Inbound Flow

The inbound Architect Flow for Mindful Callback is typically a modification to the existing Flow used to process inbound calls. In the existing inbound Flow, you will need to add several steps to:

• Fetch the EWT and turn it into a phrase to play back to the caller.

• Check the EWT to make sure it is above a defined threshold before offering the callback option (EWT will be checked in Genesys but announced in Mindful).

• Verify that Mindful is available and ready to process callback requests.

• (Optional) Post data to Mindful Datastore.

• Transfer the call to Mindful

Open your existing Inbound Architect Flow (Admin > Architect). If you are starting a new Flow, first select "Inbound Call" on the Flows tab, then click Add. Add the blocks listed below and follow the steps to configure the inbound Flow.

Find Queue

The Find Queue block populates a special Queue-type variable containing the queue name and queue ID. The queue name and ID will be used later to send calls to the agent queue when needed.

Configure the Find Queue block as shown:

• Queue Name — Enter the name of the agent queue to be used for this Flow, and select the Literal mode to the right of the input field. Alternatively, you could use a variable here and use the Expression mode.

• Queue Result — Enter the variable Task.QueueName.

Call Data Action (retrieve OAuth token)

Add a Call Data Action block after the initial Find Queue block.

• Category — Select the OAuth Integration that was created earlier.

• Data Action — Select the Token Retrieval Data Action.

  

• Success Outputs — In the access_token field, assign the variable Task.access_token.

  

Call Data Action (Get Offer Decision)

Add another Call Data Action block on the success path of the Token Retrieval Data Action.

• Category — For this new Call Data Action block, select the Integration that contains the Get Offer Data Action.

• Data Action — Select the Get Offer Action created earlier.

  

• Call Target URL — Enter the offer-decision endpoint URL, including your Call Target ID.

• AuthToken — Assign the expression Task.access_token.

• Success Outputs — Assign Task variables to each of the outputs you would like to capture and evaluate.

  

Finally, add a Decision block to evaluate the Task.shouldOffer boolean value (and any other variables of interest returned by the API) before routing the call to Mindful for a callback offer or transferring the call directly to agents.

Call Data Action (Get Estimated Wait Time)

Next, use a Call Data Action block to invoke the Get Estimated Wait Time Action created earlier.

Configure this block as shown in the example:

• Category — Select the Integration for Genesys Cloud that you created in a previous step.

• Data Action — Select the Get Estimated Wait Time Action.

• Inputs > Queue_ID — Refer to the queue name variable configured in the initial FindQueue block by using the format Task.<QueueName>.id, as seen below. This will pass the queue id (which is required for the EWT query rather than the queue name) to the Data Action.

  
• Inputs > MEDIA_TYPE — Enter a literal value of call.
• Success Outputs > Estimate Wait Time in Seconds — Enter the variable Task.EWT.

Switch (check EWT value)

The next block (Switch) will check the EWT value obtained in the previous block. It will then route the call down different paths based on the value of the EWT.

You can configure the cases however you would like. In our example, we use three cases:

• Case 1 — The value of the EWT variable (divided by 60 for minutes) is less than 1 (so EWT is less than one minute).
• Case 2 — The value of the EWT variable is greater than 120 (so EWT is greater than two hours).
• Default Case: Neither Case 1 nor Case 2 are true (EWT is between one minute and two hours).

(Optional) Call Data Action (Datastore POST)

If you wish to use the Mindful Datastore to maintain call context, you will need a Call Data Action block to invoke the Datastore API's POST endpoint.

Configure this block as seen in the example:

• Category — Select the Integration for Mindful created earlier.

• Data Action — Select the Datastore POST Action.

• Inputs — Add entries for the Datastore URL, customer contact number, and auth token, as well as all items configured in your Data Set Template in Mindful Datastore.

  

  Remember that only DS_URL, DS_Auth, and DS_ContactNumber are required. All other fields shown here are examples. For each input, provide an existing variable or literal value. The following guidelines apply to the required inputs:

  • DS_URL – Enter the URL of the Submit Data Request endpoint of the Mindful Datastore API.

    You can retrieve this in the Datastore UI at Data Set Templates > Data Set API (plug icon), as seen in the example below.

    

  • DS_Auth — Enter your Datastore API token.

    Copy the API token (including the word "Bearer") from the same API example page, as seen above. You can also copy the API token from the Data Set Template page and add the word "Bearer" yourself.

  • DS_ContactNumber — Enter the caller's ANI (ContactNumber).

    Use an expression to make sure the ANI is formatted correctly when using it as a key in Datastore. The example shows the right-most 11 digits of the system variable Call.Ani assigned to the ContactNumber variable with the expression Right(Call.Ani, 11). This format can vary according to your regional numbering system.

Transfer to Number (to Mindful)

Add a Transfer to Number block to send calls to the SIP number associated with the relevant Mindful Call Target. This number should match the number range in the Number Plan configured previously.

This is the final block for a successful route through the Flow to Mindful. The final block to configure will catch instances in which a call needs to be routed directly to an agent queue rather than being sent to Mindful.

Transfer to ACD block (at normal priority)

Two blocks should contain exits leading to a Transfer to ACD block:

• The Case 1 path from the Switch block (meaning the EWT is under one minute)

• The No path from the Get Offer Decision block (meaning Mindful is not available)

In both of these cases, calls should be transferred to agents rather than Mindful Callback. Note in the example below that the priority should be set at a low value to ensure that returned callbacks have higher priority.

Choose-hold Flow

This Architect Flow is used if the caller declines the callback offer after being sent to Mindful Callback. In this case, Mindful sends a SIP REFER to Genesys Cloud, and the numeric portion of the SIP URI configured in the Choose Hold Phone Number field in the Mindful UI is passed in the SIP refer-to header.

Configure a DID entry (typically a virtual number) in Genesys Cloud to match the Choose Hold Phone Number.

Assign the DID entry to a Call Route:

Finally, assign the Call Route to the Choose Hold Architect Flow:

Example choose-hold Flow

The example choose-hold Architect Flow contains three primary steps, shown below. You could add more steps based on your requirements, but these three must be included if you utilize Mindful Datastore.

(Optional) Call Data Action (Datastore GET)

This Call Data Action block retrieves the data passed to Datastore during the initial inbound call. It then assigns the returned data back to variables that can be used for call routing decisions, agent screen-pop, or other uses.

Consult the example above when configuring this block:

• Category — Select the Integration for Mindful created earlier.

• Action — Select the Datastore GET Action.

• Inputs > DS_URL — Select the Literal type and enter the following expression. This is used as the full HTTPS GET URL in the Datastore GET Action. Notice that the expression uses the Call.Ani variable to append the caller's ANI onto the URL with the expected number of digits.

  Append("https://api-ds.getmindful.com/api/v1/data_sets/search?customer_contact_number=",ToString(Right(Call.Ani, 11)))

• Inputs > DS_Auth — Enter the API token (including the word "Bearer") of your Data Set Template from the API example page (Data Set Templates > Data Set API), just as you did for the inbound Architect Flow. You can also copy the API token from the Data Set Template page and add the word "Bearer" yourself.

• Success Outputs — Configure Success Outputs for all data keys in the relevant Data Set Template. Our example includes the following outputs/keys:

  
  • Task.FirstName
  • Task.LastName
  • Task.AccNum
  • Task.OriginalCallId

Configure additional outputs as needed, based on the data contained in your data set.

Transfer to ACD (send to agent queue)

This block sends the call to queue at the normal inbound queuing priority. Note that this should not be the highest priority (highest priority is 5 full stars = priority 10) so that callbacks can queue at a higher priority.

Callback return flow

The Callback Flow is almost identical to the choose-hold flow, with several exceptions: except for the priority of the Send to ACD block.

• The priority of the Send to ACD block is set to maximum.

• A Call Data Action block is needed to obtain the Mindful OAuth token for the Agent Answer API.

• A Set Screen Pop block is needed to add the ANI (If not already being passed) and the new OAuth token to the agent script.

Like the Choose Hold flow, a virtual DID number should be configured in Genesys Cloud and assigned to a Call Route that routes to the Callback Flow. The virtual number should then be configured in the Call Center Phone Number field in the Mindful Call Target configuration.

The final Flow should look similar to the example below:

(Optional) Call Data Action (Datastore GET)

This Call Data Action block retrieves the data passed to Datastore during the initial inbound call. It then assigns the returned data back to variables that can be used for call routing decisions, agent screen-pop, or other uses.

Consult the example above when configuring this block:

• Category — Select the Integration for Mindful created earlier.

• Action — Select the Datastore GET Action.

• Inputs > DS_URL — Select the Literal type and enter the following expression. This is used as the full HTTPS GET URL in the Datastore GET Action. Notice that the expression uses the Call.Ani variable to append the caller's ANI onto the URL with the expected number of digits.

  Append("https://api-ds.getmindful.com/api/v1/data_sets/search?customer_contact_number=",ToString(Right(Call.Ani, 11)))

• Inputs > DS_Auth — Enter the API token (including the word "Bearer") of your Data Set Template from the API example page (Data Set Templates > Data Set API), just as you did for the inbound Architect Flow. You can also copy the API token from the Data Set Template page and add the word "Bearer" yourself.

• Success Outputs — Configure Success Outputs for all data keys in the relevant Data Set Template. Our example includes the following outputs/keys:

  
  • Task.FirstName
  • Task.LastName
  • Task.AccNum
  • Task.OriginalCallId

Configure additional outputs as needed, based on the data contained in your data set.

Call Data Action (retrieve OAuth token)

Add a Call Data Action block before the Set Screen Pop and Transfer to ACD blocks, configured as shown below:

• Category — Select the OAuth Integration created earlier.

• Data Action — Select the OAuth token retrieval Action created earlier.

• Success Outputs — Assign the access_token variable to "Task.auth_token" to make the token available to the screen-pop script.

• Inputs — Assign the following inputs:

  • FirstName — "Task.FirstName"

  • LastName — "Task.LastName"

  • AccNum — "Task.AccNum"

  • UUIData — "Task.OriginalCallId"

  • Authentication Token — "Task.auth_token"

  • ANI — tostring(right(Call.Ani,10))

The related agent screen-pop script is detailed in the main integration guide.

Transfer to ACD

In the Transfer to ACD block, increase the priority in the Transfer to ACD block to a level higher than normal inbound calls. This does not have to be the highest priority (five stars). It only needs to be higher than the priority of inbound calls to the same agent queue.

With this final Flow in place, your Mindful integration should be complete, and you should be ready for end-to-end testing!