Transfer on User Exit allows a Nimbus service to automatically transfer a customer to a configured target service when the last Nimbus user ends the call, provided the customer has given their consent beforehand.

A typical use case is a post-call survey: the customer is asked during the call whether they would like to participate in a survey after speaking with an agent. If they agree, they are automatically routed to a survey service when the agent hangs up, without any manual action required.

How it Works

The overall flow involves three components working together:

1. Consent collection: The workflow asks the customer whether they agree to be transferred after the call.
2. Service configuration: The originating service has Transfer on User Exit enabled in Modalities Service Settings, with a target service defined.
3. Automatic transfer: When the last Nimbus user leaves the call by ending it, Nimbus checks for consent and, if granted and the service has Transfer on User Exit enabled, automatically transfers the customer to the configured target service.

💡The agent handling the call is not informed that Transfer on User Exit is configured on their service. From the agent's perspective, the call works as normal.

💡Only the initial caller is transferred.

💡Consultation calls and transfers to a different service is not triggering Transfer to User Exit.

Configuring Transfer on User Exit

Transfer on User Exit is configured per service under Modalities Service Settings > Audio/Video for Inbound and Outbound with Workflow. Inbound and outbound are configured independently. However, enabling Transfer on User Exit in one direction pre-fills the same target service in the other direction when enabled. The target service can be changed any time.

Configuring Consent in the Workflow

Consent is mandatory for Transfer on User Exit to trigger. If no consent has been collected, Nimbus treats the consent status as Not Granted and will not initiate the transfer.

The consent is captured using the Record Consent workflow activity (available for AV Inbound workflows). The recommended workflow pattern is:

1. Play an announcement informing the customer that they will be transferred after the call (e.g. to a survey), or use Customer Input (Advanced) which covers announcement and customer input in one.
2. Ask the customer for input (e.g. "Press 1 to agree, press 2 to decline").
3. Based on the input, use the Record Consent activity:
   • Set Consent Purpose = Transfer on User Exit, Consent = Granted on the "yes" path.
   • Set Consent Purpose = Transfer on User Exit, Consent = Not Granted on the "no" path.
4. Continue the workflow normally.

How consent is carried through a session

The consent status is stored as a session parameter and passed along with the call through transfers between services.

• If consent was granted in Service A and the customer is then manually transferred to Service B, the consent status is still Granted when the customer arrives at Service B.
• If consent is asked again in a subsequent service and the customer declines, the status is updated to Not Granted. This new value applies for all further services in the session, unless consent is asked again.
• A service admin can also programmatically set consent to Not Granted by including the Record Consent activity with a fixed Not Granted value to prevent Transfer on User Exit from triggering for customers who arrive via a specific route.

Overriding consent without asking the customer

You can include the Record Consent activity with a hardcoded value (without any customer input) to control the consent status for specific routing paths. This is useful when:

• Certain call flows should never result in a transfer (e.g. escalations or specific IVR paths).
• You want to grant consent automatically without explicitly asking the customer (e.g. if consent is obtained through other means, such as a web form).

DTMF and PSTN Transfer

By default, Transfer on User Exit uses Nimbus internal routing. This means DTMF (keypad tone) input is not supported in the target service after the transfer. If the target service runs an automated IVR or survey that requires keypad input, PSTN-based transfer must be used instead.

Enabling DTMF support

To enable DTMF support, the target service must have a PSTN number assigned. You can enable DTMF support by enabling the DTMF-Supported Transfer toggle in the Transfer on User Exit settings of the originating service.

💡When enabled, Nimbus places an outbound PSTN call to the target service's phone number, which supports full DTMF functionality. Note that after transferring to a DTMF service, no further transfer is possible.

Toggle states

The DTMF-Supported Transfer toggle has three states depending on the selected target service:

What happens if the PSTN number is removed?

If the target service's PSTN number is removed while DTMF-Supported Transfer is enabled,

• a warning is shown in Modalities Service Settings,
• the transfer attempt will fail, and
• The failure is recorded in Reporting with the outcome Failed Service Transfer to External - the original Service Session remains valid and is not marked as failed.

Behavior in the Target Service

When a customer arrives at the target service via Transfer on User Exit, the session is treated as a Transfer on User Exit session. This has the following effects:

• If the target service has a queue and a Nimbus user accepts the call, that user cannot perform any transfer actions — Blind Transfer and Safe Transfer are disabled.
• The user cannot start a Consultation Call from within this session (to user or to service).
• Codes & Tags (My Session) are disabled in the target session.
• Tooltips in the UI explain why these actions are disabled.

💡These restrictions currently apply to My Session and Attendant Console.

💡In Nimbus Assistant, Codes and Tags are still enabled, however, the equivalent restrictions are planned to be shipped with a future release. Transfers are blocked.

Only one Transfer on User Exit transfer can occur per Unified Session. If the target service also has Transfer on User Exit configured, it will not trigger a second automatic transfer. The target service is always the final destination.

Workflow Restrictions in the Target Service

The workflow assigned to the target service also has restrictions. The Transfer workflow activity behaves as follows:

Consultation Calls and Multi-Agent Scenarios

Transfer on User Exit is designed to be transparent during a normal call. Nimbus users can still transfer calls, start consultation calls, and work as usual. The Transfer on User Exit transfer is only triggered when the last Nimbus user leaves the call by ending the call (not by transferring it).

In a consultation or conference call scenario with multiple agents:

• If User A (Service A) consults User B (Service B) and then leaves the call, the customer remains with User B.
• If Service B also has Transfer on User Exit configured, it takes effect when User B eventually ends the call. At that point, Nimbus uses the consent that was collected earlier (e.g. in Service A) and transfers the customer to the target configured on Service B (not the target configured on Service A).

Reporting

All sessions involving Transfer on User Exit are flagged in reporting for easy identification.

Session flags

The following sessions carry a Transfer on User Exit flag (field TransferOnUserExit in OData):

• The Unified Session of the originating call
• The Transfer Session between the originating and target service
• The Service Sessions involved.

💡 The flag is exposed in OData. Power BI dashboards consume these fields, but the standard Power BI template update follows in a later release - existing dashboards continue to work but won't show the new fields until the template is refreshed.

Unified Session outcome

The Unified Session outcome is based on the last Nimbus user–customer interaction before the Transfer on User Exit transfer, not on the outcome of the target service session. This ensures that a failed or incomplete follow-up transfer does not affect the reported outcome of the original user–customer interaction.

Possible Unified Session outcomes for Transfer on User Exit sessions:

• User Accepted (most common — the agent accepted and handled the call)

Target Service Session outcomes

Within the target service session, outcomes are limited to:

• Accepted
• Client Ignored
• Canceled
• Failed

💡 If the transfer fails (e.g. PSTN number removed, target service unavailable), the outcome is recorded as Failed Service Transfer to External and is visible in Reporting.

Known Limitations

INC Transfer to PSTN Limitations and Requirements

☝Nimbus and related addons can only perform PSTN transfers according to Microsoft's licensing and constraints.
✅ As Administrator you need to acquire Microsoft Teams phone licenses 

🤔Which PSTN licenses do I need to acquire?

Service Licensing

Target Service using any of the Microsoft | PSTN Connectivity options ▼	Licence to apply for Nimbus Services
Direct Routing	“Teams Phone Resource Account” 🔎  See:  Microsoft Learn | Direct Routing Plan Microsoft Learn | Microsoft Teams Phone Resource Account licenses
Calling Plan	“Teams Phone Resource Account” license, plus "Microsoft Teams Domestic Calling Plan" OR "Microsoft Teams Domestic and International Calling Plan" OR “Microsoft Teams Calling Plan pay-as-you-go”1 PLUS "Communication Credits" (if these aren't already included as part of your plan) 🔎 See: Microsoft Learn |  Microsoft Teams Calling Plans 1 Only required for Outbound Call functionality, also see “Ahead notice Pay-as-you-go Calling Plan licensing changes” below.
Operator Connect	“Teams Phone Resource Account” 🔎 See: Microsoft Learn | Operator Connect Plan

User Licensing

Target User	License to apply to Nimbus Users & Call Targets
All Users, including … + Agents that handle Nimbus calls + Attendant Console transfer and consultation targets.	“Teams Phone Standard”, each account having: “EnterpriseVoiceEnabled” 🔎  See: Microsoft Learn | Teams Phone Standard

☝Please note that Luware staff cannot give recommendations on which license plan is best suited for your needs. Depending on your scenario, additional Teams App licenses may be required. Exact details are to be discussed with your Microsoft contacts.

 

 

 

🤔How does PSTN licensing affect Service and call transfers?

Assuming that the initially called Service has (no) PSTN license assigned - the following scenarios may unfold:

Scenario A - Service A has a PSTN license. Transfers to other Services occur.

⮑ The PSTN license carries over throughout transfers to other Nimbus Services B and C.
⮑ As the license carries over, a PSTN transfer to an external target is possible from either Service.

Scenario B - Service B has no PSTN license. A Transfer to Service C occurs which has a PSTN license.

⮑ The customer skips over Service A and manages to reach Service B instead.
⮑ The PSTN license is missing on Service B, so nothing is carried over to Service C.
⮑ Even if Service C has its own PSTN license, a PSTN transfer to an external target is not possible.

🌟Learnings:

• Nimbus will use the PSTN license – and create a (transfer) Session – from the FIRST Service responding to a call. 
• Regardless of how many internal Service transfers are performed thereafter, the FIRST Service PSTN license remains in effect. 
• If a PSTN license is missing, the transfer task will fail and be treated accordingly by the System.¹
• Even if a Service being transferred towards has a PSTN license, it cannot be added in post, as the Call Session is already ongoing from the first-responding Service.

✅ For your licensing needs this means: If you require PSTN transfer functionality, you'll need to ensure that this Service is handling all your incoming calls.

• For ONE first-level / Front Desk Service, you'll need a PSTN license for this particular Service.
• For MULTIPLE first-level Services scenario, you'll need PSTN licenses for all first-level Services.

---

¹🔎 Assumption: Workflow takes the normal “Exit” Announcement route and Service Session will conclude with a “Transfer failed” outcome. For more details on analyzing your Reporting results, refer to Nimbus Reporting and Static Dimensions > "Service Session Outcomes"

 

 

☝Note that handling and tracking of running cost for PSTN licenses is outside of the Luware support scope. If you however require assistance in extending and/or configuring your Nimbus Services for PSTN, our support will gladly assist you:

Luware Support Address

Luware Website	https://luware.com/support/
Luware Helpdesk	https://helpdesk.luware.cloud
Cloud Service Status	https://status.luware.com/