Ask to Authenticate action

Prerequisites

Configure the Apple Messages for Business (AMB) platform integration and add the required OAuth settings in the Authentication section. The Ask to Authenticate action appears in digital bot flows only if you have configured authentication for the AMB integration. For more information about configuring authentication for AMB, see Configure ACD for Apple integrations.

Use the Ask to Authenticate action in digital bot flows to authenticate the bot participant during a messaging conversation.

Note: The Ask to Authenticate action is only available for Apple Messages for Business (AMB) and it appears only if you have configured authentication for the AMB integration. The action takes the failure path if you use it in any other unsupported channels.

Field	Description
Name	The label you enter here becomes the name of the action in the task editor.
Sign In Message	Enter the wording presented to the end customer when prompting to sign in using an authentication action. For example, “Please sign in so we can retrieve your order information.”
Success Message	Enter the message that the bot must send to the participant after the authentication is successful.
Authentication Completion Timeout	Set the timeout for how long that the bot must wait for the participant to complete the authentication. If the authentication is not completed within this time, then a No Input event is triggered. Click Increase or Decrease to adjust the timeout, or manually enter the timeout. You can set the timeout in days, minutes, hours, or seconds.
No Match	Enter the communication that the bot produces when the user’s input is not a valid match. Note: The bot returns the content from Settings > User Input > No Match Detected > No Match Apology, combined with the No Match communication.
Customize No Match	Enables the No Match Reprompts field. Use this option to create a list of no match prompts that incrementally occur when the bot receives No Match input events.
No Match Reprompts	When the bot receives a No Match input, the bot returns the communication in the No Match Reprompts collection that corresponds to the current number of No Match inputs received for that action. For example, the first No Match input triggers the bot to use the first No Match reprompt in the defined collection. The length of the No Match Reprompt collection overrides the maximum number of No Match retries that you define at Settings > User Input > No Match Detected > Maximum Number of No Match Retries for that particular action. For example, if you define two reprompts in the collection, the bot retries twice. An empty collection turns off No Match retries. Note: The bot returns the Settings > User Input > No Match Detected > No Match Apology combined with the corresponding No Match Reprompt communication.
Default No Match	Enables the default No Match field. Use this option to define a single No Match prompt that the bot produces when it receives No Match input events.
Failure Outputs	These outputs allow the flow author to map the results of any resulting `errorType` and `errorMessage` variables when the action takes the failure path. errorType: A non-empty string that contains the type or category of the error. errorMessage: A non-localized failure message. The string can be empty or NOT_SET. Notes: To expand or collapse the list of variables, click the arrow to the right of Failure Outputs. To display the list of allowable `errorType` values, hover over the information icon to the right of errorType.
Paths	Max No Inputs: Enable or disable the Max No Inputs path. When you enable this option, if the bot exceeds the maximum number of no input retries that you set for this action, then the flow follows this output path. Max No Matches: Enable or disable the Max No Matches path. When you enable this option, if the bot exceeds the maximum number of no match retries that you set for this action, then the flow follows this output path. Note: If you disable this path, then the flows that you configure for the output path are hidden, not deleted.

Best practices when configuring the Ask to Authenticate action

The following best practices help you in ensuring that the messaging channel supports the authentication request:

Before you add the Ask to Authenticate action, it is recommended that you identify whether the user’s device can handle the authentication request. The device capabilities are included within the participant data of a conversation. To confirm the device capability, you can use the expression, (FindString(Flow.deviceCapabilities,"AUTH") > 0), for example, in a Decision or Switch action before the Ask to Authenticate action. Check for the presence of either “AUTH” or “AUTH2.” If the flow executes the action with a device that does not support AUTH or AUTH2, then the action takes the failure path.
You can also use the Architect built-in variable, Session.Source, to identify the messaging channel type. For more information about this variable, see Architect built-in variables.