Microsoft Dynamics CRM 4.0 Security Model
Create a rough model of your company’s current operational structure. For each section of your organizational layout, you should identify the approximate number of users and the types of business functions those users perform. This rough organizational map to start planning how you want to set up and configure security in your Dynamics CRM deployment.
Each box in the figure represents a business unit. Each business unit can have multiple child business units. Dynamics CRM security only allows to specify one business unit per user. A single business unit for a team, each team can consist of users from one or many business units.
A rough organizational model with information about the different types of users in your system, then translate that information into Dynamics CRM security settings.
Security Model Concepts
The Microsoft Dynamics CRM security model uses two main concepts: Role-based and object-based security and Organizational structure
Organizational Structure
Role-based Security - Roles, Privileges, Access Levels
Object-based Security - Access rights, Create access, Sharing objects, Assigning objects
Role-Based Security
It is a set of access levels and privileges for each of the entities (such as Leads, Accounts, or Cases) in Dynamics CRM. Roles are associated with permissions (privileges and access levels) for the different business objects (entities). Therefore, when a user logs on to the system, Dynamics CRM looks at the user’s assigned security roles and uses that information to determine what the software will allow that user to do and see throughout the system. This is known as role-based security.
Privileges define what actions a user can perform on each entity in Dynamics CRM. Privileges are pre-defined in Dynamics CRM and cannot be changed; examples of privileges include Create, Read, Write, and Delete.
Privileges by Entity
Miscellaneous Privileges
Add Reporting Services Reports (upload RDL), Delete Audit Partitions (audit partitions for each three-month period), Publish Duplicate Detection Rules, Publish Mail Merge Templates to Organization, View Audit History, View Audit Summary, Bulk Delete,...
Access levels
Access levels indicate which records associated with each entity the user can perform actions upon. Although default access levels are assigned to each privilege, the access level can be changed. For example, if a role allows the user to delete accounts, the access level associated with the account delete privilege indicates the specific accounts that the user can delete.
None Example
Dan is the Purchase Manager for Adventure Works’ Easter Region. Adventure Works has decided that there are some privileges the Purchase Manager must be restricted from performing, such as creating, writing, and deleting Views. To guarantee this, the System Administrator creates a copy of the default Purchase Manager role and assigns the None access level to the Create, Write, and Delete privilege for the Views entity. Dan is assigned this new, customized role instead of the default Purchase Manager role.
If Kader is assigned None as the Delete Order access level, he cannot delete any order in the system, including any order that he owns.
User Example
Bob and Jane are in the Root BU
Bob owns Account A, and Jane owns Account B
Bob has the Read Account privilege at User depth
Bob can read Account A but not Account B
In Adventure Works Cycle, Jim is a CSR in the CS business unit. Jim has 'User Account Create' and 'User Account Write' access. The User level access for these two privileges enables Jim to create new Accounts and edit (change) any records that are assigned to him, shared with him by other users, or shared with any team in which he is a member.
Business Unit Example
Bob and Jane are in the Root BU, and Alice is in the Child 1 BU
Bob owns Account A, Jane owns Account B, and Alice owns Account C
Bob has the Read Account privilege at Business Unit depth
Bob can read Account A and Account B, but not Account C
Hassan is the CS Manager at Adventure Works Cycle. He manages the CSR and is required to assign and review all accounts and cases assigned to these representatives. Assigning him 'Business Unit Case Create' access enables him to create cases for any customer assigned to the CS business unit. Similarly, if Hassan has 'Business Unit Account Delete' access, he can delete any Account record that is owned by him or any user who is assigned to the CS Business Unit.
Parent: Child Business Units Example
Bob and Jane are in the Root BU, and Alice is in the Child 1 BU
Bob owns Account A, Jane owns Account B, and Alice owns Account C
Bob has the Read Account privilege at Parent:Child Business Units depth
Bob can read Account A, Account B, and Account C
Aliyar is VP of Sales and Marketing for Adventure Works Cycle. He manages all the Sales and Marketing representatives for the Field Sales and Marketing Divisions. By assigning Aliyar 'Parent:Child Opportunity Read' access, she can view all opportunities owned by any user assigned to the Sales & Marketing business unit or any one of its child business units. Because the Adventure Works Cycle, Customer Care, Customer Support, and OEM Support business units are not subordinate to Aliyar's business unit, she cannot view opportunities owned by users assigned to those business units.
Organization Example
Bob and Jane are in the Root BU, Alice is in the Child 1 BU, and Ted is in the Child 2 BU
Bob owns Account A, Jane owns Account B, Alice owns Account C, and Ted owns Account D
Alice has the Read Account privilege at Organization depth
Alice can read Account C and Account D
Noor is the System Administrator for Adventure Works Cycle. He requires the ability to reassign ownership of any record in the system, regardless of the business unit to which the owner of the record belongs. If his System Administrator role gives him Organization Lead Assign access, Noor can reassign any lead that is entered in the system, regardless of who owns the record.
More Example
Bob, Jane, and Alice are in the Root BU
Bob and Jane have the Read Account privilege at User depth
Alice has the Read Account privilege at Business Unit depth
In this environment: Bob can read Account A, but not B or C
Jane can read Account B, but not A or C
Alice can read Accounts A, B, and C
Security Roles
Dynamics CRM includes a set of 14 pre-defined security roles that reflect common user roles. Each security role is associated with a set of privileges that determines the user's access to information within the company. You can define custom roles.
Delegate - A user that can perform actions on behalf of another user
Schedule - Manager A user who manages services, required resources, and working hours
Scheduler - A user who schedules appointments for services
System Administrator - A user who defines and implements the process at any level
System Customizer - A user who customizes Microsoft Dynamics CRM records, attributes, relationships, and forms
CEO-Business Manager, CSR Manager, Customer Service Representative, Marketing Manager, Marketing Professional, Sales Manager, Salesperson, Vice President of Marketing, Vice President of Sales
Security Roles and Privileges at http://msdn.microsoft.com/en-us/library/bb954998.aspx
Go to Settings -> System -> Adminisistration -> Security Roles
When you assign multiple security roles to a user, Dynamics CRM combines the user rights so that the user can perform the highest-level activity associated with any of her roles.
Dynamics CRM divides the privileges of a security role into subsets by creating tabs for the functional areas, such as Marketing, Sales, Service, and so on. Each tab in the security role editor lists different entity privileges and miscellaneous privileges for entities in Dynamics CRM. The colored circles in the security role settings define the access level for that privilege.
The privileges and access levels that are associated with the CSR role are shown in the following screenshot:
Object-Based Security
Object-based security in Dynamics CRM focuses on how users gain access to individual instances of business objects (entities) and is provided by using access rights. Define different security parameters for the various records (such as Lead, Account, Contact, ...) because each record has an owner.
The relationship between an access right and a privilege is that access rights apply only after privileges have taken effect. For example, if users do not have the privilege to read accounts, they will be unable to read any account, regardless of the access rights another user might grant them to a specific account through sharing.
Access Rights
Create Access - not included in the table because by default, the user who creates an entity instance will have all rights on that entity instance, unless his or her other privileges forbid a specific right.
Sharing Entity Instances
Sharing provides the ability for users to allow other users or teams access to specific customer information. Consider the following example:
Bob and Ted are both assigned the Salesperson role, which has User Read and Write access to accounts
Ted owns Account B and shares Opportunity 1 with Bob, with Read rights
Bob can now read Opportunity 1, but not Account B
Sharing capabilites are Share, Share rights, Modify share, Remove share.
Open the entity record and click Sharing on the Actions menu (Share or Share Secure Fields) of the entity menu bar. In the Share dialog box, select the users with whom you want to share this record by clicking Add User/Team.
Assigning Entity Instances
Anyone with Assign privileges on an entity instance can assign that object to another user. When an entity instance is assigned to a new user, the new user becomes the owner of the entity instance and its related entity instances. The original user loses ownership of the entity instance but automatically shares it with the new owner.
In Dynamics CRM 4.0, the system administrator can decide for an organization whether entity instances should be shared with previous owners or not after the assign operation. If Share with previous owner is chosen, then after the assign operation the previous owner shares the entity instance with all access rights. Otherwise the previous owner does not share the entity instance and therefore may not have any access to the instance, depending on his or her privileges.
Cascading Rules
In Dynamics CRM, certain actions, such as sharing and assigning, on a parent entity instance can affect child entity instances based upon the cascading rules that are configured on the relationships between the parent object and its child objects.
Dynamics CRM actions that are can be controlled by using cascading rules include: Assign, Delete, Merge, Reparent, Share, Unshare
The cascading rules in Dynamics CRM 4.0 are described in the following table.
Sharing and Inheritance
A child entity instance inherits the sharing properties of the parent entity instance according to the cascading rules configured for the parent entity instance.
Sharing is maintained on individual entity instances. An entity instance inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, an entity instance can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent.
For example, Bob and Ted are working on a high-priority lead. Bob creates a new lead and two activities, shares the lead with Ted, and selects cascade sharing, which also gives Ted access to the associated activities. Ted makes a call and sends an e-mail regarding the new lead. Bob sees that Ted has contacted the company two times, so he does not make another call.
Note: Bob could also have explicitly shared the two activities with Ted without having to share the lead.
Removing the share of a parent entity instance removes the sharing properties of objects (entity instances) that it inherited from the parent. That is, all users who previously had visibility into this entity instance no longer have visibility.
Entity Types in Microsoft Dynamics CRM 4.0
Managing Users
Settings Area -> System - > Administration -> Users.
For each user, you must complete the following security-related tasks:
Assign one or more security roles to the user. Assign the user to one business unit. Assign the user to one or more teams. Assign a Client Access License type.
As an administrator:
Disable old users and reassign their records to different users. Monitor the number of Microsoft Dynamics CRM licenses you’re using to make sure you are compliant.
Reassigning User Records
If employee quits, disable the user, want to reassign his or her records to a different user in the system. 2 Methods, Bulk Reassign
Open a user record -> Click the Reassign Records button in the ribbon -> The dialog box will be appears.
Manually Reassign Active Records - Select the active records, assign them to an new owner.
Monitoring License Usage for Compliance - Start the Microsoft Dynamics CRM Deployment Manager on the Microsoft Dynamics CRM web server, right-click the Microsoft Dynamics CRM link in the left column, and select Properties. The Microsoft Dynamics CRM Properties dialog box opens. Click the License tab.
Security Role Inheritance
When you create a new security role in a business unit, Dynamics CRM creates an instance (copy) of that security role for every business unit that is a child of the business unit for which you created the new security role. If you try to edit the security role in one of the child business units, you will see a warning message stating, 'Inherited roles cannot be modified or updated.' You can edit only the parent security role, and then Dynamics CRM automatically copies your changes to all of the security roles in the child business units.
If you create a new security role called Manager assigned to the Customer Care business unit, Dynamics CRM automatically creates noneditable copies of the Manager security role in the Customer Support and OEM Support business units because they are children
of the Customer Care business unit. Any changes you make to the Manager security role are automatically propagated to all of the Manager security roles in the child business units. When you view the security roles for one of the other business units, such as Service or OEM,
you do not see the Manager security role listed because the Service and OEM business units are not children of the Customer Care business unit.
Field Level Security
When you enable field security, no user can access that field until you explicitly give him or her permission. However, users with the System Administrator security role will always have full access to all secured fields in Dynamics CRM.
Field Security Profiles
Settings -> Administration -> click Field Security Profiles.
By default Microsoft Dynamics CRM includes a system administrator field security profile. Like security roles, field security profiles offer a way for administrators to group together a set of security settings.
Reference
http://msdn.microsoft.com/en-us/library/bb954998.aspx
http://msdn.microsoft.com/en-us/library/gg309524.aspx
http://technet.microsoft.com/en-us/library/hh699698.aspx
http://msdn.microsoft.com/en-us/library/bb955124.aspx
- Supports a licensing model for users.
- Provides users with access only to the information that they require to do their jobs
- Categorizes types of users by role and restrict access based on those roles.
- Prevents users from accessing objects that they do not own or share.
- Supports data sharing by providing the ability to grant users with access to objects that they do not own to participate in a specified collaborative effort.
Create a rough model of your company’s current operational structure. For each section of your organizational layout, you should identify the approximate number of users and the types of business functions those users perform. This rough organizational map to start planning how you want to set up and configure security in your Dynamics CRM deployment.
Each box in the figure represents a business unit. Each business unit can have multiple child business units. Dynamics CRM security only allows to specify one business unit per user. A single business unit for a team, each team can consist of users from one or many business units.
A rough organizational model with information about the different types of users in your system, then translate that information into Dynamics CRM security settings.
Security Model Concepts
The Microsoft Dynamics CRM security model uses two main concepts: Role-based and object-based security and Organizational structure
Organizational Structure
- Organization (Root Business Unit) - The organization is the top level of the Dynamics CRM business management hierarchy. Dynamics CRM automatically creates the organization based on the name that you enter during the software installation. You cannot change or delete this information.
- Business unit - A logical grouping of your business operations. Each business unit can act as a parent for one or more child business units.
- Team - Teams are a group of users that share and collaborate on records. Team members can belong to different business units.
- User - Someone who typically works for the organization and has access to Dynamics CRM. Each user belongs to one (and only one) business unit, and each user is assigned one or more security roles.
Role-based Security - Roles, Privileges, Access Levels
Object-based Security - Access rights, Create access, Sharing objects, Assigning objects
Role-Based Security
It is a set of access levels and privileges for each of the entities (such as Leads, Accounts, or Cases) in Dynamics CRM. Roles are associated with permissions (privileges and access levels) for the different business objects (entities). Therefore, when a user logs on to the system, Dynamics CRM looks at the user’s assigned security roles and uses that information to determine what the software will allow that user to do and see throughout the system. This is known as role-based security.
Privileges define what actions a user can perform on each entity in Dynamics CRM. Privileges are pre-defined in Dynamics CRM and cannot be changed; examples of privileges include Create, Read, Write, and Delete.
Privileges by Entity
| Privilege | Description |
| Create | Create an entity. |
| Read | View entities. |
| Write | Make changes to entities for users. |
| Delete | Remove entities for users. |
| Append | Permits the user to attach another entity to, or associate another entity with, a parent record. Associate a selected entity to another entity. |
| Append To | Permits the user to attach other entities to, or associate other entities with, the record. To associate an entity to this entity. |
| Assign | Give access to entities to another user. |
| Share | Give access to entities to another user while keeping your own access. |
| Reparent | Assign a different parent to an entity. |
| Enable/Disable | Give or take away privileges. |
Miscellaneous Privileges
Add Reporting Services Reports (upload RDL), Delete Audit Partitions (audit partitions for each three-month period), Publish Duplicate Detection Rules, Publish Mail Merge Templates to Organization, View Audit History, View Audit Summary, Bulk Delete,...
Access levels
Access levels indicate which records associated with each entity the user can perform actions upon. Although default access levels are assigned to each privilege, the access level can be changed. For example, if a role allows the user to delete accounts, the access level associated with the account delete privilege indicates the specific accounts that the user can delete.
| SDK Name | Access Level | Description |
 Global | Organization | This global access level 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 as well. |
 Deep | Parent: Child Business Units | This deep access level 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 Units access automatically have Business Unit and User access as well. For example, if a user has Parent: Child Business Units Read Account privileges, the user can read all accounts in his or her business unit, as well as all accounts in any child business unit of that business unit. |
 Local | Business Unit | This middle access level 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 Read Account privileges, the user can read all accounts in the local business unit. |
 Basic | User | This entry access level 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 Read Account privilege, the only accounts that can be read are those that are owned by or shared to the user. |
 None | None Selected | This access level denies the user privileges at any level. A privilege is not added to the security role. |
None Example
Dan is the Purchase Manager for Adventure Works’ Easter Region. Adventure Works has decided that there are some privileges the Purchase Manager must be restricted from performing, such as creating, writing, and deleting Views. To guarantee this, the System Administrator creates a copy of the default Purchase Manager role and assigns the None access level to the Create, Write, and Delete privilege for the Views entity. Dan is assigned this new, customized role instead of the default Purchase Manager role.
If Kader is assigned None as the Delete Order access level, he cannot delete any order in the system, including any order that he owns.
User Example
Bob and Jane are in the Root BU
Bob owns Account A, and Jane owns Account B
Bob has the Read Account privilege at User depth
Bob can read Account A but not Account B
In Adventure Works Cycle, Jim is a CSR in the CS business unit. Jim has 'User Account Create' and 'User Account Write' access. The User level access for these two privileges enables Jim to create new Accounts and edit (change) any records that are assigned to him, shared with him by other users, or shared with any team in which he is a member.
Business Unit Example
Bob and Jane are in the Root BU, and Alice is in the Child 1 BU
Bob owns Account A, Jane owns Account B, and Alice owns Account C
Bob has the Read Account privilege at Business Unit depth
Bob can read Account A and Account B, but not Account C
Hassan is the CS Manager at Adventure Works Cycle. He manages the CSR and is required to assign and review all accounts and cases assigned to these representatives. Assigning him 'Business Unit Case Create' access enables him to create cases for any customer assigned to the CS business unit. Similarly, if Hassan has 'Business Unit Account Delete' access, he can delete any Account record that is owned by him or any user who is assigned to the CS Business Unit.
Parent: Child Business Units Example
Bob and Jane are in the Root BU, and Alice is in the Child 1 BU
Bob owns Account A, Jane owns Account B, and Alice owns Account C
Bob has the Read Account privilege at Parent:Child Business Units depth
Bob can read Account A, Account B, and Account C
Aliyar is VP of Sales and Marketing for Adventure Works Cycle. He manages all the Sales and Marketing representatives for the Field Sales and Marketing Divisions. By assigning Aliyar 'Parent:Child Opportunity Read' access, she can view all opportunities owned by any user assigned to the Sales & Marketing business unit or any one of its child business units. Because the Adventure Works Cycle, Customer Care, Customer Support, and OEM Support business units are not subordinate to Aliyar's business unit, she cannot view opportunities owned by users assigned to those business units.
Organization Example
Bob and Jane are in the Root BU, Alice is in the Child 1 BU, and Ted is in the Child 2 BU
Bob owns Account A, Jane owns Account B, Alice owns Account C, and Ted owns Account D
Alice has the Read Account privilege at Organization depth
Alice can read Account C and Account D
Noor is the System Administrator for Adventure Works Cycle. He requires the ability to reassign ownership of any record in the system, regardless of the business unit to which the owner of the record belongs. If his System Administrator role gives him Organization Lead Assign access, Noor can reassign any lead that is entered in the system, regardless of who owns the record.
More Example
Bob, Jane, and Alice are in the Root BU
Bob and Jane have the Read Account privilege at User depth
Alice has the Read Account privilege at Business Unit depth
In this environment: Bob can read Account A, but not B or C
Jane can read Account B, but not A or C
Alice can read Accounts A, B, and C
Security Roles
Dynamics CRM includes a set of 14 pre-defined security roles that reflect common user roles. Each security role is associated with a set of privileges that determines the user's access to information within the company. You can define custom roles.
Delegate - A user that can perform actions on behalf of another user
Schedule - Manager A user who manages services, required resources, and working hours
Scheduler - A user who schedules appointments for services
System Administrator - A user who defines and implements the process at any level
System Customizer - A user who customizes Microsoft Dynamics CRM records, attributes, relationships, and forms
CEO-Business Manager, CSR Manager, Customer Service Representative, Marketing Manager, Marketing Professional, Sales Manager, Salesperson, Vice President of Marketing, Vice President of Sales
Security Roles and Privileges at http://msdn.microsoft.com/en-us/library/bb954998.aspx
Go to Settings -> System -> Adminisistration -> Security Roles
When you assign multiple security roles to a user, Dynamics CRM combines the user rights so that the user can perform the highest-level activity associated with any of her roles.
Dynamics CRM divides the privileges of a security role into subsets by creating tabs for the functional areas, such as Marketing, Sales, Service, and so on. Each tab in the security role editor lists different entity privileges and miscellaneous privileges for entities in Dynamics CRM. The colored circles in the security role settings define the access level for that privilege.
The privileges and access levels that are associated with the CSR role are shown in the following screenshot:
Object-Based Security
Object-based security in Dynamics CRM focuses on how users gain access to individual instances of business objects (entities) and is provided by using access rights. Define different security parameters for the various records (such as Lead, Account, Contact, ...) because each record has an owner.
The relationship between an access right and a privilege is that access rights apply only after privileges have taken effect. For example, if users do not have the privilege to read accounts, they will be unable to read any account, regardless of the access rights another user might grant them to a specific account through sharing.
Access Rights
| Right | Enumeration Name | Description |
| Read | ReadAccess | View an entity instance. |
| Write | WriteAccess | Make changes to entities for users. |
| Delete | DeleteAccess | Remove entities for users. |
| Append | AppendAccess | Associate a selected entity to another entity. |
| Append To | AppendToAccess | To associate an entity to this entity. |
| Assign | AssignAccess | Give access to entities to another user. |
| Share | ShareAccess | Give access to entities to another user while keeping your own access. |
Create Access - not included in the table because by default, the user who creates an entity instance will have all rights on that entity instance, unless his or her other privileges forbid a specific right.
Sharing Entity Instances
Sharing provides the ability for users to allow other users or teams access to specific customer information. Consider the following example:
Bob and Ted are both assigned the Salesperson role, which has User Read and Write access to accounts
Ted owns Account B and shares Opportunity 1 with Bob, with Read rights
Bob can now read Opportunity 1, but not Account B
Sharing capabilites are Share, Share rights, Modify share, Remove share.
Open the entity record and click Sharing on the Actions menu (Share or Share Secure Fields) of the entity menu bar. In the Share dialog box, select the users with whom you want to share this record by clicking Add User/Team.
Assigning Entity Instances
Anyone with Assign privileges on an entity instance can assign that object to another user. When an entity instance is assigned to a new user, the new user becomes the owner of the entity instance and its related entity instances. The original user loses ownership of the entity instance but automatically shares it with the new owner.
In Dynamics CRM 4.0, the system administrator can decide for an organization whether entity instances should be shared with previous owners or not after the assign operation. If Share with previous owner is chosen, then after the assign operation the previous owner shares the entity instance with all access rights. Otherwise the previous owner does not share the entity instance and therefore may not have any access to the instance, depending on his or her privileges.
Cascading Rules
In Dynamics CRM, certain actions, such as sharing and assigning, on a parent entity instance can affect child entity instances based upon the cascading rules that are configured on the relationships between the parent object and its child objects.
Dynamics CRM actions that are can be controlled by using cascading rules include: Assign, Delete, Merge, Reparent, Share, Unshare
The cascading rules in Dynamics CRM 4.0 are described in the following table.
| Rule | Description |
| Cascade All | Perform the action on the specified entity instance and all related entity instances. |
| Cascade None | Perform the action on the specified entity instance only. Do not cascade to related entity instances. |
| Cascade Active | Perform the action on the specified entity instance and all related entity instances that are active or open. |
| Cascade User Owned | Perform the action on the specified entity instance and all related entity instances that are owned by the same user as this entity. |
| Remove Link | Perform the action on the specified entity instance and remove the link to the related entity instance. No changes are made to the related entity instance. |
| Restrict | Applies to delete only. The delete is not allowed if there are other entity instances that reference the ID of the entity instance being deleted. |
Sharing and Inheritance
A child entity instance inherits the sharing properties of the parent entity instance according to the cascading rules configured for the parent entity instance.
Sharing is maintained on individual entity instances. An entity instance inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, an entity instance can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent.
For example, Bob and Ted are working on a high-priority lead. Bob creates a new lead and two activities, shares the lead with Ted, and selects cascade sharing, which also gives Ted access to the associated activities. Ted makes a call and sends an e-mail regarding the new lead. Bob sees that Ted has contacted the company two times, so he does not make another call.
Note: Bob could also have explicitly shared the two activities with Ted without having to share the lead.
Removing the share of a parent entity instance removes the sharing properties of objects (entity instances) that it inherited from the parent. That is, all users who previously had visibility into this entity instance no longer have visibility.
Entity Types in Microsoft Dynamics CRM 4.0
| Entity Type | Examples | Characteristics |
| User-Owned | Account, Contact, Lead | Have a specific owner attached to them, Can be shared to other users or teams, Can be assigned to other users, Access is determined by privilege depth on that object and sharing |
| Business-Owned | Business Unit, Role, SystemUser | Same as User-Owned but without assign/share, Access is determined by privilege depth |
| Organization-Owned | Product, Territory, ContractTemplate | Access is determined by organization membership |
| Child Entities | SalesLiteratureItem, QuoteDetail | Access is determined through parent object,Example: Privilege to read ContractDetail == Privilege to read Contract, Example: AccessCheck(user, ContractDetail A, Read) == AccessCheck(user, ContractDetail A’s parent Contract, Read) |
Managing Users
Settings Area -> System - > Administration -> Users.
For each user, you must complete the following security-related tasks:
Assign one or more security roles to the user. Assign the user to one business unit. Assign the user to one or more teams. Assign a Client Access License type.
As an administrator:
Disable old users and reassign their records to different users. Monitor the number of Microsoft Dynamics CRM licenses you’re using to make sure you are compliant.
Reassigning User Records
If employee quits, disable the user, want to reassign his or her records to a different user in the system. 2 Methods, Bulk Reassign
Open a user record -> Click the Reassign Records button in the ribbon -> The dialog box will be appears.
Manually Reassign Active Records - Select the active records, assign them to an new owner.
Monitoring License Usage for Compliance - Start the Microsoft Dynamics CRM Deployment Manager on the Microsoft Dynamics CRM web server, right-click the Microsoft Dynamics CRM link in the left column, and select Properties. The Microsoft Dynamics CRM Properties dialog box opens. Click the License tab.
Security Role Inheritance
When you create a new security role in a business unit, Dynamics CRM creates an instance (copy) of that security role for every business unit that is a child of the business unit for which you created the new security role. If you try to edit the security role in one of the child business units, you will see a warning message stating, 'Inherited roles cannot be modified or updated.' You can edit only the parent security role, and then Dynamics CRM automatically copies your changes to all of the security roles in the child business units.
If you create a new security role called Manager assigned to the Customer Care business unit, Dynamics CRM automatically creates noneditable copies of the Manager security role in the Customer Support and OEM Support business units because they are children
of the Customer Care business unit. Any changes you make to the Manager security role are automatically propagated to all of the Manager security roles in the child business units. When you view the security roles for one of the other business units, such as Service or OEM,
you do not see the Manager security role listed because the Service and OEM business units are not children of the Customer Care business unit.
Field Level Security
When you enable field security, no user can access that field until you explicitly give him or her permission. However, users with the System Administrator security role will always have full access to all secured fields in Dynamics CRM.
Field Security Profiles
Settings -> Administration -> click Field Security Profiles.
By default Microsoft Dynamics CRM includes a system administrator field security profile. Like security roles, field security profiles offer a way for administrators to group together a set of security settings.
Reference
http://msdn.microsoft.com/en-us/library/bb954998.aspx
http://msdn.microsoft.com/en-us/library/gg309524.aspx
http://technet.microsoft.com/en-us/library/hh699698.aspx
http://msdn.microsoft.com/en-us/library/bb955124.aspx
No comments:
Post a Comment