On this page
Overview
Security management is responsible for the system's security and controls access to modules and features. It also provides a set of business rules which can be used to automatically apply additional security controls.
For information related to record level access rights and restrictions (e.g. granting exclusive access to Contact Information to the members of the department that created the contacts) view Network Management.
Major features
- Control of actions, printouts, reports, WEB APIs, and modules accessible to groups of users through security profile
- Automatic assignment of privacy level to new records used to restrict access to groups of users
- Automatic assignment of tasks to users or groups of users
- Capturing of changes done to entries using audit trail
- Restriction of visibility and modification of fields to selected departments
- Custom selection of fields set as mandatory
- Creation of security keys which can be used in webhooks
Setting Up Security Management
Security Profiles
Security Profiles provide information related to the access of modules and features by users. For example, they determine whether a menu option is available on the left menu and if the 'New' button is available for subscriptions in the Data Entry page or if the accounts receivable report, and create WEB API will be available.
Security profiles are then assigned to users and determine the respective modules and features each User will have access to when logging into the System.
By default, full access is granted by Security Profiles and it is up to you to restrict access.
Security profile fields
The table describes the sections of Security Management Definitions Data Entry page, and explains how the fields in the page are used.
Mandatory
Main Information | |
---|---|
Name Alternative Code Number of Active Users: A read-only value that provides the number of 'Active' users that use the specific Security Profile. | |
Inherited Security Profiles | |
Security profiles may inherit configuration of existing security profiles to speed up the setup process. The configuration of inherited security profiles overrides that of newly created profiles. For example, if a security profile for team leaders does not allow access to module configuration, then the security profile for team members (inherited from the team leaders' security profile) will also not allow access to module configuration, even if access was allowed in the definition of the team members' profile. Therefore, inherited security profiles are useful when you wish to add additional restrictions to those of an existing profile. | |
Menu Access | |
Main Menu | Allow or deny access to main menu options by selecting them (left hand side checkbox) and click on Allow Access or Deny Access links respectively. |
Shortcuts Menu | Allow or deny access to main menu options by selecting them (left hand side checkbox) and click on Allow Access or Deny Access links respectively. |
Module Access | |
Define the features from each module which should be restricted for this security profile | |
Common Processes | 'Deny' or 'Allow' access to each module's Common Processes, which include:
|
Additional Processes | 'Deny' or 'Allow' access to each module's Additional Processes, which include actions available in the Actions Menu of the 'Manage Module' page and Common Processes and actions of all Configuration Modules of the specific entity. |
Custom Processes | 'Deny' or 'Allow' access to each module's Custom Processes, which include any processes that are not included as standard with the software release but have been explicitly implemented for an organisation. |
Web API Methods | 'Deny' or 'Allow' access to WEB APIs available for each module. |
Reports | 'Deny' or 'Allow' access to Reports available for each module. |
Printouts | 'Deny' or 'Allow' access to Printouts available for each module. |
Interfaces | 'Deny' or 'Allow' access to Interfaces available for each module, which are not included as standard with the software release (like Custom Processes). Such interfaces are available only if requested by an organisation and can be found under Pentaho Exports or Pentaho Imports of the Utilities module. |
Dashboards | 'Deny' or 'Allow' access to the Dashboards available for each module. |
Privacy Levels and Privacy Level Groups
Privacy Level Groups are used to categorise the Privacy Levels. Privacy levels are assigned to individual records of Explicit Viewing Entities (either manually by a dedicated action or automatically by PLARs) and are used to control the access to data when shared between organisational units as well as visibility and modification of information of those records.
Privacy levels have a flat structure and their hierarchy level is represented by a numeric value. Larger privacy level numbers denote higher privacy; Users that belong to organisational units that have access to records of a specific privacy level (e.g. Privacy Level 3) can only access all records of that privacy level and below. (1,2,3).
Once privacy level groups and levels are configured, they must be used in collaboration with other system features to be used:
- Control over records shared between groups based on their privacy level: Create Group Collaboration Profiles and define the Privacy Levels and Privacy Level Groups as conditions of what is shared.
- Control over visibility and modification of records with a specific privacy level: Setup Conditional Security Restrictions and set visibility and modification restrictions on fields of records based on their privacy level. Refer to Applying conditional security conditions
Privacy level and privacy level group fields
The table describes the sections of Automatic Collaboration Rules Data Entry page, and explains how the fields in the page are used.
Mandatory
Main Information | |
---|---|
Name: the name of the group which will include multiple privacy levels Alternative Code Privacy Levels: A list of all privacy levels which are included in the group.
|
Privacy Level Assignment Rules (PLAR)
Privacy Level Assignment Rules (PLARs) are used to automatically apply privacy levels on entity records. PLARs are triggered when creating or modifying a record that meets the conditions set on the organisational units and the entity. PLARs are also applicable on all Web API calls.
Privacy level assignment rules fields
The table describes the sections of Privacy Level Assignment Rules Data Entry page, and explains how the fields in the page are used.
Mandatory Configurable
Main Information | |
---|---|
Name State: The state of the PLAR which can be 'Active' or 'Inactive'. If the state is 'Inactive', no assignment is performed Priority: Determines the order in which PLARS should be applied in case multiple are applicable. The selection box includes 5 Priority options (numbered '1' to '5') with '1' being the highest priority. Rules with no defined priority are considered to have the lowest priority. Assignment Options: Select how the privacy level will be assigned to an entity
| |
Conditions | |
Entity Conditions | The set of entity related conditions which include the following:
|
Organisational Conditions | A set of the organisational units for which the PLAR is valid, and in which the unit of the user creating or modifying a record must be included, for the PLAR to be triggered and applied. |
Automatic Collaboration Rules (ACR)
Automatic Collaboration Rules (ACRs) are used to automatically assign a record to a specific user or unit based on a set of conditions, to further process the record up to its completion. ACRs are applied when creating or modifying a record that meets the ACR conditions.
ACR is only applicable for the following Assignable entities:
- Activities
- Service requests
- Jobs
- Leads
ACRs offer two options for Automatic Assignment:
- Automatic Assignment based on the geographical area of the Contact.
- Automatic Assignment as defined by the setup rule.
Automatic collaboration rule fields
The table describes the sections of Automatic Collaboration Rules Data Entry page, and explains how the fields in the page are used.
Mandatory Configurable
Main Information | |
---|---|
Name Entity: select the entity which can be one of the following: Activities, Service requests, Jobs, Leads (these are Assignable Entities) State: The state of the ACR which can be 'Active' or 'Inactive'. If the state is 'Inactive', no assignment is performed Priority: Determines the order in which ACRs should be applied in case multiple are applicable. The selection box includes 5 Priority options (numbered '1' to '5') with '1' being the highest priority. Rules with no defined priority are considered to have the lowest priority. | |
Assignment Settings | |
Assignment Options: Defines how the assignment will be applied. Two options are available:
| |
Conditions | |
Entity Conditions | The set of entity related conditions which include the following:
|
Organisational Conditions | A set of the organisational units for which the ACR is valid, and in which the Unit of the User creating or modifying a record must be included, for the ACR to be triggered and applied. |
Conditional Security Restrictions (CSR)
Conditional Security Restrictions (CSRs) are used to restrict the visibility of certain system features and attributes of each module, and to define particular attributes as 'Non-editable' or 'Mandatory'. The restrictions are applied provided that certain conditions set on the organisational units and the entity are met. CSRs are also applicable on all Web API calls.
Different restrictions are applied for fields. processes and printouts
Restrictions | |||
---|---|---|---|
Type | Visible Entity will be visible | Editable | Mandatory Entity cannot be saved if not defined |
Fields | |||
Processes | |||
Printouts |
Conditional security restriction fields
The table describes the sections of Conditional Security Restrictions Data Entry page, and explains how the fields in the page are used.
Mandatory
Main Information | |
---|---|
Name Entity: The entity that the CSR will be applied to. State: The state of the ACR which can be 'Active' or 'Inactive'. If the state is 'Inactive', no assignment is performed | |
Restrictions | |
Fields | Unless stated otherwise in the CSR, the system sets the fields as Editable and Visible (default). Select fields of the selected entity and enable or disable, visibility, modification and requirement. A section or fields within a section can be selected. For example, Addresses or Addresses / Area can be selected. By selecting the section, top level restrictions are defined (and not for each item explicitly). |
Restricted Processes | Add the processes which should not be available |
Restricted Printouts | Add the printouts which should not be available |
Conditions | |
Entity Conditions | The set of entity related conditions which include the following:
|
Organisational Conditions | A set of the organisational units for which the CSR is valid, and in which the unit of the user creating or modifying a record must be included, for the CSR to be triggered. |
Audit Trail
Audit Trail Settings define the rules governing Audit Trail logging in the System which monitors changes performed on System entries. Through Audit Trail Settings, the entities and fields that should be monitored can be selected. Only one 'Active' instance of Audit Trail Settings per Entity can be configured in the System. Audit Trail Settings can only be applied on predefined CRM.COM entities, either through the UI or Web API and during the execution on any of the following processes:
- Modifying
- Deleting
- Removing information
The logging of an Audit Trail can be applied to a block of information or to components of that block. e.g., for the Contact Information Entity, the complete address block or only specific components of the address (e.g Address/District) can be monitored. When an address block is monitored, every time the address is modified, added or deleted, an entry will be added to the Audit Trail. When the district is monitored, an Audit Trail entry will be added when the district of an already defined address is updated.
Audit trail fields
The table describes the sections of Audit Trail Data Entry page, and explains how the fields in the page are used.
Mandatory
Main Information | |
---|---|
Entity: The entity that the Audit Trail will be applied on. The entities which can be monitored by the Audit Trail mechanism are listed in the Audit Trailed Entities. State: The state of the audit trail settings instance, which can be 'Active' or 'Inactive'. | |
Monitored Fields | |
A list of all fields related to the selected entity that can be monitored, with the option to set them as active or not. Either activate or deactivate specific fields by using the respective checkbox or 'Activate All' and 'Deactivate All' by using respective links. |
Secret Keys
Secret keys are registered to specific URL endpoints and are used by Webhooks in order generate a code that will be used by third-party systems to authenticate received data.
Secret keys fields
The table describes the sections of Secret Keys Data Entry page, and explains how the fields in the page are used.
Mandatory Configurable
Main Information | |
---|---|
Name Alternative Code Type: The type of the secret Key which should be set to Webhook URL Endpoint: The URL endpoint associated with the key (e.g. www.crm.com) Key: The key is generated automatically and is unique. The key is used to generate the authentication code for the webhook |
Related Configuration Areas
The following module is related to security management and must be configured for the security management module to operate at its full capacity.
Manual Link | Area | Description | Configuration |
---|---|---|---|
Network Management | Units | Configure the units which the ACR will use to assign records to. Optionally for each Unit define the 'covered geographical areas' to be able to use the 'Based on Geographical Areas' assignment option of the CSR | Mandatory |
Network Management | Collaboration Between Groups | Once privacy level groups and levels are configured use them in collaboration between groups to restrict the sharing of records between groups based on their privacy level. | Optional |
Using Security Management
Assigning Privacy Level
Control who has access to records when shared between different departments, (collaboration of groups), or control visibility and modification of information of those records, by setting a privacy level. Use Actions > Set Privacy Level available from the Actions menu available through Summary and Data Entry Pages.
In case you are setting the privacy level through the Summary page make sure that you first select all the records that you wish to update by checking the checkbox on the left hand side of the record.
Additional Information
- By changing contact information or accounts receivable privacy levels, the privacy level of any Contact Information based Entities or Accounts Receivable based Entities records, is affected
- In case privacy level is not defined the record is accessible to all users.
- Privacy level can be automatically set on a record based on Privacy Level Assignment Rules (PLARs).
Assigning security profile to users
Security Profiles are assigned to users through the Manage Users Data Entry page. Once you create the security profile you can define the security level of a user by adding the profile to his user.
Viewing Audit Trail
Audit trail helps you identify and changes done to records in your system by providing information on the old and new value as well as the user that made the change. Once audit trailed entities are established, it will be possible to monitor their modifications directly from the entry's Data Entry page.
- Navigate to the Data Entry page of a record with enabled audit trail
- Click on the AUDIT LOG button located at the top-right corner of the page.
- The Audit Log modal will open providing information on the modified fields and their changes.
Applying conditional security restrictions
Conditional security restrictions are automatically applied as long as conditions set in the CSR are met. Below you can see a few examples of how you can use CSR.
Fields: The address of a contact information with high privacy level is not visible to call centre agents
- Restricted Processes: Restrict the creation of a job of a 'New Subscription' fulfilment scope to call centre agents
- Restricted Printouts: Restrict the extraction of a wallet printout when the wallet is cancelled
Applying automatic collaboration rules
Automatic collaboration rules are used to assign an activity a service request, a lead or a job to a specific user or unit with the purpose to handle them. For example, on creating a new lead for a potential rewards participant residing in London, you can automatically assign it to a marketing department call agent responsible for Londoners.
There are 2 ways that the assignment can be done.
- If more than one unit covers the area in question, then the automatic assignment is not performed.
- The geographical area information is compared to each entity's distinct address.
- For activities, leads and service requests, it is compared against all available addresses of the related contact information ('Active' and 'Inactive').
- For jobs: compared against job location
Security Management Business Examples
Assign tasks for government representative customers to specific user
Scenario 1
Company ZX would like service requests created for government representative customers to only be managed by the Supervisor.
Solution
Configuration
Privacy Level Group
Create a Privacy Level Group with the following settings:
- Group Name: General
- Privacy Levels
- Privacy Level: Super High / Hierarchy Level: 10
- Privacy Level: High / Hierarchy Level: 8
- Privacy Level: Moderate / Hierarchy Level: 6
- Privacy Level: Low / Hierarchy Level: 2
Privacy Level Assignment Rule
Create a PLAR with the following settings:
- Assignment Options: Inherit From Contact Information/Accounts Receivable
- Entity Conditions: Service Requests
Automatic Collaboration Rule
Create an ACR with the following settings:
- Entity: Service Requests
- Entity Conditions:
- Privacy Level: Super High
- Assignments
- Assign to User: Supervisor
User Process
Preconditions: Privacy Level for Contact Information and Accounts Receivable of government representative customers should be manually set to Super High upon creation
- Create and save the service request.
- The privacy level is set to 'Super High' as it is inherited by the contact information (PLAR)
- The service request is assigned to the supervisor due to the privacy level set to 'Super High' (ACR)
Hide sensitive information of government representative customers
Scenario
Company ZX would like to hide addresses and phone numbers of government representative customers, to users that belong to the Customer Service department
Solution
Configuration
Privacy Level Group
Create a Privacy Level Group with the following settings:
- Group Name: General
- Privacy Levels
- Privacy Level: Super High / Hierarchy Level: 10
- Privacy Level: High / Hierarchy Level: 8
- Privacy Level: Moderate / Hierarchy Level: 6
- Privacy Level: Low / Hierarchy Level: 2
Conditional Security Restriction
Create a CSR with the following configurations:
- Entity: Contact Information
- Field Restrictions: Select all address related fields and remove visibility
- Conditions: Privacy Level: Super High
- Organisational Conditions: Customer Service
Monitor change of addresses
Scenario 3
Company ZX would like to monitor every change of address.
Solution
Configuration
Audit Trail
Create an 'Active' Audit Trail record with the following settings:
- Entity: Contact Information
- Fields:
- Contact Information Addresses
- Contact Information Addresses/Area
- Contact Information Addresses/Country
- Contact Information Addresses/District
- Contact Information Addresses/Municipality
- Contact Information Addresses/Postal Code
- Contact Information Addresses/State
- Contact Information Addresses/Street Name
- Contact Information Addresses/Street Number
- Contact Information Addresses/Town
- Contact Information Addresses/Type
Notes
- If you are using a previous release, view CRM.COM Release Changes.
Glossary
CRM.COM Term | Definition |
---|---|
Activity | A small task or action that is either stand-alone or must be completed as part of a larger project. |
Lead | A potential opportunity for additional business. |
Service Request | Used to register problems that customers experience with their products and subscriptions and to check whether products are under warranty. |
Job | A small project initiated by the operator for customers, involving the delivery and billing of services, products and activities. Customer requests and orders, such as that for a new subscription, can be initiated and registered through a job. |
Assignable Entity | A CRM.COM entity which requires a course of action and can be assigned to a unit or a user, which will be responsible for performing the actions. |
Organisational Unit | A unit or group or community |
Explicit Viewing Entity | Entity which holds information regarding the owner of a record. |
Unit | Represents a body of Users which belong on the same team and follow identical business processes. |
Group | Represents a body of Users which belong to the same department and to one or multiple collaborating teams within that department, and follow common business processes. |
Collaboration | The sharing between of data to be viewed, modified, or assigned between goups |