There are two types of users for the CRM software:

Standard users have a limited access to the CRM system to perform CRUD (Create, Retrieve, Update, and Delete) and limited user-specific customization operations. Administrator users have unlimited privileges for the CRM. Administrator users are capable to manage the complete software including:

In figure: Special Admin Function you see the detail view of an users provided by the CRM user management function. With marking the Admin check box any user will be assigned administration privileges and become an administrator user.

Figure 4.1. Special Admin Function at Users Menu

At the core of Role-based security stands the concept of collecting permissions in roles, which can be granted to standard users. Each role is based on one or more profiles. It is a user's membership in roles that determines the privileges the user is permitted to perform. Security administration with Role-based security consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. The Role-based security framework provides for mutually exclusive roles as well as roles having overlapping responsibilities and privileges.

For example, some general CRM operations may be allowed for all employees, while other operations may be specific to a role. Role hierarchies are a natural way of organizing roles within an organization and defining the relationship and attributes of the roles. Complexities introduced by mutually exclusive roles or role hierarchies as well as regulating who can perform what actions, is all handled by the Role-based security settings.

For the CRM system to reach its full potential as a means for enterprise CRM, access control mechanisms must be in place which can regulate user access to information in a way that serves your business today. Role-based security allows for the specification and enforcement of a variety of protection policies which can be tailored on an enterprise-by-enterprise basis. Once the Role-based security framework is established for the organization, the principal administrative actions are the granting and revoking of users into and out of roles as job assignments dictate.

One of the greatest advantages of Role-based security is the administrative capabilities it supports. User membership in roles can be assigned and revoked easily, and new memberships established as job assignments dictate. With Role-based security, users are not granted permission to perform operations on an individual basis, rather operations are associated with roles. Role association with new operations can be established as well as old operations deleted, as organizational functions change and evolve. This basic concept has the advantage of simplifying the understanding and management of privileges. Roles can be updated without having to directly update the privileges for every user on an individual basis.

Furthermore, individual users (e.g. John, Mary) might be assigned to one or more roles, where the roles are based on the user's job responsibilities and competencies in the organization. Users should be assigned to multiple roles to reflect the fact that some users connect to the system in different functions depending on the tasks. For example, user John might be assigned the role Head-Sales, because John is the head of sales at your company, as well as the role admin, because John is also CRM system administrator. If John wants to work as administrator he logs in as admin, if John wants to work as head of sales, he logs in as Head-Sales. It is possible to let John connect to the system with the same password, regardless of whether he acts as administrator or head of sales.

	Note
	Users in any given role can always view, edit, delete all data owned by users below in the hierarchy.

Profiles are used to define privileges for executing CRM system operations. From a functional perspective, the central notion of Role-based security is that of profiles representing actions associated with roles and users that are appropriately made members of roles.

The relationships between users, roles, and profiles are depicted in figure: Users, Roles and Profiles Relations as many-to-many relationship. For example, a single standard user can be associated with one or more roles by different user names, and a single role can have one or more user members. Roles can be created for various job positions in an organization. For example, a role can include sales representatives or assistants in a company.

The profiles which are associated with roles, constrain members of the role to a specified set of actions. For example, within a sales organization the role of the sales representative can include operations to create, edit, and delete their own accounts; the role of an assistant can be limited to browse existing information of a particular sales rep, and the role of the head of sales may be to review all sales data.

Figure 4.2. Users, Roles and Profiles Relations

The association of profiles with roles within an enterprise can be in compliance with rules that are self-imposed. Profiles can be specified in a manner that can be used in the demonstration and enforcement of regulations. For example, an assistant can be constrained to adding a new entry to a customer's history rather than being generally able to modify sales records.

Access privileges based on profiles are set by the CRM system administrator. The administrator has to set these privileges when configuring the CRM system. Therefore, the following privilege types are available:

The CRM system makes sure that a user can only exercise certain operations if the user has proper privileges assigned.

	Important
	Note the following general rules: special privileges are always superior to common privileges revoked privileges overstrike always granted privileges in addition, the CRM system maintains special rules, in the following marked as Important

Table 4.1. Privilege Types at Profiles

Global Privileges:	If you create a profile, the global privileges allow you to decide whether the common privilege to view or to edit all information / modules of the CRM system is given: View all: A user with a role based on a profile that allows viewing all data can view all data in the entire organization. You should not give this privilege if you want to implement restricted access rules. Edit all: A user with a role based on a profile that allows editing all data can create/edit all data in the entire organisation. You should not give this privilege if you want to implement restricted access rules. Important Global privileges in profiles override the permissions defined by Tab, Standard, Field and Utility Privileges as they are explained below.
Tab Privileges:	The option to set tab privileges allows you to decide which tabs or modules should be shown. For this purpose the CRM displays all available modules.
Field Privileges:	The option to set standard privileges allows you to decide whether create, edit, delete, and view privileges are given related to the CRM modules. For this purpose the CRM displays all available modules. Important Custom fields are included. Therefore, you should have created your custom fields before starting to set field privileges.
Utilities:	Numerous CRM modules come with utility functions such as import, export, merge, and convert lead. The option to set utility privileges allows you to decide whether these functions will be available for roles that are based on a specific profile.

	Important
	Privileges defined by profiles override the Default Organization Sharing Rules and the User defined Sharing Rules. For example, let us assume that the organization sharing rule allows a user to view the potentials of others. However, if the profile does not allow access to the potential module these access privileges are revoked.

For better manageability, the CRM system allows collecting users, roles, roles with subordinates and user groups in groups. It is important to understand that groups are not a tool for defining security settings. Rather user groups are used to manage the data access.

	Important
	Note that the group settings override the profile settings. Group privileges may become restricted by custom organisation sharing privileges.

Group of Users

The CRM system provides functions to define groups of users, sometimes called teams. You may give these groups their own name and assign an unlimited number of users to one group. As an example a group called Team A is shown in figure: Group of Users - Example.

Figure 4.3. Group of Users - Example

Group of Roles

You can also build groups which are based on roles. That might be a helpful function if you do not know the individual users and their tasks within you company. An example is shown in figure: Group of Roles - Example.

Figure 4.4. Group of Roles - Example

In this group all users that have the role Sales or Marketing are members of this group. If you assign a data entry at the CRM system to this group, all members become owners of this entry.

Group of Roles with Subordinates

IIn addition to simple Role-based groups you may also build groups which include subordinates. That means the users who are assigned to roles which are below a selected role will be included. The following figures illustrate this. Let's assume your company has set up a hierarchical order as shown in figure: Hierarchy Example.

Figure 4.5. Hierarchy Example

In this figure the role "Sales" has a subordinated role "Sales Assistant" and the role "Marketing" is the master to the role "Marketing Assistant." If you create a user group as shown in figure: Group of Roles with Subordinates - Example all users with sales and marketing-related roles, including the assistants will become members of this group.

Figure 4.6. Group of Roles with Subordinates - Example

Group of Groups

You may build groups where the members are also groups. That means that all users who are a member of a selected group will also become members of the new group. Let's assume you want to build a hierarchy as shown in figure:Sample Hierarchy for Groups. Based on these structure you may create a user group Sales where the groups Team A and Team B are members. At this example the Team A and Team B groups are build with users as members.

Figure 4.7. Sample Hierarchy for Groups

If you assign a CRM data entry to the group Sales the Persons 1 to 4 will all become the owners of this entry with all privileges.