Example call flow for the 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. 

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.

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 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 Genesys Cloud, 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 Genesys Cloud 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.

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

For more information about the integration, see About the Genesys Cloud 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.

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

For more information, 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.

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

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.

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.

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.

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.