Transfer to Secure Flow action

AI-generated summary

Genesys Cloud's Transfer to Secure Flow functionality provides a robust system for handling sensitive interactions while maintaining security protocols and operational efficiency. The feature requires prior user authentication and supports multiple interaction types including inbound, outbound, and in-queue flows. Transfers cannot proceed during active supervisor monitoring, ensuring data privacy and compliance. Key technical capabilities include blind transfer implementation, configurable timeout settings, customizable audio prompts, and support for various transfer destinations like ACD, users, external numbers, and voicemail. The system allows for invocation data transmission and participant data configuration before transfers, while maintaining strict security by excluding sensitive information. The platform includes comprehensive error handling through failure paths, providing detailed error variables and automatic disconnection protocols for secure flows. Network issues trigger automatic rerouting, and the system supports return paths to original call flows after secure interaction completion. Notable limitations include restrictions on unpublished flow selection, failure triggers for removed flows, and the inability to transfer during active monitoring sessions. The system prioritizes security and operational continuity through structured failure path handling and automated response mechanisms when transfer attempts encounter difficulties.

PrerequisitesClick to expand

Use the Transfer to Secure Flow action in the menu to transfer an interaction to a published flow that contains secure data. If the selected flow is removed from the system and no longer exists and you do not update this transfer action, the flow fails at this action step. If you select an unpublished flow, Architect sends a warning message.

Note: If a supervisor or administrator actively monitors a secure interaction, the agent cannot transfer the interaction. Architect cannot automatically stop active monitoring of secure interactions. If the “More than one external participant is connected to the conversation” message appears, the agent must contact their supervisor or administrator and request that they end the monitoring session.

This action is available in menu choices and task sequences for inbound, outbound, and in-queue flows. Menu choices contain common settings such as DTMF and speech recognition.

Action	Description
Name field	The label you enter here becomes the name of the transfer node in the flow structure.
Secure Call Flow	Select the secure flow to which to transfer the interaction.
Invocation Data	A string to be passed to the secure flow, which is available in the secure flow via the Flow.InvocationData built-in variable. This string should NOT contain secure/sensitive information, such as a credit card number.
Connect Timeout	Click to change the default timeout, in seconds or milliseconds. Use the + or – buttons, or manually enter an appropriate value. Notes: If you do not specify a value, or if Architect does not override this value, the system uses the timeout configured for the target user voicemail. If the maximum dial timeout configured for the trunk is less than the timeout setting at the flow level, the trunk’s maximum dial timeout is used. If you modify this setting, republish existing flows. This step ensures that existing flows follow the configured failure path for unsuccessful transfers.
Pre-Transfer Audio	Optionally configure a prompt to play before transferring the interaction.
Failed Transfer Audio	Optionally configure a prompt to play if the transfer action detects a failure.
Failure outputs	These outputs allow the flow author to map the results of any resulting errorType and errorMessage. errorType: A nonempty string that contains the type or category of the error. errorMessage: A non-localized failure message. The string may be empty or NOT_SET. Note: Click the arrow next to Failure Outputs to expand or collapse the list of variables.

Define success and failure paths

Note: For transfer actions included in secure flows, Genesys Cloud overrides the defined failure path and disconnects the call. The normal consultation VXML transfer type can be problematic in secure flows; therefore, Genesys Cloud uses blind transfers. For more information, see . This behavior occurs in transfers to ACD, user, external numbers, group, other flows, and voicemail.

Name	Description
Success	Ends the flow and sends the call to the secure flow. Notes: An executed Success path indicates that no errors were encountered during the process. If you transferred to a secure call flow from an inbound call flow, you can use the Transfer to flow action to send the call to the invoking call flow after the secure flow ended. Note that a new instance of the inbound call flow will start. You can set participant data before the first instance of the inbound flow transfers to the secure flow. This way, in the second instance of the inbound flow, if you added logic to check for the presence of such data, you can return to a specific part of the inbound flow or run only parts of the flow based on that data and logic.
Failure	This path indicates that an error occurred while executing the action. Specify the action if Architect is not able to transfer the call. For example, a play audio action to indicate that the action wasn’t successful, a transfer action to send the caller to an agent or representative for assistance. Note: If the network experiences connection issues, the action automatically takes this failure path.

Name

Description

Success

Ends the flow and sends the call to the secure flow.

Notes:

An executed Success path indicates that no errors were encountered during the process.
If you transferred to a secure call flow from an inbound call flow, you can use the Transfer to flow action to send the call to the invoking call flow after the secure flow ended. Note that a new instance of the inbound call flow will start.
You can set participant data before the first instance of the inbound flow transfers to the secure flow. This way, in the second instance of the inbound flow, if you added logic to check for the presence of such data, you can return to a specific part of the inbound flow or run only parts of the flow based on that data and logic.

Failure

This path indicates that an error occurred while executing the action. Specify the action if Architect is not able to transfer the call. For example, a play audio action to indicate that the action wasn’t successful, a transfer action to send the caller to an agent or representative for assistance.

Note: If the network experiences connection issues, the action automatically takes this failure path.

[NEXT] Was this article helpful?

Get user feedback about articles.

Loading...

Transfer to Secure Flow action

Define success and failure paths

[NEXT] Was this article helpful?