Overview

Important areas of CRM.COM are the ones used to set up your business network; the departments and teams, the users as well as security settings used throughout the system. There are 3 main areas used to set this up:

• Network Management is used to define the structure of an organisation's internal departments and external partner network, and subsequently define access to data, at record level. 
• User Management used to create and administer CRM.COM accounts. User management defines the access and permissions required for system access and maintenance.
• Security Management is the centre from which an organisation controls access to system modules and features, and ensures the implementation of its business rules.

Set up Network Settings

Network Management is used to define the structure of an organisation's internal departments and external partner network, and subsequently defining access to data, at record level. 

Business Unit Categories 

Business unit categories follow a hierarchical tree structure and are used to classify business units into generic groups based on similar characteristics (e.g. Merchants, Partners etc.) .

Business Units 

Business units represent an organisation's divisions (e.g. branches) and sub organisations (e.g. departments), where a group of people (or devices belonging to that business unit) work together to carry out a specific business operation. Business units can be based in different geographical locations, while a hierarchical representation (defining the relationship between them and parent business units) can model the organisation's structure. In the context of CRM.COM, business units functionality and data access can be differentiated using Type and access Classifications respectively.

In terms of functionality, business units can be belong to one of the following types: operating and commercial.

• Operating Business Units are used for reporting purposes and form the hierarchical structure of an organisation. An operational business unit can be the owner of multiple transaction acquiring points from which transactions will be submitted to the system (e.g. purchase customer events).
• Commercial Business Units are used for transactional purposes, where an account is required; describing the financial agreement with the organisation's business unit. A commercial business unit can be the owner of a reward agreement, multiple warehouses, multiple transaction acquiring points from which transactions will be submitted to the system (e.g. purchase customer events). The root business units should be classified as commercial.

In terms of data access, business units can be classified based on three business access levels. Each level defines which records can be accessed by a business unit and whether a collaboration will be required for sharing data. The root business units (Level 0) can be assigned with any of the three access levels, and all child business units will inherit such an access level by default. The access level of the child business units can be explicitly defined, but it should be equal to or less than the parent business unit's access level. In addition, parent business units are allowed by default to perform any record action (view, use, create and modify) of its child business units.

• Full Access users of this access level by default are:
  • Allowed to view, use, create and modify customers across all business units (of any level, including parent).
  • Allowed to view, use, create and modify explicit/implicit records across all business units (of any level, including parent).
• Normal Access users of this access level by default are:
  • Allowed to view, use, create and modify customers across all business units (of any level, including parent).
  • Allowed to view, use, create and modify explicit/implicit records of their own and child business units (excluding parent).
  • Not allowed to view, use, create and modify any explicit/implicit records of their parent or other business units.
    • Such actions on explicit/implicit records are allowed only via a sharing profile (based on the data access level).
• Restricted Access users of this access level by default are:
  • Allowed to view, use, create and modify customers of their own and child business units (excluding parent).
  • Allowed to view, use, create and modify explicit/implicit records of their own and child business units (excluding parent).
  • Not allowed to view, use, create and modify any customers of their parent or other business units.
    • Sharing customers between business units is allowed only via a sharing profile.
    • Creating and/or managing customers of such collaborated business units is not be allowed.
  • Not allowed to view, use, create and modify any explicit/implicit records of their parent or other business units.
    • Such actions on explicit/implicit records are allowed only via a sharing profile (based on the data access level).

Options available from the Actions menu: 

• Create new child (business) unit.
• Create new user. 

Contact 

 For each Business Unit you can provide contact details such as emails, phones, addresses etc. here.

Transaction Acquiring Points 

Define the Transaction Acquiring Points where a transaction event can actually take place. This could be an identification number of a POS, of a credit card machine or even a portal.  

Systemic Information 

Provide a Product Code Prefix which will be used to prefix all Products (SKU) owned by this business unit.

Sharing Profiles 

A sharing profile provides the ability to define which other business units a business unit (of normal or restricted access) it can collaborate with, and how its data can be accessed (viewed/used) based on the following business rules: contact category, contact KYC profile, accounts classification, accounts reward tier. By creating a sharing profile between two business units, then automatically all child business units of the collaborated business unit can access the data of the collaboration's business unit and its children (unless if another shared profile is explicitly created for such child business units).

Collaborated business units will be allowed to have access only to specific shared data, classified as follows:

• Customer Care contains all customer records that are related to Activities, Service Requests, Leads and Segmentation.
• Financial contains all customer records that are related to Financial Transactions (of any type), or Products.
• Reward contains all Reward Offers and all customer records that are related to Customer Events or Reward Transactions (of any type).

Data access between business units is classified into two levels (such levels are subject to hierarchy restrictions, with "view" as the lowest level and "use" as the the highest, while each higher level includes the functionality of each lower one).

• View level allows only the search and view capability of other business units customers and/or explicit/implicit records.
  • Customer information can be used only for searching and viewing allowed shared data.
  • Customer information cannot be viewed, created or modified.
• Use level allows the search, view and use capability of other business units customers and/or explicit/implicit records.
  • Customer information can be used for searching and viewing allowed shared data.
  • Customer information can be used for creating allowed shared data.
  • Shared data can be viewed, created, assigned or modified (processed).
  • Customer information cannot be viewed, created or modified.

Refer to Understanding network entity types for more information on specific entities.

Financial transactions between business units can be performed only if a sharing profile (allowing the 'use' functionality on financial transactions) exists for the business unit that the transaction will be issued against (and the issuer business unit is a collaborating business unit in a collaboration profile). Inventory management (warehouse) rules and restrictions should not be violated.

When creating a Sharing Profile, the Collaboration Scope can be for 'All Business Units' or 'Specific Business Units'. You can also define which data from the specific Business Unit can be shared based on the following restrictions:

• Data can be shared with the particular Business Unit based on certain data restrictions.
• Shared data can be accessed only when the specified customer conditions are met.

Automatic Collaboration Rules (ACR)

Automatic collaboration rules are used to assign a business unit to activities, service requests or leads, based on a set of conditions when creating or modifying an entry. For example, when a new lead for a potential rewards participant residing in London is created, it can be automatically assigned to a sales department responsible for the London area. For each rule you can define the conditions that must be met in order for the ACR to be assigned.

An automatic collaboration rule can be defined either to use the Business Unit as 'Assignment Information' (assigned to) or as 'Ownership Information' (owned by), for activities, leads or service requests. 

Assigning Based on Covered Geographical Areas

When you select to assign a business unit based on a geographical area, then the assignment will be done provided that the location of the customer is within the geographical area that is defined in the Business Unit.

You have to select the Business Unit that will be automatically assigned to newly created or modified entries based on the geographical area. E.G., Set up a rule that will assign new installation activities to installation departments (business units) within the vicinity of the customer. When searching for business units to add, the system will only retrieve those in the defined geographical areas.

Refer to 62566733 for more information.

Assigning Not Based on Covered Geographical Areas

When the business unit assignment will not be done based on the geographical area, then you must define how the assignment will be done. You have options to Automatically assign to a business unit using defined 'Entity Conditions' or 'Organisational Conditions'.

Set up Security Settings

Security management is the centre from which an organisation controls access to system modules and features and ensures the implementation of its business rules.

Access Control & User Permissions 

Access Control & User Permissions (ACUP) profiles are assigned to users and are used to define the modules/module settings a user can/cannot access and the data actions a user can/cannot perform against the business unit that was used to login into the system. The restricted module/module settings will not available from the user interface, while the restricted data actions will not be able to be performed (applicable on the user interface/Web API).

• Active Users - provides a list of users assigned to this profile. 
• Menu access - allow/deny access to specific menu options for the users of this profile. 
• Settings menu access - allow/deny access to specific System Settings configurations. 
• Module access - allow/deny access to module specific processes (areas include Common Processes, Additional Processes, Web API, Reports, Dashboards, Printouts). 

Audit Trail 

Audit trail settings define the rules for monitoring modifications and accessing on system records, either through the UI or the WEB API while modifying, deleting or removing information. Only one 'Active' instance of audit trail settings can be configured for each entity.

Entities and fields to be monitored are selected through audit trail settings. There are predefined options to Monitor all fields, or alternatively Do not monitor any field for the entity.  

Logging of the 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 Town) 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 town is monitored, an entry will be added when the town of an already defined address is updated.

Additionally any searching conducted in the system can be logged by activating the Log additionally any data access or retrieval (search) actions option.   

Conditional Security Restrictions (CSR)

Conditional Security Restrictions is a security-based mechanism that provides the ability to limit or enhance the default behavior of certain module attributes (by making them hidden, read-only (not-editable), mandatory or mask them with asterisks), module process and/or module printouts. A conditional security restriction can be applied across the software or to a specific business unit (if a parent business unit is specified, then the related condition security restriction will be applied on all child business units).

The restrictions are applied if conditions set on the business units and entities are met. CSRs also apply to all Web API calls. 

Some examples are:

• Fields: If the contact 'email address' is a restricted field then it may not be visible to call center agents.

• Processes: Restrict the creation of the 'New Subscription' fulfillment scope to call center agents.
• Printouts: Restrict wallet printouts after a wallet is cancelled.

Different restrictions are applied to fields, processes, and printouts.

	Restrictions
Type	Visible Entity will be visible	Editable Entity will be available for editing	Mandatory Entity cannot be saved if not defined
Fields
Processes
Printouts

Secret Keys 

Secret Keys can be used by Webhooks in order for third party systems to authenticate and receive internal data from CRM.COM. The authentication is made using the HMAC SHA256 algorithm based on the unique GUID key (secret key) and the related data field that is requested.

Secret Keys are used to generate unique (GUID) keys that can be used by external systems in order to retrieve data from CRM.COM. Webhook Keys are registered against a specific URL endpoint and can be used by Webhook processes in order for third party systems to authenticate and receive internal data.

Users 

A user is a physical entity or a system that can access and use CRM.COM modules either through the User Interface or Web API, while being subject to business network and security restrictions. Users are classified based on their role as follows:

• Admin Users
  • Admin users have access to the CRM.COM Cloud configuration (at the organisation level) only (do not have access to any CRM.COM applications/modules). Each deployment will have a single admin user (same as the Keycloak's admin user) and such a user will be used on behalf of the system for creating all related Keycloak records (e.g. back-office users, contact users).
• Back-Office Users
  • Super users have unrestricted access (authorised to access all areas and features of CRM.COM, without being affected by any network or ACUP restrictions).
  • Normal users perform day to day tasks and setup configuration (including access to CTI tools through the communication centre, a phone extension number is required).

Each user can be assigned to one or more business units with the respective permissions. 

The 'Actions' menu provides options to change the user password and to set the user as inactive.  

Refer to Additional Security Processes and Automations for other relevant functionality regarding Users. 

Applications 

Applications are used to define the different client applications (e.g. mobile app, external systems) that will consume the system's Web API for performing tasks of a configuration or business classification. For identifying a client application, a set of API Keys will be used for identification and security purposes. API Keys (publishable/secret) are used in order to authenticate an API request that is submitted into CRM.COM.

The 'Actions' menu provides options to 'Generate new Secret Key' or to 'Generate New Publishable Key'. 

62566733

Additional Network Processes and Automations

Cloning entities

The following entities can be cloned (copied) to save time, using the Clone option from the 'Actions' menu of the respective page.

• Sharing Profile - the data sharing restrictions and the data access conditions are also replicated in the new profile. 
• Automatic Collaboration Rules - all the business units, entity conditions and organisational conditions are replicated in the new rule.  
• Access Control & User Permissions - all Active Users, Menu Access, Settings Menu Access and Module Access settings are also replicated. 

Automatically assign business units based on geographical areas

Business units (or child business units) can be assigned automatically on new or existing records using common geographical areas. For example, the system can assign an installation team from the same area (e.g., US postcode MA20155) as that of the customer who requested the installation.  

Business Units are assigned to 62566733 and represent the teams responsible for performing the task. Business units are also assigned to 62566733 and represent the departments that own and have full access rights to the record.

Business Unit assignment

Business Units can be assigned automatically based on covered geographical areas provided the necessary set up has been completed through Automatic Collaboration Rules. Business Unit assignment is applicable for entities that require that a task is completed by a user. The following are 62566733:

• Activities
• Leads
• Service Requests

A business unit is automatically assigned to an entry provided that the customer is located within the covered geographical area. The system compares the address of the customer to the geographical areas covered by each business unit and assigns a business unit when a match is found (see table below). Automatic assignment cannot take place if more than one business units cover the area.

62566733 62566733

Providing service feedback

It is possible for customers to rate your company's services, (in this case business units services), by providing a rating as well as comments. Both rating and feedback is only possible through the WEB API.

The provided feedback can be viewed through the Foundation > Analytics > Feedback option. 

Understanding network entity types

An understanding of CRM.COM network entity types is essential for setting up network management.

All CRM.COM entities such as subscriptions, subscription types and activities can belong to multiple entity network types. For example, the Activities module is defined as an implicit viewing entity as well as an assignable entity. Entity entries inherit their functionality and access behavior from the network entity type.

Refer to the table below for a description of network entity types.

62566733  

Additional Security Processes and Automations

Accessing CRM.COM

Active users can log into the system from the CRM.COM login page using their username and password.

Logging in using different business units

Users that belong to multiple business units must select a business unit when logging in. A different set of data might be available for each business unit, depending on the user's permissions. 

Logging out

To log out from the system you need to click on the profile icon in the top right-hand corner of the screen and select Logout.

Handling invalid login attempts

To protect against unauthorized access, a user can be locked out after multiple consecutive invalid login attempts. This is handled by the IAM layer. 

62566733

Managing user settings and passwords

Password expiration  

User passwords may be valid only for a limited period of time, this is handled by the IAM layer. 

Changing user passwords

If the password of a user must be changed there are three ways to change a password:

• Before login (old password required)
  From the Login screen, click on Change Password, provide your username, current password and new password and confirm the new password. Click on SUBMIT.

• After login (old password required)
  
  1. Click in the user profile icon in the top right-hand side of the screen.
  2. Select Profile. 
  3. From the Actions menu, click on Change Password.
  4. Provide the Old and New Password (following the password rules shown in the tooltip), confirm the password and SAVE. 

• Changed by administrator (old password not required)
  1. Navigate to Configuration > System Settings > Set up Security Settings > Users. 
  2. Locate and View the user whose password you want to change in order to go to their data entry page.
  3. From the Actions menu, click on Change Password.
  4. Provide a New Password (following the password rules shown in the tooltip), confirm the password and SAVE.

Activating and deactivating user accounts

 Users must be in an 'Active' state to log into the system. Unused accounts can be deactivated (e.g., when an employee leaves the company).

1. Navigate to Configuration > System Settings > Set up Security Settings > Users. 
2. Locate and View the user whose password you want to change in order to go to their data entry page.
3. From the Actions menu, click on Set as Active or Set as Inactive.

Changing the 'State' for multiple users

The 'State' of multiple users can be updated simultaneously to either 'Active' or 'Inactive' from the Users summary (search) screen. Select the user account you wish to update by checking the box on the left of the user name and then select Actions > Change State > select the new state to be set and select Save from the modal.

62566733

  Create users in bulk using templates 

Save time when creating multiple users by importing them using a template (in xls, xlsx or csv format) either from a third-party system (if available), or manually. You can define common characteristics, such as  identical business units or access rights, by using pre-defined options (instead of providing identical values and settings in each new user's data entry page). This process is supported only for back-office users.

1. Select Actions > Generate Users in Bulk.
2. Either use an existing definition (select View) or create a New one. 
3. Provide a unique Name and Code, and an optional Description.
4. Select the predefined settings: System Language, Home Page Preference, and Password. 
5. Select the Business Unit and the Access control & user permissions to be set for all users.
6. Save when done. 
7. Select Actions and Download Template of your choice. 
8. Prepare the file.
9. When you are ready to proceed with the import select the Scheduling Settings tab at the bottom of the screen and select when you would like the process to run (Run now or Run on specific date/time).
10. Click on Actions > Submit, select and upload the file to be imported > Submit.
11. You will be able to view the results of the import using the Logs tab on the same screen. 

The user's passwords can either be user defined or auto-generated.

62566733

Web API keys

Web API Keys are an alternative means of authenticating users that access CRM.COM through Web API calls. Web API Keys are assigned to specific users in order to access a specific organisation.

Systemic Keys

Systemic Keys are Web API Keys for authenticating users and allowing access to CRM.COM through Web API calls from third-party systems. Authentication based on Systemic Keys is achieved using a Web API Key (user specific) and users are allowed to access any CRM.COM record.

Consumer Application Keys

Consumer Application Keys are an extension of existing Web API Keys for authenticating consumer-based applications, and allow access to CRM.COM through Web API calls from third-party systems. Authentication based on Application Keys is achieved using a Web API Key (user specific). Accessing CRM.COM data is restricted only to consumer-related information (based on the provided access token) and configuration data (including any configuration data that is not consumer related).

Identity and Access Management (IAM)

Identity and Access Management (IAM) is a service layer that operates above the instance level and is responsible for controlling who is authenticated (sign in; users and customers via an external service, such as Keycloak) and authorised (has access and permissions) to access and/or use any organisation's resources (via an internal process, using access control & user permissions profiles). IAM layer is responsible for housing and maintaining a pool of users/customers, along with their basic contact details, such as first name, last name, email address, phone number and any other identification attributes (customer identification mediums) that are required by the business (e.g. hashed credit cards) and a list of the instances/organisations that are authorised to access the system. In addition, the IAM layer leverages common practices and standard protocols, such as two-factor (EMAIL/SMS) and Google authentication, password expiration and one time password policies, OAuth2.0, OpenID and Single Sign-On.

IAM (Business Network, ACUP & Security) Token

A dedicated IAM mechanism is responsible for user authentication, where a token swap should take place between the IAM and the instance layer prior accessing the instance's resources. Such a process will result in a token (consisted by a business network token & a security token and kept in memory) that will be able to authorise users that have sufficient privileges (access rights) when performing a record action without invoking persistent layers each time. Based on the token, the following information should be able to be verified / provided:

• Identify and verify a user's data accessibility and allowance (in terms of business network actions and sharing).
• Identify and verify a user's record accessibility and allowance (in terms of record actions).
• Able to provide the user's business unit and determine whether the user can perform an action on records (based on their ownership).
• Determine whether the user can perform such record actions based on their access control & user permissions profile.

Users

A user is a physical entity or a system that can access and use CRM.COM modules either through the User Interface or Web API, while being subject to business network and security restrictions. Refer to Users for user roles and classifications. 

Contacts

Contacts are considered as the persons or companies that purchase/consume physical goods/services from the organisation and can have access only to their personal data.

Customer Identification Mediums

A customer identification medium is a name/value pair in the IAM micro-service that enable applications (e.g. external systems) to provide services and perform actions on their behalf. A customer identification medium should not be confused with an authentication service, as it's sole purpose is to provide an alternative mean of identifying a customer in an already established (authorised) communication between services or systems.

 62566733