Access Control is used to control access to CiviCRM data and functionality. This is done through Access Control Lists (ACL's). An ACL consists of:
1. A Role that has permission to do this operation ('Administrator', 'Team Leader'),
2. An Operation (e.g. 'View' or 'Edit'), and
3. A set of Data that the operation can be performed on (e.g. a group of contacts)
EXAMPLE: "Team Leaders" (Role) can "Edit" (Operation) all contacts in the "Active Volunteers Group" (Data).
CiviCRM provides built-in access control for contact groups, profiles and custom data.
CiviCRM for Drupal includes additional access control features for specific tasks (Administer, Import, etc.), and for component data (contributions, membership, and events). It should be noted that in Drupal you only need to use CiviCRM's ACLs if you wish to control access of certain contacts to certain groups; if you simply want to control the types of data and actions a user can see/perform you can use the Drupal permissions Administer » User Management » Access Control.
CiviCRM's built-in Access Control is managed by Access Control Lists (ACL's). ACL's allow you to control who can view and edit specific contact groups, specific profiles and/or specific sets of custom data.
For example, you might want to allow only staff on your Development Team to view or edit contacts in your "High Value Donor" group. The basic steps for this are:
If you are having trouble with getting Permissions to work like you think they should, the first step is to look at your Drupal or Joomla! user Permissions. For example, if you want to prevent a CiviCRM user from editing another contact's record and adding or removing them from an ACL group then you have to uncheck (or disable) "View All Contacts" AND "Edit All Contacts" for that user role. Then go into CiviCRM Access Control and give that role Edit or View permissions. In order to filter out the ACL Groups to prevent users from adding or removing contacts to ACL Groups jump over to the forum and check this topic out on how to do that: http://forum.civicrm.org/index.php/topic,14595.0.html. This blog post by Gregory Heller also provides a detailed step-by-step guide for controlling access to "sensitive" sets of custom fields.
"Users" is the name Drupal and Joomla use to describe either people who have an account and can log into the website (authenticated/registered user), or a website visitor who has not logged in (anonymous/public user). In CiviCRM, "users" refers to anyone who has been assigned a role with specific permissions to take actions in CiviCRM. "Contacts" is the name CiviCRM gives to the Individuals, Organizations and Households that you create and store in CiviCRM.
PERMISSIONS let you control what users can do on your site. Each user ROLE (see ROLES below) has its own set of permissions. View the default permissions here.
ROLES allow you to fine tune the security and administration of Drupal or Joomla. A role defines a group of users that have certain privileges as defined in PERMISSIONS. Examples of ROLES include: anonymous user, authenticated user, moderator and administrator.
You will need to decide which roles you need, based on your workflows (see PLAN)
These rules allow you to limit accounts that are allowed to be created or logged in.
If you are giving multiple users access to CiviCRM data and tasks, it's a good idea to assign/limit which tasks and/or groups of contacts each user can manipulate. You will use ROLES and PERMISSIONS to determine what each user can see and do.
ROLES are a way of assigning one or more specific PERMISSIONS to a group. Users assigned to the ROLE are granted specific permissions assigned to the role. You can create as many roles as needed and users can be assigned to one or more roles. You can only assign ROLES to groups of contacts.
PERMISSIONS are the actual tasks which are granted to a ROLE. These may be functional - e.g. edit (all) contacts, or they may relate to a specific subset of your data, e.g. a defined group of contacts (enewsletter subscribers). You could allow only enewsletter subscribers' to view custom data (enewsletter subscriber interests) by assigning the PERMISSION "View enewsletter subscriber interests" to the ROLE of enewsletter subscriber.