CRM has sophisticated security configuration facilities that use a combination of business units and security roles to determine the information and functionality available to each user within CRM.
Each record in CRM (except for organisation-owned entities) is assigned an owner who belongs to a business unit. It is the business unit that determines the security and each user is given a number of roles that determine whether they can access just records they own or access all the records belonging to the same business unit or those lower down in the hierarchy.
The following concepts apply to CRM security:
· Root Organisation – the root business unit for the installation.
· Business Unit – a hierarchical structure reflecting the organisation of the business, perhaps according to business function (sales, marketing, customer service) for a smaller company. Each user belongs to one business unit.
· User – a user is assigned to a single business unit and has one or more security roles. The least restrictive security setting against all of the roles assigned to a user determines the security level.
· Roles – the security role determines the security permissions available against each entity or function. Roles are defined against the root organisation or for a particular business unit and are inherited by the child business units.
· Teams – individual records may be shared with individual users or with teams of users. Although teams have a default business unit, any user can be assigned to a team.
Teams allow for exceptions to be made to the security depending on the business unit hierarchy and individual records can be shared with any individual user or team.
The Enterprise version of CRM offers multi-tenancy where multiple instances of the CRM database can run side by side on the same hardware with users being able to log in to each instance with a single user licence. This may be useful for larger companies where different divisions run entirely separate business processes which can be installed as independent databases.
An organogram of your organisation can be used to determine a hierarchy of business units (departments) within the organisation that is broken down so that all staff within each unit are likely to be sharing information with each other. Members of each unit can be assigned different security roles so that the manager role, for example, can view all information owned by a business unit but ordinary members can view only their own data.
Each business unit is part of a hierarchy (the parent business unit can be changed in the actions menu) and inherits the available security roles from its parent. It is recommended that security roles are maintained against the primary business unit so that each role has a similar definition throughout the organisation.
Security settings can be set up for each entity to cascade down to related (one to many) entities so that all related records have their ownership changed or are shared with a team when the parent record is assigned to another owner or shared (see the customisation section).
Business units can refer to external organisations that require access to CRM, such as resellers, affiliates or suppliers. Security can be set up so that these users can view and update data only within their own business unit. They can be made part of a team to be given access to other records only if the record is shared with the appropriate team.
Note: Take care when setting up the business units as the names cannot be changed after they have been entered.
All user settings can be configured within the settings-business units option, and new users can also be created and altered here. Note that new users must first be created in the Windows Active Directory and that deleting or changing the user details within Active Directory does not automatically update the entry in CRM.
Entering the Domain Logon Name for a new user will automatically extract the remaining details from the Active Directory.
The Organisation Information for a User is useful in different areas of the application:
· Manager can be used to create workflow and for reporting analysis.
· Business unit is the core organising principle behind the ownership of data and security.
· Territory is used for assigning leads and monitoring the sales cycle.
· Site is used to determine location for scheduling.
Note: Multiple users can be entered from the new-add users option.
Changing the business unit for a user will affect the security settings on all of the records owned by the user and needs some care. All of the owned records can be reassigned before changing the business unit with the reassign records option on the actions menu of the user form (you can also use the assign button available on the view toolbar).
The manager and business unit can be changed from the actions menu. Changing a business unit against a user deletes all of the roles, and the user will have no security rights to access the system until a new set of roles has been specified.
Users can be enabled and disabled and the number of full and read-only users should match the purchased licences. There are three different access modes for a user:
· Full provides access to the database according to the least restrictive of the assigned security roles.
· Administrative users have no access to data but can log on to the system and change settings (no licence required).
· Read-only users pay a reduced licence fee but cannot write to the database.
Note: Read-only and administrative users can be owners of tasks even though they cannot alter data, and workflow could be defined to carry out email notifications as necessary.
Email Access Configuration allows you to define the way in which email is synchronised with CRM with regular Outlook users using the Outlook client for integration and other users perhaps using automatic routing via Exchange.
Note: You can test different users without having to logon multiple times by selecting the Internet Options and changing the Security settings for your browser to prompt for user logon (usually for trusted sites). You will be prompted for a username and password each time you access the system.
Security settings for each role are defined for each entity or against specific functions. A number of default roles are set up during CRM installation and can be used or copied to help with initial configuration. Take care to create roles at the highest applicable business unit in the hierarchy so that changes are passed down throughout the system.
Note: System Administrator and System Customiser are special roles for administering and customising the system.
Remember also that users belong to a single business unit and can have multiple roles with the least restrictive security permission applied where appropriate.
Security settings can be established at the following levels:
· None – no access permitted.
· User – the user can access entity occurrences that he or she owns, along with entities that have been shared explicitly with that user or a team to which the user belongs.
· Business Unit – the user can access any entity owned by members of their business unit.
· Child Business Unit – the user can access any entity owner by their business unit or any business unit lower down in the hierarchy.
· Organisation – access to everything.
Most entities have user-based ownership, and the owning business unit is determined by the owner of the record. Changing the owner, using the assign button, may in some cases also change the business unit affecting the access rights on that entity occurrence. Changing the business unit for a user will also change the Business Unit of all of the entity occurrences owned by that User.
Teams are used to allow exceptions to the security levels. Perhaps some contacts need to be shared with users in separate business units, but the current security access level denies access. In this case, the entity occurrence can be shared with individual users or teams who then have the permitted access to that entity.
Note: Teams are assigned to a default business unit, but this is just to limit the teams visible to other users. Any user can be specified as a member of any team.
One problem with security is that the business unit is automatically assigned to each record according to the current owner and it does not seem possible to change this without reassigning the owner. This can cause problems when a department is sub-divided into several business units and the manager and administrative staff are in the parent business unit. In this case, any records created by the manager cannot be viewed by the users in the child business units and will have to be shared with a team.