Microsoft CRM Implementation Guide - Microsoft CRM System Security

Note: The information provided in the user records is viewable by the entire organization.

Microsoft® Business Solutions Customer Relationship Management (Microsoft CRM) security ensures data integrity and privacy using security roles, privileges and access levels, rights, and privacy. This security model applies to all record types (objects) on the Microsoft CRM server, Microsoft CRM Sales for Outlook, and Crystal Reports.

The security model applies to the following main areas:

• External security

• Internal security

• Authorized user access control (roles, privileges, and so forth)

Security Privileges

Microsoft CRM has predefined privileges that cannot be modified. A privilege is an action performed by a user on a record type (object) with an access level. For example, in “User can Delete Lead Business Unit,” the action is “Delete,” the record type is “Lead,” and the access level is “Business Unit.”

Actions

The action portion of the security privilege defines what the user can do and which record types the user has access to, as determined by the access level and record type portion of the privilege. There are many actions available in the Microsoft CRM security model, for example, Create, Read, Write, Delete, and Append.

A complete list of actions, record types, and their corresponding access levels is available in "Appendix B: Security Role Tables."

Objects

A complete list of actions, record types, and their corresponding access levels is available in "Appendix B: Security Role Tables."

Access Levels

The access level for a given record type determines at which levels within the organization hierarchy a user can act on that record type. Microsoft CRM has the access levels listed in the following table.

Each access level includes record types exposed by all access levels below the level granted to the user by the privilege. For example, a user with Parent: Child Business Units access for action on or to a particular record type also has Business Unit and Local access for that action on or to the same record type.

Note: There is a known issue when upgrading a privilege depth from Business Unit to Organization or Parent: Child Business Units access. Doing so fails with the following error:

“This role already holds the privilege with the ID {GUID}.”

The workaround is to remove the privilege entirely and add it back with the depth you want.

Security Roles

As an aid to managing security, Microsoft CRM has predefined security roles. A security role is represented by a position title (such as Sales Manager or System Administrator), to which are assigned privileges most likely to be required by people serving in that position. Microsoft CRM has the following predefined security roles:

• CEO-Business Manager

• Customer Service Representative

• CSR Manager

• Marketing Professional

• Sales Manager

• Salesperson

• System Administrator

• Vice President of Sales

Also, you can create additional roles for your organization. These can be created either new or by modifying an existing predefined or custom role. Custom roles are automatically added to the Active Directory® Organizational Unit for the business unit in which the custom role is created.

Important: Do not delete or modify the System Administrator role because you will not be able to reinstate it and could therefore lock yourself out of the system.

For a detailed list of the default security privileges for each predefined security role in Microsoft CRM, see "Appendix B: Security Role Tables."

Editing and Creating Security Roles

You can edit predefined or existing custom security roles to suit your needs. You can also create new security roles by editing a predefined roll and giving it a new name, or you can create a new one from the start. New security roles are added to Active Directory. Active Directory requires that names of objects in Microsoft CRM that are added to Active Directory must be 51 characters or less.

You can add a security role to any business unit. All child business units of the business unit in which you initially create the new security role get the new security role as well. The same applies to changes and deletions of security roles. Changes and deletions are propagated down the hierarchy.

When you create a business unit within the organization, all predefined security roles are added to that business unit. You can then add, delete, and modify security roles to the business unit. Child business units, upon their creation, are populated with the identical security roles of the parent business unit.

Edit a security role

1. Open Microsoft CRM (either the Web client or the Outlook client), click Home, click Settings, click Business Unit Settings, and then click Security Roles.

2. Click the role that you want to edit.

3. See the online Microsoft CRM Help for more information.

Create a new security role

1. Open Microsoft CRM (either the Web client or the Outlook client), click Home, click Settings, click Business Unit Settings, and then click Security Roles.

2. Click New Role.

3. See the online Microsoft CRM Help for more information.

Copy a security role

1. Open Microsoft CRM (either the Web client or the Outlook client), click Home, click Settings, click Business Unit Settings, and then click Security Roles.

2. Click the role of which you want to make a copy.

3. See the online Microsoft CRM Help for more information.

Security Rights

Each instance of a record type has security rights associated with it. A record instance is different from a record type in that there can be many instances of a particular type of record. Microsoft CRM has the following rights associated with each instance of a record:

• CRM_Access_Create

• CRM_Access_Read

• CRM_Access_Write

• CRM_Access_Delete

• CRM_Access_Append

• CRM_Access_Assign

• CRM_Access_Share

• CRM_Access_AppendTo

A user has these security rights to a specific record instance if:

• The user owns the record instance.

• The record instance is set as public.

• The record instance owner shares the record instance with another user.

Security Dependencies

Sometimes is it necessary to have more security rights than may seem necessary to perform a given action. For example, if you have security rights CRM_Access_Create and CRM_Access_Read for accounts, you can create an account record but you cannot assign it to another user unless you also have CRM_Access_Assign.

The following table lists the dependencies among the access rights for a given action.

Top of page