Security model

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.

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

Remote device control

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

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.

Additional permissions when publishing

Each app project is associated with one or more security roles. When we publish an app project, the security roles on the backend server are updated to gain permissions to custom Resco entities needed for correct functioning of Resco mobile apps. Some of these permissions are set on global (organization) level, some on the basic (user) level.

Level	Entity	Permissions
User	resco_mobileaudit	Read, write, create
Organization	resco_mobiledata	Read
Organization	resco_mobiledevice	Read, write, create, append
User	resco_mobilelicense	Read
Organization	resco_mobileproject	Read
Organization	resco_mobiletracking	Read, write, create
Organization	resco_mobilesecuritypolicy	Read, appendTo
Organization	resco_chatcomment	Read, write, create, delete, append
Organization	resco_chatpost	Read, write, create, delete, append, appendTo
Organization	resco_chattopic	Read, write, create, delete, append, appendTo
Organization	resco_chatuser	Read, write, create, delete, append, appendTo
User	resco_favorite	Read, write, create, delete
Organization	resco_devicecontrol	Read, write

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.

Sales entities

A significant difference exists between how Resco Cloud and Dynamics 365 Online handle permissions for the default sales entities with child entities (e.g. order product, invoice product)

• On Dynamics, child entities inherit permissions from parent entities (e.g., order detail inherits permissions as they are set for order).

  In older Dynamics versions (e.g., 2011), users need the delete permission on order to be able to delete order detail items.

  This was changed in Dynamics 365 (Online) in favor of Append and Append To permissions: They allow users to associate and remove the association with child records on the parent record.

• On Resco Cloud, child entities have separate entity permissions. This allows for a more granular permission setup.