☝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 

🤔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"

 

 

In MS Teams technically you can use conference invite and transfer features, but Nimbus cannot control the session anymore, nor create status reports on the results. This will not be a controlled or safe transfer, thus Nimbus will consider your user free to take on other tasks.

In Nimbus, therefore transfer buttons will be disabled while you are in a conference created by Nimbus functionality – e.g. when you…

• … started via Assistant Consultation / Attendant Consultation (both with either Service or User).
• … started with Supervision.

The transfer of Custom Context Parameters and System Fields (Custom Fields) works under the following scenarios:

✅ Note: Only applies if “Persistent RONA” is enabled via Distribution Service Settings.

• When the target User is already is in RONA state.
  ⮑ A message will be shown after a transfer attempt is made: “Transfer cannot be started to a User, who is in a Nimbus Task”. 
  ⮑ There will be no extra User Session for Nimbus Reporting created.²
• When the target User ignores / doesn't answer the transfer (e.g. Timeout), Nimbus will not flag users with RONA state¹.
  ⮑ User Session in Nimbus Reporting marked “Cancelled”²
• When the target User actively declines a transfer will also not flag users with RONA state. 
  ⮑ User Session in Nimbus Reporting marked as “Declined”.²

¹🤔 Why is RONA not applied in this case? When a User is a direct transfer target, they were not selected by the Nimbus Task Queue and Distribution system. In order to keep that user available to other Nimbus Services – e.g. after previous transfer / timeout – no persistent RONA state is applied.
² Depending on the Attendant Console transfer scenario (safe/blind), the call will return to the initial User or be lost. This is not related to RONA behavior.

¹ See Nimbus Reporting Model >  Static Dimensions > “User Session Outcomes”

² Voicemail and Reporting: Any direct "Transfer to Voicemail" Actions via Attendant Console are not creating a new User Session or any related User State checks for the Nimbus Reporting Model.

³ Blind Transfer behavior: When the destination doesn't accept – and has Voicemail or any other forwarding activity enabled – the transfer will not reach Voicemail nor the forwarding target. This is expected Contact center behavior and avoids the loss of calls.

⁴ Safe Transfer / Voicemail behavior: When the destination doesn't accept - and has Voicemail enabled - the transfer will NOT reach the Voicemail. This is expected Contact Center behavior to avoid a potential call loss. 

⁵ Disabled Voicemail: Nimbus cannot check ahead if voicemail is enabled for a user, but the “Transfer to Voicemail” UI element is always shown. Also refer to the “Transfer to disabled Voicemail” limitations.

☝Out of box, transfers towards the UPNs of Teams-native Auto Attendants (AA) or Call Queues (CQ) Resource Accounts will fail. Preconditions and Workarounds apply.

Connectivity plan dependencies

Based on the PSTN connectivity option used, transfers towards the Resource Accounts' assigned phone numbers will work as summarized in the table below.

Set-CsPhoneNumberAssignment -PhoneNumber <phone number assigned to the CQ/AA resource account> -ReverseNumberLookup SkipInternalVoip

☝No Voicemail feature lookahead possible: Currently, there is no way to check ahead if a transfer target (MS Teams User) has Voicemail features enabled. This is a design limitation by Microsoft which Nimbus currently cannot circumvent. 

☝Voicemail feature IT policies: Additionally, the Voicemail feature may also be deactivated as part of a tenant-wide IT policy by your administrator. There are also known cases where Microsoft accepts transfers to Voicemail but the recipient has no means to check (e.g. due to MS Teams Client / License restrictions). 
→ We highly recommend using “Transfer to voicemail” related Nimbus features only in case Voicemail is generally enabled for the Microsoft Teams user.

☝Unsupported Scenario - PSTN call forward to Voicemail within own Tenant: When inviting an internal user via PSTN (e.g. in a Attendant - Consultation Call scenario) with Voicemail forwarding enabled:
⮑ The call will be redirected, but the receiving user will not hear anything.
⮑ In Nimbus the call will fail.

🔎Analysis: This scenario is unsupported because MS Teams will auto-resolve the PSTN Number and generate a federated call. The Nimbus bot will run into a timeout and the receiving user will only get an empty Voicemail.