On this page
Overview
Security management is the center from which an organization controls access to system modules and features and ensures the implementation of its business rules.
Access to customer data is handled through Network Management.
Major features
- Grant access to modules and features through a security profile.
- Assign privacy level automatically (restricting access to records, to specific groups).
- Automatically assign tasks to users or departments.
- Capture changes in records with an audit trail.
- Allow selected departments to view and edit specific fields.
- Select which fields should be mandatory.
- Create security keys to be used in webhooks.
Setting Up Security Management
Security profiles
Security profiles determine the system modules and features that users can access (including actions, printouts, reports, WEB APIs). A profile grants full access by default. It is subsequently configured with restrictions and then assigned to users.
For example, a profile can be used to restrict access to:
- Sections on the Left menu
- 'New' subscriptions button in the Data Entry page
- Accounts receivable report
- Option to create WEB APIs.
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 | |
|---|---|
Number of Active Users that use the specific profile (read-only). | |
| Inherited Security Profiles | |
Security profiles can inherit existing configurations to speed up the setup process. Inherited profiles are ideal for setting additional restrictions, as their configuration overrides those of a new profile. E.g.: The security profile of management team leaders restricts access to module configuration. If the finance team leaders inherit their profile from the management, access to module configuration will be restricted despite being granted in the finance team leaders profile definition. | |
Menu Access Select menu options (left-hand side checkbox) and use 'Allow' or 'Deny' access | |
Main Menu: If access to a 'Parent' menu option is denied (e.g., Billing > Additive Discounts), the restriction is also applied the 'Child' menu options (e.g., Billing > Additive Discounts > Manage Ad Hoc Discounts). The child menu option will not be available. Shortcuts Menu | |
| Module Access | |
Define the features from each module that should be restricted to each security profile. Modules can be filtered by application area by using the list filter ( Select a module to load its security settings and use Allow and Deny access. The Actions menu button is greyed out for 'Denied' processes.
|
Privacy levels and privacy level groups
Privacy levels (PL) are used to control access to view and modify data shared between organizational units. The privacy levels are assigned to individual records of Explicit Viewing Entities, either manually through a dedicated action or automatically by PLARs.
Privacy levels have a hierarchy represented by a numeric value, ascending with higher privacy; Users that belong to an organizational unit with access to records of a specific privacy level (e.g., PL3) can access records up to and including the specific privacy level (e.g., PL 1, 2, 3).
Privacy level groups are used to classify and label privacy levels. Once privacy level and level groups are configured they are used in tandem with other system features. For example, they can be used to:
- Control the modification of shared records (e.g., create Group Collaboration Profiles to share data between the London and Manchester group, but only let Manchester users modify records created by London users).
- Control the visibility of private records (e.g., setup Conditional Security Restrictions and restrict the visibility of high privacy contact addresses and telephones to call center agents).
- Assign new records to particular users or departments according to the privacy level of each record (e.g., setup Automatic Collaboration Rules and assign new high privacy level activities to the manager).
Privacy level and privacy level group fields
The table describes the sections of Privacy Level Group Data Entry page and explains how the fields in the page are used.
Mandatory
| Main Information | |
|---|---|
Privacy Levels: A list of all levels that are included in the group.
|
Privacy level assignment rules
Privacy Level Assignment Rules (PLARs) are used to automatically apply privacy levels when creating or modifying a record, based on a set of conditions set in the PLAR. PLARs can also be applied to Web API calls.
Privacy level assignment rule fields
The table describes the sections of Privacy Level Assignment Rule Data Entry page and explains how the fields in the page are used.
Mandatory
Configurable
| Main Information | |
|---|---|
Priority Order: Determines the order in which PLARS are applied. Priority options are numbered from '1' (highest priority) to '5'. Rules with undefined priority order have the lowest priority. Assignment Option: Select how the privacy level will be assigned to an entity.
Inherit From Contact Information/Accounts Receivable: Apply the privacy level of the master entity record (contact information or accounts receivable). E.g., Communications have a contact information master entity. If the contact for which the communication is created has privacy level set to '5', then so will the communication. | |
| Conditions | |
| Entity Conditions |
|
| Organisational Conditions | The units in which users (creating and editing records) must be included for the PLAR to apply. |
Automatic collaboration rules
Automatic collaboration rules (ACRs) are used to automatically assign the further processing of a record to a specific user or unit based on a set of conditions.
ACRs are triggered when creating or modifying a record. ACRs apply to the following assignable entities:
- Activities
- Service requests
- Jobs
- Leads
The automatic assignment of ACRS can be based on the geographical area of the contact or 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 | |
|---|---|
| |
| Assignment Settings | |
| |
| Conditions | |
| Entity Conditions |
|
| Organisational Conditions | The units in which users (creating and editing records) must be included, in order for the ACR to be applicable. |
Conditional security restrictions
Conditional Security Restrictions (CSRs) are used to restrict the visibility of certain system features and module attributes and to define particular attributes as 'Non-editable' or 'Mandatory'. The restrictions are applied if conditions set on the organizational units and entities are met. CSRs also apply to all Web API calls.
Different restrictions are applied to 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 | |
|---|---|
The
| |
Restrictions | |
| Fields | Unless otherwise stated in the CSR, the system sets the fields as 'Visible' and 'Editable' by default. Select entity fields and check to enable whether they should be 'Visible', 'Editable' and 'Mandatory'. 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 (not for each item explicitly). |
| Restricted Processes | Add processes that should not be available. |
| Restricted Printouts | Add printouts that should not be available. |
| Conditions | |
| Entity Conditions |
|
| Organisational Conditions | The units in which users (creating and editing records) must be included for the CSR to apply. |
Audit trail
Audit trail settings define the rules for monitoring modifications on system records.
Entities and fields to be monitored are selected through audit trail settings. Only one 'Active' instance of audit trail settings can be configured for each entity. Settings are applied to predefined CRM.COM entities, through the UI or Web API, while modifying, deleting or removing information.
The logging of audit trail can be applied to a block of information or to block components. For example, the complete address block or specific components of the address (such as Address/District) can be monitored. When an address block is monitored, an entry is added to the audit trail every time the address is modified, added or deleted. When the district is monitored, an entry will be added when the district of an already defined address is updated.
Refer to Viewing Audit Trail for information on how audit trail settings are applied and displayed in updated records.
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 | |
|---|---|
The
| |
| Monitored Fields | |
A list of all fields related to the selected entity that can be monitored and which can be activated or deactivated individually or all at once. At least one field should be activated in an 'Active' audit trail setting. |
Secret keys
Secret keys are registered to specific URL endpoints and are used by Webhooks to 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 | |
|---|---|
Key: Generated automatically and unique. The key is used to generate the authentication code for the Webhook. |
Related Configuration Areas
Mandatory modules must be configured for the security management module to work.
Optional modules may be configured for the security management module to operate at its full capacity.
| Manual Link | Area | Description | Configuration |
|---|---|---|---|
| Network Management | Units | Configure the units to which the ACR will assign records. To use the 'Based on Geographical Areas' assignment option of the ACR, define the 'covered geographical areas' for each unit. Units may also be used in the organizational conditions of CSRs and PLARs. | Mandatory |
| Network Management | Groups | Groups may be used in the organizational conditions of ACRs, CSRs and PLARs. | Optional |
| Network Management | Communities | Communities may be used in the organizational conditions of ACRs, CSRs and PLARs. | Optional |
| Network Management | Collaboration Between Groups | Once privacy levels and level groups are configured, use them to restrict the sharing of records between collaborating groups. | Optional |
Using Security Management
Assigning a privacy level
The privacy level of a record, used in system security processes, can determine:
- Permissions to view and modify information shared between departments through Group Collaboration.
- Permissions to view and modify data through Conditional Security Restrictions.
- Users or units to be assigned activities, service requests, jobs and leads through Automatic Collaboration Rules.
To define the privacy level of a record, click on SET PRIVACY LEVEL from the Actions menu available on the Summary and Data Entry page. In the Summary page, select the records to update by checking the checkbox on the left of the record.
Additional Information
- Modifying the privacy level of a 'contact information' or an 'accounts receivable' affects the privacy level of entities associated with the specific contact or account. For example, if the privacy level of a contact is set to 'High', the privacy level of the contact's subscriptions, accounts, wallets, and activities will be set to the same level.
- Records without a privacy level are accessible to all users.
- Privacy level can be automatically set on a record based on privacy level assignment rules.
Assigning a security profile to users
Security profiles are assigned to users through the manage users Data Entry page. The security profile is created and added to a user to define their security level.
Viewing the audit trail
The audit trail identifies changes on system records by providing information on modified values and the user that effected the change. Once audit trailed entities are established, it is possible to monitor their changes directly from their Data Entry page.
- Navigate to the Data Entry page of an audit trail enabled record.
- 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 (CSRs) are automatically applied if their conditions are met. CSR examples:
Fields: The address of a contact with high privacy level is not visible to call center agents.
- Processes: Restrict the creation 'New Subscription' fulfillment scope jobs to call center agents.
- Printouts: Restrict wallet printouts after a wallet is canceled.
Applying automatic collaboration rules
Automatic collaboration rules are used to assign activities, service requests, leads or jobs to a specific user or unit. For example, when a new lead for a potential rewards participant residing in London is created, it can be automatically assigned to a marketing department call agent responsible for the London area.
- If more than one unit covers the area, the assignment is not automatic.
- Geographical area is evaluated against the entity's address.
- For activities, leads and service requests, the geographical area is evaluated against all ('Active' and 'Inactive') addresses of the contact.
- For jobs, the geographical area is evaluated against job location.
Security Management Business Examples
Assigning tasks for government clients to a specific user
Scenario 1
Company ZX requires the supervisor to handle service requests created for government clients.
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: The privacy level when creating contact information and accounts receivable for government clients should be manually set to 'Super High'.
- Create and save the service request.
- The privacy level is inherited by the contact information (PLAR) and set to 'Super High'.
- The service request is assigned to the supervisor as the privacy level set to 'Super High' (ACR).
Hiding sensitive government client information
Scenario
Company ZX requires that the addresses and phone numbers of government clients are hidden from users belonging 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 is 'Super High'
- Organisational Conditions: Customer service
Monitoring address changes
Scenario 3
Company ZX wants to monitor all address changes.
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 | 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 that 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, group or community. |
| Explicit Viewing Entity | Entity that holds information regarding the owner of a record. |
| Unit | A body of users that belong to the same team and follow identical business processes. |
| Group | A body of users that belong to the same department and to one or multiple collaborating teams within that department, and follow common business processes. |
| Collaboration | The sharing between groups of data to be viewed, modified, or assigned. |