Example call flow for the data actions integration


Note: This article applies to the Adobe, AWS Lambda, Google, Microsoft Dynamics 365, PureCloud, Salesforce, web services, and Zendesk data actions integrations.

The following examples are inbound call flows that use static actions with the data actions integrations.

In this example call flow, the IVR routes interactions based on information that the integration retrieves from Adobe with the custom action Get Entity from Adobe Experience Platform.

  1. In the task called Query Adobe, the Call Data Action looks up the ANI in Adobe with the custom action Get Entity from Adobe Experience Platform. The integration returns information from Adobe about the person associated with this phone number.
    Note: Call.Ani typically returns a string that includes tel:. For phone numbers without the tel: prefix, use toString(toPhoneNumber(Call.Ani)) instead of Call.Ani.
  2. If the Call Data Action succeeds, Architect sets the caller’s name and transfers to the Existing Customers queue.
  3. If the Call Data Action fails or times out, Architect transfers the call to the New Customers queue.

Click image to enlarge.Example call flow for the Adobe data actions integration

For more information about creating call flows, see Use data actions in Architect.

For more information about the integration, see About the Adobe data actions integration.

In this example call flow, the IVR plays an audio message that asks the caller to pick a number between 0 and 9. The call flow sends the number to an AWS Lambda function to determine if the caller picked the correct number. For more information, see Example AWS Lambda function for Architect call flows.

  1. In the task called Collect Input, the IVR asks the caller to pick a number between 0 and 9.
    1. If the caller picks a number, then Architect proceeds to the Call Data Action. (See step 2.)
    2. If the caller fails to pick a number between 0 and 9, then Architect plays an audio message and disconnects.
  2. In the task called Call Data Action, Architect sends the caller’s selection to an AWS Lambda function using the data action.
    1. If the AWS Lambda function executes and returns the number, Architect then proceeds to the decision tree. (See step 3.)
    2. If the AWS Lambda function does not returns the number, then Architect plays an audio message and disconnects.
  3. In the decision tree, Architect checks to see if the number that the caller selected is 5.  
    1. If the number is 5, then Architect plays audio indicating that the caller won.
    2. If the number is not 5, then Architect plays audio indicating that the caller did not win.

Click image to enlarge.

Example call flow for AWS Lambda data actions integration

For more information about creating call flows, see Use data actions in Architect.

For more information about the integration, see About the AWS Lambda data actions integration.

In this example call flow, the IVR routes interactions based on information that the integration retrieves from Google with the custom action Get Customer Data from Google.

  1. In the task called Query Google, the Call Data Action looks up the ANI in Google with the custom action Get Customer Data from Google. The integration returns information from Google about the person associated with this phone number.
    Note: Call.Ani typically returns a string that includes tel:. For phone numbers without the tel: prefix, use toString(toPhoneNumber(Call.Ani)) instead of Call.Ani.
  2. If the Call Data Action succeeds, Architect sets the caller’s name and transfers to the Existing Customers queue.
  3. If the Call Data Action fails or times out, Architect transfers the call to the New Customers queue.

Click image to enlarge.Example call flow for the Google data actions integration

For more information about creating call flows, see Use data actions in Architect.

For more information about the integration, see About the Google data actions integration.

In this example call flow, the IVR routes interactions based on information that the integration retrieves from Microsoft Dynamics 365 with the data action Get Contact By Phone Number.

  1. In the task called Query Microsoft Dynamics 365, the Call Data Action looks up the ANI in Microsoft Dynamics 365 with the data action Get Contact By Phone Number. The integration returns information from Microsoft Dynamics 365 about the person associated with this phone number.
    Note: Call.Ani typically returns a string that includes tel:. For phone numbers without the tel: prefix, use toString(toPhoneNumber(Call.Ani)) instead of Call.Ani.
    1. If the Call Data Action succeeds, then Architect proceeds to the decision tree. (See step 2.)
    2. If the Call Data Action fails or times out, then Architect transfers the call to the Customer Service Queue.
  2. In the decision tree, Architect checks to see if the state in the caller’s contact record is California.
    1. If the state is California, then Architect transfers the call to the California Queue.
    2. If the state is not California, then Architect transfers the call to the Non-California Queue.

Click image to enlarge.

Example call flow for Microsoft Dynamics 365 data actions integration

For more information about creating call flows, see Use data actions in Architect.

For more information about the integration, see About the Microsoft Dynamics 365 data actions integration.

In this example call flow, the IVR routes a caller to a particular queue based on information that the integration retrieves from the Platform API with the static action Get Estimated Wait Time.

  1. In the task called Query PureCloud, the Call Data Action uses the static action Get Estimated Wait Time to retrieve the estimated wait time. The static action Get Estimated Wait Time is associated with the installed integration PureCloud Data Actions.
    1. If the Call Data Action succeeds and the estimated wait time is less than 5 minutes, then Architect transfers the caller to the Normal Inbound Queue.
    2. If the Call Data Action succeeds and the estimated wait time is more than 5 minutes, then Architect transfers the caller to the All Hands Queue.
    3. If the Call Data Action fails or time outs, then Architect transfers the caller to the Normal Inbound Queue.
  2. If transfers are successful, then the flow ends. If all transfers ultimately fail, then Architect disconnects the call.

Click image to enlarge.
Example call flow for the PureCloud data actions integration

For more information about creating call flows, see Use data actions in Architect.

For more information about the integration, see About the PureCloud data actions integration.

In this example call flow, the IVR routes interactions based on information that the integration retrieves from Salesforce with the data action Get Contact By Phone Number.

  1. In the task called Query Salesforce, the Call Data Action looks up the ANI in Salesforce with the data action Get Contact By Phone Number. The integration returns information from Salesforce about the person associated with this phone number.
    Note: Call.Ani typically returns a string that includes tel:. For phone numbers without the tel: prefix, use toString(toPhoneNumber(Call.Ani)) instead of Call.Ani.
    1. If the Call Data Action succeeds, Architect proceeds to the decision tree. (See step 2.)
    2. If the Call Data Action fails or times out, Architect transfers the call to the Customer Service Queue.
  2. In the decision tree, Architect checks to see if the state in the caller’s contact record is California.
    1. If the state is California, Architect transfers the call to the California Queue.
    2. If the state is not California, Architect transfers the call to the Non-California Queue.

Click image to enlarge.

Example call flow for Salesforce data actions integration

For more information about creating call flows, see Use data actions in Architect.

For more information about the integration, see About the Salesforce data actions integration.

Tip: For the web services data actions integration, use static actions as templates to guide you in creating custom actions. For more information, see Edit, copy, or delete a data action and Create a custom action

In this call flow, the IVR plays an audio message based on information that the integration retrieves from a weather service with the static action Current Weather.

  1. In the task called Query Weather Service, the Call Data Action uses the static action Current Weather to retrieve the current weather for a particular zip code from the weather service. The static action Current Weather is associated with the installed integration Web Services Data Actions.
    1. If the Call Data Action succeeds, then Architect plays an audio message that contains the current temperature for the zip code that the weather service returned.
    2. If the Call Data Action fails, then Architect plays an audio message about not being able to determine the current weather for the zip code.
    3. If the Call Data Action time outs, then Architect plays an audio message about the weather service timing out.
  2. Architect disconnects the call.

Click image to enlarge.
Example call flow for the web services data actions integration

For more information about creating call flows, see Use data actions in Architect.

For more information about the integration, see About the web services data actions integration.

In this example call flow, the IVR routes interactions based on information that the integration retrieves from Zendesk with the data action Get User By Phone Number.

  1. In the task called Query Zendesk, the Call Data Action looks up the ANI in Zendesk with the data action Get User By Phone Number. The integration returns information from Zendesk about the person associated with this phone number. 
    Note: Call.Ani typically returns a string that includes tel:. For phone numbers without the tel: prefix, use toString(toPhoneNumber(Call.Ani)) instead of Call.Ani.
    1. If the Call Data Action succeeds, then Architect proceeds to the decision tree. (See step 2.)
    2. If the Call Data Action fails or times out, then Architect transfers the call to the Customer Service Queue.
  2. In the decision tree, Architect checks to see if the state in the caller’s user record is California.
    1. If the state is California, then Architect transfers the call to the California Queue.
    2. If the state is not California, then Architect transfers the call to the Non-California Queue.

Click image to enlarge.
Example call flow for Zendesk data actions integration

For more information about creating call flows, see Use data actions in Architect.

For more information about the integration, see About the Zendesk data actions integration.