We are preparing a new source of documentation for you. Work in progress!
The goals of the security model are:
- Users access only data they need for their job
- Categorize users by role and restrict access based on those roles.
- Support data sharing for collaboration. (Users are granted access to records that they do not own.)
- Prevent user access to records they do not own or share.
Organization and business unit
Organization is the top-level of the CRM business hierarchy. It corresponds to the specific business, company, etc. Scheme customization is done at this level. (Entities, DB)
An organization is divided into hierarchical business units. Child business units are optional.
Users are individuals who have specific logins/passwords and a set of attached privileges at various access levels. Each user has to be part of a business unit. Users can own/share records. Each user can have one or more security roles.
Teams group up users from one or more Business units. A user can be a member of several teams. User rights are inherited from all the teams the user is member of.
Teams can own/share records. That's why they are also called ownership teams. Team is assigned one or more security roles. Examples: sales teams, marketing teams
Both users and teams are so-called principals; they are stored in SystemUserPrincipals table.
Ownership concept allows better definition of the user rights.
Entity types by ownership:
- None - Not owned by anybody. System entities, NN entities...
- Organization Owned - Article, Competitor, Currency... Has an organizationid attribute, cannot be assigned/shared.
- Business Owned - BusinessUnit, Calendar, Team, SecurityRole, User... Belong to a business unit. Has an owningbusinessunit attribute.
- User or Team Owned - Role-based security applies, can be assigned/shared. Has owningteam/owninguser attributes.
Custom entities are either organization-owned or user-or-team owned.
- Create, Read, Write, Delete
- Append and AppendTo deal with source > destination relations:
- Append ("Append Me") allows to set this record as a source.
- Example: User with Append privilege for opportunity can add notes to opportunity records.
- Example: User has Append privilege for contacts => Parent customer field (account lookup) on the Contact form is enabled.
- AppendTo ("Append To Me") allows to set this record as destination.
- Example: User has AppendTo privilege for notes => he can add notes to other records.
- Ex: User has AppendTo privilege for contacts => Primary Contact on the Account form is enabled.
- Assign: Transfer ownership of my record to another user (This modifies the Owner field and therefore also requires the appropriate Write privileges)
- Share: User that gets the shared access must have at least basic access to the entity type being shared.
Certain actions require a combination of permissions:
|Create a record||CREATE, READ|
|Share a record||SHARE, READ|
|Assign a record||ASSIGN, WRITE, READ|
|Append To a record||WRITE, READ, APPEND TO|
|Append a record||WRITE, READ, APPEND|
- View audit history/summary
- Bulk delete
- Publish email templates/reports/articles
- Create – Allow user to create new records.
- Read – Allow user to view the record.
- Write – Allow user to edit the record.
- Delete – allow user to delete the record.
- Append - Associate to another record.
- AppendTo - Associate to this record.
- Assign - Transfer record ownership to another user.
- Reparent - Assign a different parent to entity record.
- Share - Provide an access to a record to another user while keeping your own access, i.e. salesperson grants read access to an opportunity to another salesperson.
Field level security
Field level security is used in situations when certain fields contain sensitive data.
Field level security is available for the default fields on most out-of-box entities, custom fields, and custom fields on custom entities.
The process to secure a field:
- First field level security must be enabled for particular entity field.
- Users (or teams) are added to Field Security Profiles. (Unrelated to security roles!)
- Read/Create/Update permissions for the given entity field are granted to those profiles. (Create: User can define the field content for an empty field.)
Remote device control
Relation to cloud service security level
Security roles define what the users can do with different types of records. A business unit can have several security roles. These roles are inherited by child business units. Roles defined by the root business unit are available everywhere.
Security role defines the access levels and permissions for each CRM entity. Security role applies to all records of the given type. It’s not possible to add/remove access for a particular record.
- CEO-business manager
- VP of sales
- Sales manager
- Sales rep
- CSR manager
- CSR (Customer Service Representative)
- Marketing professional
- System administrator
Other roles can be added.
Each user must be assigned a role.
Security roles are cumulative - one user may have more security roles. If so, his privileges are a union of the permissions of respective roles.
Differences between CRMs
Various CRM servers implement their security model in different ways. For example, Resco CRM server streamlines ownership of entities and does not allow record sharing.