We are preparing a new source of documentation for you. Work in progress!

Security model

From Resco's Wiki
Jump to: navigation, search

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.

Business units.png

User

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.

Team

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

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.

Permissions

Common permissions:

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

Dependencies:

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

Other permissions:

  • View audit history/summary
  • Bulk delete
  • Publish email templates/reports/articles
  • etc.

Entity permissions

  • 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:

  1. First field level security must be enabled for particular entity field.
  2. Users (or teams) are added to Field Security Profiles. (Unrelated to security roles!)
  3. 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.)

Security manager

Remote device control

Woodford administrators can use Device control to display and manage devices that are synchronized with your CRM.

Relation to cloud service security level

Security roles

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.

Predefined roles:

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