Overview
Access tokens are used to identify and authenticate customers accessing CRM.COM from third-party systems, such as mobile applications or portals. Users can be identified through a code, such as a telephone number, or a combination of an identifier and passcode, such as a username and a four-digit PIN. Additionally access tokens allow the use of OTP one-time-passwords to grant single-session access.
Setting Up Access Tokens and Core Processes
Before you start using Access Tokens set up the system to reflect your own business needs.
Classifications
: Classifications are used to define the operational characteristics of access tokens. Besides the rules set in the Global Settings, rules can be applied to each classification regarding the automatic creation and deletion of tokens and the formatting of credentials. If a classification is not specified when a token is created, then the settings defined in the Settings for Access Tokens with No Classification are applied.
Settings for Access Tokens with No Classification
- Global Settings
Recommended additional setup
In addition to the Access Tokens specific settings the following may be configured for the Access Tokens to operate at its full capacity.
- Communications
Communication Templates: Configure templates including access token tags, to be forwarded by email or SMS when an access token is related to an accounts receivable or a rewards participant.
Queue External Systems: Configure an external system to handle communications, if communications are not handled directly (and sent by email or SMS) from CRM.COM,
Event-based Communication Definition : Configure specific events that trigger communications. E.g., a new passcode request from a customer will result in an email.
Using Access Tokens
Foundation / Access Tokens / Manage Access Tokens
Access tokens can be created manually through the access token Data Entry page or automatically. Tokens can also be created manually from accounts receivable page if the system is not configured to do so automatically.
Use EDIT from the Actions Menu to enter edit mode. A Access Tokens cannot be modified if its cancelled or completed already.
Important fields to consider
Classification: If there are configured classifications in the system you can select one of the classifications. Note that if a classification is selected then certain automations and rules may be different than the ones applicable on access tokens with no classification.
Authentication Code: A code used by customers to gain access to the system and to their personal data (instead of an identifier and passcode)
Identifier: A string of characters used to identify the customer (username).
Passcode: A code used to authenticate the identifier.
Accounts receivable: The account linked with the specific access token and which can be edited only while creating a token.
Automatically create access token using email address and phone number
Access tokens can be automatically created either on creating a new account and providing a phone number or email address or on adding phone numbers or email addresses on existing accounts. The result of this would be for the customers to have an access token for each registered email address or phone number. It is possible to select how the email address or the phone number will be used; for example, you can set the email address to be used as the identifier or authentication code or on both of them.
Optionally you can set in which access token classifications the automation will be applied.
To activate the automation Enable Allow Creating and Updating Access Tokens Based on Email Address/Phone Number available in the Automation Settings section of the Global Settings
If the Automatic Creation Method of the identifier or authentication code of the selected classification (or of the definition where no classification is selected) is set to 'None', access tokens cannot be created using email or phone numbers.
As the customer can register multiple email addresses and phone number you might wish to control the number of access tokens generated for each account. In such case, you can provide Maximum Number of Access Tokens per Accounts Receivable which is available in the Accounts Receivable Settings of Global Settings, while you can also enforce the creation of at least one access token per account by enabling Always Require at Least One Access Token per Accounts Receivable.
Creating access tokens with no identifier and pass code
It is possible to create access tokens that will only have an authentication code. This is particularly useful in case where you would like to provide access without providing username and password but a single field. For example, credit card number or phone number. In this case the authentication code will be solely used to provide access, whereas you would like to include both identifier and pass code in case that you will be using access tokens to gain access to the system through a web portal or a mobile app.
To allow access tokens to be created just be using authentication code enable option 'Allow Creating Access Tokens with No Identifier and Pass Code' available in the Automation Settings of the Classifications or the Settings for Access Tokens with No Classification
Defining Identifier, Pass Code and Authentication Code associated settings
Identifier, pass code and authentication codes can follow certain formatting settings which are applicable to your line of business. It is also possible to differentiate the formatting settings depending on the access token classifications.
More specifically you can define the following settings for each
Automatic Creation Method: Whether the identifier is generated programmatically as a Unique Auto-Generated Number (numeric string) or Unique Auto-Generated ID (alphanumeric string) or not automatically (None).
If None is selected, then the Format field becomes available, with the following options:
- Email Address
- Number
- Free Text (no formatting restrictions)
Minimum Length: The number of alphabetical (a-z), numerical (0-9) or special characters required for the identifier.
If the Format is set to 'Free Text' or 'Email Address', the minimum number of alphabetical characters and other special characters can also be specified.
In case of pass codes when the Automatic Creation Method of passcodes is set to None (i.e. not generated automatically), only super users can manually set passcodes when creating or editing tokens (regular users cannot).
The passcode will be automatically generated using the format restrictions set here (in case of regular users)
The above settings can be defined in the respective sections of Classifications or Settings for Access Tokens with No Classification.
Deleting an access token
'Not Effective' access tokens that are no longer required can be deleted as long as they are not associated to an accounts receivable. This can be done manually, by using DELETE from the Data Entry page Actions menu.
Automatically delete if no association exists
Automatic deletion of access tokens is also possible when removing an access token from an accounts receivable or terminating the associated account.
To activate this feature enable the 'Delete Access Tokens on Removing the Last Entity Association' in the Automation Settings of the Classifications or the Settings for Access Tokens with No Classification
Automatically delete 'Pending Verification' access tokens
Access tokens which are in a Pending Verification state can be automatically deleted if after a number of days they have not been verified.
To activate this process enable 'Automatically delete Access Tokens that are under Pending Verification' and provide the number of days required in the Accounts Receivable Settings tab of the Access Tokens Global Settings
Verifying an access token
Access tokens can be configured to require verification before customers activate them for use. The verification process takes place when:
- new access tokens are created through the accounts receivable page
- an existing access token is associated with an accounts receivable.
Tokens are verified using a code sent by the system (by email, SMS, or mobile app) to the customer. If the code is lost, it can be requested by the customer and resent by the system. An access token is in a 'Pending Verification' life cycle state until it is verified. Once verified, its state becomes 'Effective', the token is activated and it can be used by the customer for login.
To configure the system to support the verification process enable the Require Verification available in the Global Settings. You can select to only require verification for specific classifications.
Verification codes must be directly sent to customers so that they can use to verify their registration. To complete the process:
- Create a communication template including an access token verification code tag that will be replaced with the verification code generated by the system.
- Set up event-based communication to send an email or SMS using the communication template each time an access token is associated with a rewards participant or accounts receivable by enabling one of the following events:
- On Resetting Verification Code of an Accounts Receivable Access Token
- On Creating an Access Token that Requires Verification
Updating the life cycle state of an access token
The life cycle state of an access token can be set to 'Effective' or 'Not effective'. An 'Effective' token indicates it can be used by customers to authenticate themselves in CRM.COM. The life cycle state can be toggled by the user from the Actions menu.
Setting a pending verification token to effective
Automatically update the life cycle state of an access token to 'Effective' when an access token in a 'Pending Verification' state is verified.
Setting an access token to Not Effective
If an access token is removed from an accounts receivable or its associated accounts receivable is terminated then the life cycle state can be automatically changed to Not Effective.
To activate this automation enable the 'Set Access Tokens as Not Effective on Removing the Last Entity Association' in the Automation Settings of the Classifications or the Settings for Access Tokens with No Classification
Resetting a passcode
Passcodes are similar to passwords. Lost user passcodes can be reset automatically and replaced with an auto-generated passcode, or manually (complying with the formatting regulations set in the active access token definition or classification). Reset passcodes can be sent to the customers by email or SMS.
To reset a passcode to an auto-generated string and communicate with the customer:
- Click on Reset Passcode from the Data Entry page Actions menu to generate a new code.
- Create a communication template including the access token passcode tag that will be replaced with the passcode generated by the system or provided by the user.
- Set up event-based communication definitions to send an email or SMS using the communication template whenever a passcode is reset on an access token. Enable 'On Resetting Pass Code of a Rewards Participant Access Token' or 'On Resetting Pass Code of an Accounts Receivable Access Token'.
To manually reset the passcode, EDIT the access token and update it (instead of using the Reset Passcode action). Note that only super users are allowed to manually edit the passcode. Additional to the super user prerequisite the Automatic Creation Method of the passcode must be set to 'None'.
Additional Processes and Automations for Access Tokens
Using credit card number for identification
Credit cards can be used to gain access to data of specific customers to CRM.COM. In this scenario customers would use their credit cards to be identified in CRM.COM while performing a customer event
Upon creating a customer event (purchase or achievement) the access token credit card number is used to identify the customer for which the event is created for. If set up accordingly, the Payment Medium Brand and Type are set automatically on the customer event.
- It is important to note that the credit card number is kept in an encrypted format in the access token
- The last 4 digits can be viewed
- The authentication and identification of a customer upon creation of an event is only available through the WEB API
To use credit cards as authentication code, an access token classification must be set up. In the authentication section of the Access Token Classification make the following sElection:
- Automatic Creation Method: None
- Format: Credit Card
- Require Payment Medium Brand and Type on creating Customer Events: Select whether payment medium brand and payment medium type are required
- If enabled provide the default values for Payment Medium Brand and Type
Using One Time Passwords (OTP)
Select whether customers can gain access to their CRM.COM data using a one-time password (OTP) instead of an authentication code, or an identifier and passcode. An OTP is valid for only one login session or transaction, on one device. OTPs are only available for access tokens with a classification.
If you would like to enable the use of OTPs then enable under One-Time Password Settings section available at Classifications
If an OTP is supported then its Validity Period must be defined which can either be seconds or minutes
Handling invalid login attempts
To protect against unauthorized access, a customer 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, customer access to the system is denied for the duration of a configurable lockout period. The customer is allowed to log in again when the lockout period ends or is canceled by a super user.
To enable invalid login attempts configure the Invalid Authentication Policy available in the Global Settings and Classifications. Provide the following information
- Invalid Login Attempts: Maximum number of attempts, allowed within a defined period.
- Period Within X Minutes: If the maximum number of invalid login attempts is registered within the supplied value (minutes) the customers will be locked-out.
- Lock-out Time After Invalid Login Attempts (in Minutes): The time that must pass before the customer can try and log in again.
Canceling the lockout period
Super users can reset access to the system by canceling the lockout period.
- Navigate to Manage Access Tokens and go to the user's Data Entry page.
- From the Actions menu, click Cancel Lock-out Period.
Communicating an access token
Communicating token credentials can be crucial. Customers use access tokens primarily to gain access to CRM.COM, through portals or mobile apps. The process of generating and communicating tokens is automated.
When a new customer is registered through an external system, an access token and its details are communicated to the customer.
Set up event-based communication definitions to automatically email or SMS customers when specific events associated with access tokens occur. The following events are available:
On Assigning to an Accounts Receivable
On Resetting Pass Code of an Accounts Receivable Access Token
On Resetting Verification Code of an Accounts Receivable Access Token
On Auto-generating Pass Code of an Accounts Receivable Access Token
On Creating an Access Token that Requires Verification
On Verifying an Access Token
Communication templates including access token tags (text to be replaced with values specific to the token) can be used in the definition and sent to the customer when the event occurs.
Manual communications (including tags) can also be created and sent from the communications Data Entry page. Tags related to actions can be used as long as the access token is listed in the 'Referring To' entities. Tags can be selected by typing '#'.
Refer to the Communications manual for a comprehensive list of access tokens tags.
Real Time Business Flows
Scenario
Aluxsat Co. has created a mobile app for customers participating in its loyalty scheme. Customers can register through the app by using their email address. Once registered, the customers receive a verification code that they must provide through the app, to log in and gain access to the system.
Solution
The mobile app must be integrated with CRM.COM using the available CRM.COM WEB APIs.
Configuration
Communication template
A communication template should be set up to communicate with the customer whenever an access token is related to a rewards participant. The communication template media should be set to 'Email' so that when the communication is created, verification codes are delivered to the customer's inbox.
Dear #accounts_receivable.name
Welcome to our family!
Please use the following code to activate your account: #access_token.verification_code
Once the account is activated please use the following information to access your personal account.
Access Token Number: #access_token.number
Access Token Identifier: #access_token.identifier
Access Token Passcode: #access_token.pass_code
Settings for Access Tokens with No Classification
- Identifier: format email address
- Passcode: define the required restriction
- Automation: Select 'Allow Creating Access Tokens with No Identifier and Passcode'
Global Settings
- Allow Creating and Updating Access Tokens based on Email Address: Enable
- Require Verification: Enable
Event-based communication
- Select 'On Assigning to an Accounts Receivable
- Select the created communication template that includes the #access_token.verification_code tag (to be replaced by the generated verification code).
Using the verification code
When a new customer registers through the mobile app, CRM.COM will:
- Create an access token in a 'Pending Verification' life cycle state.
- Generate a verification code and send it to the customer.
Once the customer enters the verification code using the mobile app, the life cycle state of the access token will change to 'Effective', prompting the customer to log into the mobile app using the new account.
On this page
For the developer
Check out the Access Tokens WEB API for a complete list of actions available used to integrate CRM.COM to external systems
Release news
Check out a full list of CRM.COM features available per release.
Check out upgrade notes to find out what needs to be done to upgrade from your current release to the latest release of CRM.COM.