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

Configuration / Foundation Application / Foundation Settings / Set up Access Tokens

Before you start using Access Tokens set up the system to reflect your own business needs.

Classifications Turquoise16pxfa-question-circle: 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 ClassificationTurquoise16pxfa-question-circle: You have the option not to use access token classifications at all, in which case all access tokens will be following the same business rules. In this case you can define all the operational characteristics applied on access tokens (i.e. formatting settings and generation method of identifier, passcode and authentication code etc.) here.
Global SettingsTurquoise16pxfa-question-circle: Access tokens are associated to an accounts receivable . (i.e. If a customer would like to access CRM.COM information through a mobile app or the portal, then they would be identified through their accounts receivable ). In the global settings of access tokens you can define automations and settings that define the relation between access tokens and accounts receivable.

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.

Back to top

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. An 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 from 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 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 process, 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:
1. On Resetting Verification Code of an Accounts Receivable Access Token
2. 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'.

Back to top

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

Back to top

Business Flows

Creating and Verifying an Access Token

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.

Glossary

CRM.COM Term	Description
One-time password (OTP)	A password that is valid for only one login session or transaction, on a computer system or other digital device. In CRM.COM, OTPs are used to authenticate access tokens and identify accounts receivables or rewards participants.
Communications	Log the interaction between customers and agents. Communications can support multiple communication media such as email, SMS, telephony, post, and others.
Accounts Receivable	A ledger of the financial transactions carried out between a company and its customers, such as invoices and payments.
Customer Events	Financial and marketing events performed by customers outside CRM.COM and registered in the system for additional processing and rewarding

FAQ

I would like to provide access to customers through a mobile app. Should I use authentication code or identifier and passcode

In this case you would need to create the combination of an identifier and a passcode to provide access. This for example would be the email address and a password.

When should I use authentication code instead of identifier and pass code?

Authentication codes are particularly useful in implementations where customers would be allowed to gain access to their information by just providing a single piece of information. For example a credit card number or a phone number.

I can't reset the passcode from the access token data entry page.Why?

To be able to manually update the passcode of an access token you need to be a superuser. If you are a super user and still can't make the update then check that the Automatic Generation Method for the passcode in either the Classification or Settings for Access Tokens without Classification is set to None.

If you are not a superuser you can reset the pass code bu using the respective action available in the Actions of the Access Token.

Make sure that the event based communication is set up accordingly so that the customer will receive an email or SMS with the updated passcode.

Useful Links

falseV4Manualfalselabel = "global" and space = "V4Manual"global

Browser not supported