To control data access, you must set up an organizational structure that both protects sensitive data and enables collaboration where appropriate. You do this by setting up business units A way of representing a division or department in an organization. Business units are arranged in a hierarchy, and all users in the same division or department are assigned to one business unit., security roles Defined sets of privileges.The security role assigned to a user determines which tasks the user can perform and which parts of the user interface the user can view. All users must be assigned at least one security role in order to access the system., and field security profiles These allow or restrict access to secured custom fields..
Business Units
A business unit basically is a group of users. Large organizations with multiple customer bases often use multiple business units to control data access and define security roles so that users can access records only in their own business unit.
A security role defines how different users, such as salespeople, access different types of records. To control access to data, you can modify existing security roles, create new security roles, or change which security roles are assigned to each user. Each user can have multiple security roles.
Security role privileges A user's rights to perform specific actions on specific record types or to perform tasks. Privileges are assigned by system administrators to security roles. Users are then assigned security roles. Examples of privileges include Update Account and Publish Customizations. are cumulative: having more than one security role gives a user every privilege available in every role.
Each security role consists of record-level privileges Privileges that are specific to one record type, such as Read, Create, and Write. and task-based privileges Privileges that apply to tasks that are not specific to one record type, such as Export to Excel and Go Offline.. These privileges determine which records the user can access: None None An access level that denies the user privileges at any level. , User User An access level that lets the user work with record types they own, record types that are shared with the user, and record types that are shared with the team of which the user is a member. For example, if a user is assigned the User access level on the Read privilege for Account records, the only accounts that can be read are those that are owned by or shared to the user. , Business Unit Business Unit An access level that lets the user work with record types in the user's business unit. Users who have Business Unit access automatically have User access as well. For example, if a user has Business Unit access level on the Read privilege for Account records, the user can read all accounts in the local business unit. , Parent: Child Business Unit This right lets the user work with record types in the user's business unit, and all business units subordinate to the user's business unit. Users with Parent: Child Business Unit access automatically have Business Unit and User access as well. , and Organization Organization An access level that lets the user work with all record types within the entire organization, regardless of the business unit hierarchical level to which the entity or user belongs. Users who have Organization access automatically have Parent: Child Business Units, Business Unit, and User access. .
Each type of record is either user-owned Records that are used by individuals or sub-groups, such as accounts, activities, and leads. Access to this type of record can be set at one of five levels: None , User , Business Unit , Parent-Child Business Units , or Organization . or organization-owned Records that everyone in the organization needs to access, such as products or sales literature items. Access to this type of record can be set at one of two levels: None , or Organization .. Record-level privileges define which tasks a user with access to the record can do, such as Read A privilege required to read a record. Which records can be read depends on the access level of the permission defined in your security role., Create A privilege required to create a new record. Which records can be created depends on the access level of the permission defined in your security role., Delete A privilege required to permanently remove a record. Which records can be deleted depends on the access level of the permission defined in your security role., Write A privilege required to make changes to a record. Which records can be changed depends on the access level of the permission defined in your security role., Assign A privilege required to give ownership of a record to another user. Which records can be assigned depends on the access level of the permission defined in your security role., Share A privilege required to give access to a record to another user while keeping your own access. Which records can be shared depends on the access level of the permission defined in your security role., Append A privilege required to associate a record with the current record. For example, if a user has Append rights on an opportunity, the user can add a note to an opportunity. Which records can be appended depends on the access level of the permission defined in your security role., and Append To A privilege required to associate the current record with another record. For example, a note can be attached to an opportunity if the user has Append To rights on the note. Which records can be appended to depends on the access level of the permission defined in your security role..
The owner of a record or a person who has the Share A privilege required to give access to a record to another user while keeping your own access. Which records can be shared depends on the access level of the permission defined in your security role. privilege on a record can share a record with other users or teams Groups of users who share and collaborate on business records.A team can consist of members who all report to one business unit or members who report to different business units.. Sharing can add Read A privilege required to read a record. Which records can be read depends on the access level of the permission defined in your security role., Write A privilege required to make changes to a record. Which records can be changed depends on the access level of the permission defined in your security role., Delete A privilege required to permanently remove a record. Which records can be deleted depends on the access level of the permission defined in your security role., Append A privilege required to associate a record with the current record. For example, if a user has Append rights on an opportunity, the user can add a note to an opportunity. Which records can be appended depends on the access level of the permission defined in your security role., Assign A privilege required to give ownership of a record to another user. Which records can be assigned depends on the access level of the permission defined in your security role., and Share A privilege required to give access to a record to another user while keeping your own access. Which records can be shared depends on the access level of the permission defined in your security role. privileges for specific records. More information: Share or Assign Records and Views
Teams are used primarily for sharing records that team members ordinarily couldn't access. More information: Work with Teams
It is not possible to remove access for a particular record. Any change to a security role privilege applies to all records of that record type.
In Microsoft Dynamics CRM, fields on forms can have read, create, and update permissions. Create or change custom field permissions using the Field Security setting on the field customization form and by establishing Field Security Profiles.
Field security profiles are similar to security roles in Microsoft Dynamics CRM. Both specify what users or groups of users can see, modify, or create in Microsoft Dynamics CRM.
When creating a custom field on a form, you have the option to use field security. Using field security for a field limits access to a field based on a user's field security profile. Not using field security for a field bases any restrictions to the field only on a user's security role.