| Anchor | ||||
|---|---|---|---|---|
|
| Excerpt | ||
|---|---|---|
| ||
Learn to work with Security Management |
| Panel | ||||
|---|---|---|---|---|
| ||||
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.
| Note |
|---|
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
...
| Panel | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Security Management - The Basics
|
...
Security Management - The Admin Stuff
...
| Info | ||
|---|---|---|
| ||
| Foundation > 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 | |
|---|---|
Name Alternative Code 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 | |
|---|---|
Name of the group with multiple privacy levels. Alternative Code Privacy Levels: A list of all levels that are included in the group.
|
| Anchor | ||||
|---|---|---|---|---|
|
...
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 | |
|---|---|
Name State of the PLAR can be 'Active' or 'Inactive' (no assignment performed). 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. |
| Anchor | ||||
|---|---|---|---|---|
|
...
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
| Note |
|---|
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 | |
|---|---|
Name Entity: One of the assignable entities (activities, service requests, jobs, leads). State of the ACR can be 'Active' or 'Inactive' (no assignment performed). Priority Order: Determines the order in which ACSs are applied. Priority options are numbered from '1' (highest priority) to '5'. Rules with undefined priority order have the lowest priority. | |
| Assignment Settings | |
Assignment Options: Select how the assignment will be applied.
| |
| 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. |
| Anchor | ||||
|---|---|---|---|---|
|
...
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 | |||
|---|---|---|---|
Name TheEntity that the CSR will be applied to. State of the CSR can be 'Active' or 'Inactive' (no assignment performed). | |||
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'.
| ||
| 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 and accessing on system records either through the UI or the WEB API.
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.
Additionally searching contacted in the system can be logged through audit trail logs available in summary pages.
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 Entity to which the audit trail will be applied. State of the audit trail settings instance, which can be 'Active' or 'Inactive'. The can only be one 'Active' instance per entity. Log Accessing and Retrieving defines whether the access or retrieve (search) of the data will be logged as well. | |
| 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 | |
|---|---|
Name Alternative Code Type of key (Webhook) URL Endpoint associated with the key (e.g., www.crm.com) 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
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
...
The audit trail identifies changes on system records by providing information on modified values and the user that effected the change or accessing of such records as well as accessing of the records either through the UI or the WEB API
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.
Additionally Audit Trail logs associated to searching contacted in the system is available through the action 'Audit Log' available in Summary pages. If the audit trail is accessed then a list of all the searches taking place along with the criteria used is available.
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
| Note |
|---|
|
Reports
...
Audit Trail information can be extracted in a structured format for analysis by using reports. The audit trail included in the report are selected and grouped based on user-defined criteria. The user can select the fields displayed in the report.
Refer to Reports for more information.
Audit Log per Contact Report
The report displays a list of the audit trail logs of a specific Contact Information and its related entities (Accounts Receivable and Rewards Participant)
Audit Log per User Report
The report displays a list of the audit trail logs that were performed by a specific user and are related to Contact Information and its related entities (Accounts Receivable and Rewards Participant)
Security Management Business Examples
Assigning tasks for government clients to a specific user
| Panel | ||||
|---|---|---|---|---|
| ||||
Scenario 1 Company ZX requires the supervisor to handle service requests created for government clients. Solution Configuration Privacy Level Group
Privacy Level Assignment Rule
Automatic Collaboration Rule
User Process Preconditions: The privacy level when creating contact information and accounts receivable for government clients should be manually set to 'Super High'.
|
Hiding sensitive government client information
| Panel | ||||
|---|---|---|---|---|
| ||||
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
Conditional Security Restriction Create a CSR with the following configurations:
|
Monitoring address changes
| Panel | ||||
|---|---|---|---|---|
| ||||
Scenario 3 Company ZX wants to monitor all address changes. Solution Configuration Audit Trail Create an 'Active' audit trail record with the following settings:
|
| Note | ||
|---|---|---|
| ||
|
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. |
| Panel | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Related Links
|