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 st this up:

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

Setting up your Network

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

Communities

A 'community' is the representation of an organization. Businesses with many partners can be split into two communities, one representing the business and the other grouping all of its partners.  For each community, a 'company' contact information is created. Through the Community you can provide contact details such as emails, phones, addresses etc.

You need to create a community to proceed into creating the rest of the groups (departments, partners etc.)

Groups

Groups define the different departments within a company, such as Production, Sales, and Support, along with a single contact information that can be designated as its representative. (can also be used for creating partners)

On saving the group a 'company' contact information will be created. If you would like to keep additional contact details for the group such as emails, phones, addresses you can do so directly from the group page. (this information will not be kept on the contact information)

Groups can be automatically assigned as the 'owned by group' of an entity. Refer to Automatically assign units and groups on entities for information on how to set this up.

Creating internal groups

When creating an internal group you need to set through the classification which should be set to Internal as well as the community that it should belong to. If the group you are creating will be associated to a single Unit, you have the option to automatically create it by enabling 'A single unit will be created and assigned to the Group automatically'

Creating partners

Partners define external organizational units that have a financial agreement with the company therefore each partner is associated to an accounts receivable. If the partner is one-man-show then you only need to associate a single unit to it in which case you can enable through 'A single unit will be created and assigned to the Group automatically' If the partner is more like a partner group then you have two options depending on the business. You can have each partner unit that belongs to the group to have its own accounts receivable and handle its own financials or create a single account receivable on the partner group level which will handle the financials of all partner units under it. Use Set Accounts Receivable on  and select whether it will be the Unit or the partner.

Collaboration between communities

Community collaboration profiles are used when groups belonging to different communities share data.  

The community you will provide will share all of its groups' data with the rest of the communities you will define. You have the option to define all communities or specific communities by providing them through Community is allowed to collaborate and share data with

Inward Collaboration list gives you a list of communities which share their data through with this community.  If you are planning to create collaboration between groups which do not belong to the same community then it is mandatory to define community collaboration first.

For more information on collaboration, refer to Collaboration between Groups.

Collaboration between groups

CRM.COM data is subject to different levels of access.  The level of access depends on the group (or business department) of the user. For example, if Mary belongs to Marketing Group then only users belonging to Marketing Group will have access rights to Mary entries. As with communities collaboration of a group can be designated to be with all groups or with specific groups which can be defined through 'Group is allowed to collaborate and share data with'

Data can be shared between groups (departments) by setting up group collaborations and defining restrictions on the following actions:

• View : View entries
• Modify: View and modify entries
• Assign: View modify and assign entries
• Search/Share :Defines whether the group, unit or user will be available in (Data Entry page) search results and for use as a value in group-related fields of various modules. E.g., to use as the 'Owned by Group' of a subscription, 'Assign to Unit' for an activity, 'Assign to User' of an activity

Restrictions on each action are defined by using different access level.

• None: The action is not allowed.
• All Privacy Levels: The action is allowed on records of any privacy level.
• Specific Privacy Level Groups: The action is allowed on records with a privacy level which belongs to one of the specified privacy level groups. More than one privacy level group can be specified.
• Specific Privacy Levels: The action is allowed on records with a privacy level which is equal to one of the specified privacy levels. More than one privacy level can be specified.

Refer to Privacy Level for more information

Inward Collaboration list gives you a list of groups which share their data through with this community.

Units 

A unit represents a team within a department such as team leaders and operators or could be partners under the umbrella of a partner group.  For each unit, a single contact ('person' or 'company' contact information) can be designated as the representative.

On saving the unit a 'company' contact information will be created. If you would like to keep additional contact details for the unit such as emails, phones, addresses you can do so directly from the unit page. (this information will not be kept on the contact information) 

Units can be automatically assigned as the 'Assign to Unit' of an entity. Refer to Automatically assign units and groups on entities for information on how to set this up.

Creating internal units

When creating an internal unit set the classification to internal and select a group under which it belongs

Creating partner units

When creating a partner unit set the classification to partner and select a partner group under which it belongs. Depending on how the partner group is configured, an account may be automatically created and associated to the unit

Setting up your Users

User Authentication Settings

User authentication settings define policies regarding user credentials, login authorization and authentication.  through the settings you can define

• Password policy: Define the rules to be followed when creating a password and whether passwords should expire after some time
• Username policy:Define the rules to be followed when creating a username
• Authentication policy: Enable to import users from AD/LDAP and use their credentials during the authentication process. For more information refer to LDAP
• Invalid Login Attempts policy: Define rules to be followed when a user fails to login the system multiple times.  If a policy is not specified only super users can log into the system. Refer to Invalid login attempts for more information
• IP authorization Policy: Define restrictions in the form of IP addresses from which access to CRM.COM is Allowed or Denied. The State of an IP Authorisation Rule can be 'Active' or 'Inactive' (default). Inactive rules are disregarded while active rules must include at least one IP address. Unless the policies define otherwise, the settings apply to all user accounts. Refer to Handling Anauthorised Access for more information

User templates

User templates hold information (related to Users) that is not personalized and therefore can be applied to manually or automatically create Users.

Web API keys

Web API Keys are an alternative mean 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 organization.

Systemic Keys

Systemic Keys are Web API Keys for authenticating users and allow 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) and an Access Token credentials (consumer 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 are not consumer related)

Users

A user is a physical person or a system that can access and use CRM.COM either through the User Interface or Web API 

The system supports the following types

• Superusers have unrestricted access (authorized to access all areas and features of CRM.COM, without being affected by any Network or Security restrictions)
• System users are subject to security and network access rights
• Developer users are considered as General Users that additionally can access the development tools available through the UI
• CTI enabled users are considered as General Users that additionally are able to access the CTI tools (also assigned with a phone extension number), which are embedded in CRM.COM and are available through the communication center screen

Information defined on the user is related to the access (Units) and security rights (security profile), as well as preferences such as the language the system will be viewed with (system language) and the language translations will be available on mouse over (Native language)

Setting up Security

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

Setting up user security access - 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 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. 

Setting up data security

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

In each PLAR you have the option to define whether the priority level will be inherited from the account or contact information associated with the entry. if its not inherited then you must explicitly define the priority level. You can also define a Priority Order which will determine 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. If the priority is inherited then the entry will take it either from the contact information or the 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. Refer to Network Entities for more information.

In the same rule you can define multiple areas of the system, (accounts receivable, communications, service requests) and for each area you can define the conditions that must be met in order for the privacy level to be assigned.

Keeping an 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.

Settings up data automatic assignment 

Automatic collaboration rules are used to assign activities, service requests, leads or jobs to a specific user or unit 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 marketing department call agent responsible for the London area. For each rule you can define the conditions that must be met in order for the ACR level to be assigned.

You can also define a Priority Order which will determine 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.

Assigning based on Geographical Area

When you select to assign a unit or user 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 Units.

You have to select the Users and units that will be automatically assigned to newly created or modified entries. E.g., Set up a rule that will assign new installation activities to installers within the vicinity of the customer.  When searching for units or users to add, the system will only retrieve those in the defined geographical areas (A unit without a defined geographical area cannot be added to the ACR).

Refer to Automatic assignments of groups and units based on geographical areas for more information

Assignments not based on geographical areas

When the unit assignment will not be done based on geographical area then you must define how the assignment will be done. You have options to assign to

• Specific: Specify an Assigned to Unit and/or an Assigned to User for the entry.  Users must belong to the defined unit.
• Logged In User's Unit: The entry will automatically be assigned to the unit of the logged in user.
• Logged In User: The entry will automatically be assigned to the logged in user and their unit.

Setting up system security access

Conditional Security Restrictions (CSRs) are used to restrict the visibility of certain system features (processes, printouts) 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. 

Some examples are:

• Fields: The address of a contact with high privacy level is not visible to call center agents.

• Processes: Restrict the creation 'New Subscription' fulfilment scope jobs to call center agents.
• Printouts: Restrict wallet printouts after a wallet is canceled.

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

 Back to top

Additional Network Processes and Automations

Cloning groups and collaborations

Groups and collaborations (between groups and between communities) can be cloned to save time.

When a group is cloned all of its attributes are automatically replicated in the new group (such as its classification (e.g., partner group), the number of its units, and the number of accounts of each unit).

When a community collaboration is cloned, all communities that the community collaborates with are replicated in the new collaboration profile.

When a group collaboration is cloned, all of the groups that the group collaborates with and the collaboration settings are replicated.

To clone any of the above entities, use Clone (entity) from the Actions' menu of the respective page and provide the required information.

Automatic assignments of groups and units based on geographical areas

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

Units are assigned to 'assignable entities' and represent the teams responsible for performing the task.  Groups are assigned to 'explicit viewing access entities' and represent the departments that own and have full access rights to the record.

Unit assignment

Units can be assigned automatically based on covered geographical areas provided the feature is enabled through Units. Unit assignment is applicable for entities that require that a task is completed by a user. The following are Assignable Entities:

• Activities
• Leads
• Service Requests
• Jobs

A 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 unit and assigns a unit when a match is found (see table below).  Automatic assignment cannot take place if more than one unit covers the area.

Group assignment

'Owned by Group' of entries can be based on covered geographical areas if the feature is enabled through Groups. 

'Owned by Group' is only associated with explicit viewing access entities (entities for which the owner group is defined on the record). A group will automatically be set as the 'Owner' of entries provided that the customer is located within the covered geographical area.

The system will compare the address of the customer to the geographical areas covered by each group and will assign a group when a match is found (see table below).

In each case, the system will compare the customer address, according to the table below, against the covered geographical areas of each group and will assign a group when a match is found. If more than one group covers the area the assignment is not automatic.

 Back to top  

Providing service feedback

It is possible for customers to rate your company's services, (in this case unit service), 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 Display Feedback summary page available under Analytics.

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

Back to top  

Additional User 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 under different units

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

Logging out

To log out from the system you need to click on the account icon at the bottom right of the screen and select Logout.

Protecting against unauthorized access

Controlling the IP addresses from which users can log in protects system data. You can define rules that include IP addresses, ranges of IP addresses or IP patterns from which access is allowed or denied. Each IP authorization rule can be applied to specific organizational units (users, units, groups or communities) by configuring the User Authentication Settings.

Handling invalid login attempts

To protect against unauthorized access, a user can be locked out after multiple consecutive invalid login attempts.

It is possible to define the maximum number of failed attempts allowed within a specified period. If the number is reached, user access to the system is denied for the duration of a configurable lockout period. The user is allowed to log in again when the lockout period ends or is canceled by a super user.

To set up the rules go to  User Authentication Settings.

Cancelling the lockout period

Super users can reset user access by canceling the lockout period. 

1. Navigate to Manage Users and go to the user's Data Entry page.
2. From the Actions menu, click Cancel Lock-out Period.

Back to top

Managing user settings and passwords

Password expiration  

User passwords may be valid only for a limited period if defined in the password Policy of the user Authentication Settings. In such case, upon login, the system provides users with a seven-day expiry notice, so that a new password can be selected. The user cannot select the same password.

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. Navigate to user Management and go to the user information Data Entry page.
  2. From the Actions menu, click on Change Password.
  3. 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 Manage Users, select the user whose password you want to change to go to their Data Entry page.
  2. From the Actions menu, click on Change Password.
  3. Provide a New Password (following the password rules shown in the tooltip), confirm the password and SAVE.
     
     

Changing user settings

User settings define access to system data, system areas, and CTI.  User settings must be defined through the respective action accessible to super users exclusively. The settings are:

• Super Users have access to all areas and features, including Network and Security Management, and can view more elaborate error messages.  Super users are appointed by other super users.
• Developers have access to development tools embedded in CRM.COM, available in all Summary pages, Data Entry pages, the analytics section and dashboards. Developers are granted the same Network Management and Security Management permissions as general users.  Developers are appointed by super users. 
• CTI Enabled users have access to the embedded CTI tools, accessible through the communication center screen.

To change the settings:

1. Navigate to Manage Users and select the user whose settings you want to update to go to their Data Entry page. 
2. From the Actions menu, click on Change Settings, enable or disable settings 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 Manage Users and select the user whose state you want to update to go to their Data Entry page.
2. From the Actions menu, click on Set as Active /Set as Inactive.
3. Enable or disable settings and SAVE.

Changing the state and settings for multiple users

The settings and state of multiple users can be updated simultaneously using the respective action from the 'Manage Users' Summary page. Select the user account you wish to update by checking the box on the left of the entry and select the respective action from the Actions menu.

Back to top

Creating users in bulk with templates 

Save time when creating multiple users with common characteristics, such as identical access rights or email domain, by using pre-defined user templates (instead of providing identical values and settings in each new user's Data Entry page).

To use the utility you need to define the user template to be used and the number of users. The passwords and emails of the users to be created can either be user defined or optionally the password to be the same as the username and the email to be generated using the domain defined on the template.

Generating users in bulk 

1. Navigate to Generate Users in Bulk and provide the required information.
2. Go to the Users To Be Generated tab and click Create to generate the number of users defined in the Input Settings tab. 
3. Add more users if required.
4. Provide a 'Username', 'First Name' and 'Last Name' for each user.
5. Provide an 'Email' and 'Password' if those were defined as 'Fixed' in the Input Settings, otherwise select and click on the Set Email and Set Password actions, to generate users based on username and domain. 
6. Select users to Set as Active using the respective action.
7. Click on SUBMIT from the Top menu to generate the users.

Optionally if they are CTI enables you can provide the phone extension for each user.

Back to top

Managing LDAP accounts

 If you are an organization with numerous users and already use Microsoft's Active Directory (AD), you can import and map registered users from AD directly to CRM.COM.  This will allow you to:

• Authenticate users when logging into CRM.COM, using their AD credentials. 
• Inform users regarding AD password expiry.
• Prevent users from logging in once their AD password expires.

Once Active Directory users are imported:

• Map the AD users to existing CRM.COM users, or
• Create new CRM.COM users. 

A mapped AD account can also be un-mapped and remapped to a different CRM.COM account. 

Importing LDAP accounts

 To import Active Directory user accounts into CRM.COM:

1. Navigate to LDAP Integration and click on Import Users from the Actions menu.  Select a Security Group from the drop-down list in the Import LDAP Users modal.  
   
2. Click SUBMIT.
   
3. Imported users can be viewed at the LDAP Users tab. 

Mapping imported LDAP accounts

 Imported LDAP users available in CRM.COM can be mapped (one by one) to CRM.COM users. In order to map users, they must already be imported from AD, and they should not be mapped yet.

1. Navigate to LDAP Integration > LDAP Users tab. 
2. Select users to map.  
3. Click on Map from the Actions menu.
   
4. In the modal window, search for CRM.COM users to map with LDAP users.
5. Click SUBMIT.

Creating new CRM.COM users from imported LDAP accounts

 A CRM.COM user can be created for each imported LDAP user. In order to create CRM.COM users, AD accounts must already be imported from AD and they should not be mapped yet.

The bulk user creation process can be used to generate multiple users simultaneously instead of mapping one user at a time.

1. Navigate to LDAP Integration > LDAP Users tab.
2. Select the AD user accounts for which you want to create CRM.COM user accounts.
3. Click on Create Users from the Actions menu.
   
4. Follow the process described under generating users in bulk. 

Un-mapping LDAP accounts from CRM.COM users

 Users can be un-mapped and mapped to another CRM.COM account. Un-mapped AD users can no longer login to CRM.COM using AD credentials and must use CRM.COM account credentials. 

1. Navigate to LDAP Integration > LDAP Users tab.
2. Select the user to un-map.
3. Click on Map from the Actions menu. 

Active Directory password ageing warning

Active Directory (AD) user accounts can be managed through CRM.COM.  Upon login, the system provides users with an expiry notice, by retrieving the date from the AD.  Users update their passwords and the change is reflected in the AD.

Back to top

Additional Security Processes and Automations

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

Business Flows