Roles

At the core of role based security is the concept of collecting permissions in roles, which can be granted to standard users. Each role is assigned one or more privileges (e.g., data access, deletion, modification). It is a user's membership into roles that determine 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 by 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.

One of role based security greatest advantages is the administrative capabilities it supports. User membership into roles can be assigned ans 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.

Important: Each user created in the CRM system must be associated with a role. A role must be associated with at least one profile.

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 multiple roles to reflect the fact that some users connect to the system in different function 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 at any given role can always view, edit, delete all data owned by users below in the hierarchy.

For the CRM system to reach its full potential as a means for enterprise CRM, access control mechanisms must be in place that can regulate user access to information in a manner that face 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. The purpose of the role based security setting is to provide this access control service. 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. These maintenance tasks are easily performed using the CRM system's user settings tool.

Profiles

Profiles are used to define privileges for executing CRM system operations. From a functional perspective, role based securities central notion 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 is depicted in Figure: User, Role and Profile 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 representative or assistant in a company. The profiles that 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 the 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 1.2. User, Role and Profile 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 customers history rather than being generally able to modify sales records.

Your access privileges to the CRM system are set by the administrator. The administrator should set these privileges when configuring the CRM system. Thereby the following privilege types are available:

• The permission to use certain CRM modules.
• The permission to view data in certain CRM modules.
• The permission to edit or to change data in certain CRM modules.
• The permission to delete data in certain CRM modules.
• The permission to export data from certain CRM modules.
• The permission to import data to certain CRM modules.

The CRM system makes sure that you can only exercise certain operations if you have proper privileges.
Important Note the following rules:

• special privileges are always superior to common privileges
• revoked privileges overstrike always granted privileges
• at the CRM system there are special rules, please note the special rules marked as “Important”
  

Thereby, the CRM system distinguishes the following privilege types: Global Privileges:

When you create a profile the global privileges allows you to decide whether the common privilege to view or to edit all information / modules of the vtiger CRM system is given:

• View all: user can view all module data in the organization
• Edit all: user can create/edit all module data in the organization
  

Important

Global Privileges in Profiles override the permissions defined by Tab, Standard, Field and Utility Privileges as they are explained below.

For example, let us assume in a profile the access to the Potentials tab is denied via Tab Privileges. Even then a standard user can view the Potentials module data if the 'View all' permission is set in the Global Privileges of the users profile.

Tab Privileges:

The option to set tab privileges allow you to decide which tabs or modules to be shown.

This includes the Leads, Accounts, Contacts, Potentials, Dashboards, Activities, Trouble Tickets, FAQ, Calendar, Price Books, Purchase Orders, Invoices, Reports, Notes, Emails, Products, Vendors, Quotes, Sales Orders, RSS, and Campaigns modules.

Standard Privileges:

The option to set standard privileges allow you to decide whether Create or Edit, Delete, and View privileges are given related to the CRM modules.

That includes the Leads, Accounts, Contacts, Potentials, Activities, Trouble Tickets, FAQ, Price Books, Purchase Order, Invoices, Notes, Emails, Products, Vendors, Quotes, and Sales Orders modules.

Field Privileges:

The option to set field privileges allows you to decide what entry field for each CRM module will be available for roles that are based on this profile.

That includes the Leads, Accounts, Contacts, Potentials, Activities, Trouble Tickets, FAQ, Price Books, Purchase Orders, Invoices, Notes, Emails, Products, Vendors, Quotes, and Sales Orders modules.

Important Custom fields are included. Therefore, you should have created your custom fields first before you set the 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 this 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 an user to view the Potentials of other users. However, if the profile does not allow to access the Potential module these access privileges are revoked.

User Groups

Each data entry at the CRM system has an owner. Such an owner could be an individual user or a group of users, called team. For better manageability several users, roles, roles with subordinates and user groups can be collected in user groups. You may use this to assign data entries to team

Note 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.

The following sections explain what a group membership means and how it can be used.

Group of users

Users can be collected in groups. Let us assume we would like to build a small group of sales representatives, called Team A as shown in Figure: Group of Users Example.

Figure 1.3. Group of Users Example

Person 1 and Person 2 suppose to be the members of this group, so we build a group of users. Each of these Persons are assigned to a role that defines the security settings for the individual user. You may now assign data sets to this group, as shown as an example in Figure: Activity assigned to Group. The assignment to this group means, that all members of this group are the owner of this entry.