Workflow Activities

Notes

The following page will describe workflow activities and their conifgurable properties.

Terms like "Workflow Step", "Workflow Element" and "Workflow Activity" are used synonymously.
Certain Workflow Activities are limited by your Service Type and related license. Check Nimbus Features for a comparison. Activities below are marked accordingly. Service license downgrades may not be performed until you removed the according activities from your workflows.
Certain Activities have required predecessor activities, marked with - ensure to have them in your workflow to avoid errors in call handling.
Activities with Text-to-Speech (TTS) engines used in the activities below are provided by Microsoft. We dynamically update the list of available languages. Any old or outdated selections may therefore be marked with a warning that disappears until you select a different TTS-engine. Your existing "outdated" TTS-activities still remain intact as a working copy on the Nimbus infrastructure until you change them.

Important Note: Workflows heavily rely on other Configuration data entities such as Opening Hours, Parameters, Playlists etc. The visibility of these entities within an workflow activity dropdown menus is determined by the Organization Unit (OU) "Reading along the path" rule.

The viewpoint on visible data is the Organization Unit of your workflow, not that of your user account. When workflow-dependent items are moved to a different OU, your workflow continues to function normally, but the item cannot be found in the property-selections anymore unless your workflow changes the OU accordingly.

Conversation Handling Activities

Accept Conversation

Accepts an incoming conversation and establishes the AV channel to the caller.

Configurable Properties	Description
None	Controls when your call will be accepted (also for Reporting / KPI purposes). This activity is essential and cannot be disabled. It's required in a workflow (e.g. right after a → "Check Opening Hours") activity to ensure proper tracking, call distribution and reporting.

Announcement

Plays a defined resource or text to the caller. Can generate text to speech "on-the-fly".

Required Predecessor: Accept Conversation

Configurable Properties	Description
Announcement Type	Text-to-Speech (with Language Select & Text Field) Audio Resources. Audio resources can be added via Configuration > Resources .
Add Parameters ( Toggle )	Will allow the use of Custom Parameters and Context - Fields and Parameters in the "Prompt Text" Field. Note that with this option enabled the will "Preplay" feature is disabled as paramaters are dynamically resolved during a call.
Prompt Language	Allows to select the locale / voice to use when using the Text-to-Speech engine.
Prompt Text	Only shown when Announcement Type = Text to Speech is selected. Allows you to add text to the box that will be read in the prompt language / locale. The announcement can be a mixture of text and Custom Parameters and Context - Fields and Parameters. Announcements will be generated on-the-fly and cached if continously re-used. Usage and Luware fair use policy *This activity has a dynamic* character limit for the Text-To-Speech engine.** The final resolved parameter values – not the parameter name – count towards this character limit. Keep this in mind when parameters are very long (e.g. a customer with multiple surnames) The limit is shown in the info-tooltip below the text field as you enable the "Add Parameters" field. Please note that this limit is subject ot change. Note: When the limit is exceeded, this activity will be skipped. → We recommend splitting the important information (e.g. parameters) into separate "Announcement" activities with short sentences each to avoid a skip. Please note that on-the-fly Text-to-Speech engine uses runtime resources that are under a fair-use policy. Luware may change the usage limit or contact customers that exceed the general usage quota.

Input Customer (IVR)

Plays a prompt while allowing the caller to perform DTMF inputs.

Good to know

This action uses up to 10 exit nodes. When the corresponding Prompt properties are not filled out, those are grayed out.
An input may be marked as unclear and escalated with a prompt when the user enters an unexpected key combination.

Required Predecessor : Accept Conversation

Configurable Properties	Description
Main Prompt Type	Text-to-Speech (with Language Select & Text Field) Audio Resources. Audio resources can be added via Configuration > Resources.
Prompt Language	Allows to select the locale / voice to use when using the Text-to-Speech engine.
Prompt Text	Only shown when "Main Prompt Type" = Text to Speech is selected. Allows you to add text that will be read in the prompt language / locale.
Input during announcement ( barge in )	Defines when the caller is allowed to enter input: if true - from the moment when the main prompt was started if false - after the main prompt was fully played When enabled, the "Time to complete started input" timer starts immediately upon first input. Any prompts at this point are stopped.
Max Input Timeout ( toggle )	Enables a maximum wait time to be specified in fields below.
Max Input Timeout hh:mm:ss (default 00:00:30)	Maximum wait time for any caller response to be started. Once started the "Time to complete started input" field applies. If nothing was entered, the "No Recognition" (NR) exit node is used.
Time to complete started input hh:mm:ss (min 00:00:01, max 00:00:09)	Specifies the time the caller has to make the input.
Expected Input	Description
Name	A clear name for the exit node. You can add up to 10 nodes by clicking "Add Input" at the end this field group.
DTMF	Allows to enter multiple DTMF tones / digits per exit node. If a user hasn't entered all expected digits yet – or the input is ambiguous (expected input 1: 123, input 2: 12, the caller enteres "12") – the "Time to complete started input" applies before the DTMF is evaluated.
Missing Input	Description
Missing Input Timeout hh:mm:ss (default 00:00:10)	Time for the caller to enter input. Afterwards the 1st silence prompt is played.
Missing Input 1st Prompt Missing Input 2nd Prompt	Message to play when the input was not occurring in the timeout. A selection of the following options: Text-to-Speech (with Language Select & Text Field) Resources Audio resources can be added via Configuration > Resources . If User enters no input within the silence timeout: 1st Prompt → (if configured) does the following: Play "1st Prompt" otherwise play the "Main Prompt Text" 2nd Prompt → (if configured) does the following: Play "2nd Prompt", Play "1st Prompt" otherwise play the "Main Prompt Text"
Wrong Input	Description
Wrong Input 1st Prompt Wrong Input 2nd Prompt	Message to play when the input was not recognized. A selection of the following options: Text-to-Speech (with Language Select & Text Field) Resources Audio resources can be added via Configuration > Resources . If User enters a wrong input: 1st Prompt → (if configured) does the following: Play "1st Prompt" otherwise play the Main "Prompt Text" 2nd Prompt → (if configured) does the following: Play "2nd Prompt", Play "1st Prompt" otherwise play the Main "Prompt Text"

Collect Information

Enterprise Routing Contact Center

Allows to store DTMF inputs in Parameters, exiting based on whether or not an input was received. The parameter can also be used in other areas and verified via the "Check Parameter" activity.

Required Predecessor: Accept conversation

Configurable Properties

Description

Main Prompt Type

Text-to-Speech (with Language Select & Text Field)
Audio Resources.

Audio resources can be added via Configuration > Resources.

Prompt Language

Allows to select the locale / voice to use when using the Text-to-Speech engine.

Prompt Text

Only shown when "Prompt Type" = Text to Speech is selected.

Allows you to add text that will be read in the prompt language / locale.

Input during announcement
( barge in )

Defines when the caller is allowed to enter input:

if true - from the moment when the main prompt was started
if false - after the main prompt was fully played

When enabled, the "Time to complete started input" timer starts immediately upon first input. Any prompts at this point are stopped.

Parameter To Save

Required: To be visible in this selection menu at least one Custom Parameter must be defined and made available to your service or tenant-wide Organization Unit.

Custom parameters can be used in the following areas:

Area

Usage within

Workflows

Workflow Activities

"Voice Message"
"Input customer"
"Collect Information"
"Check Parameter"

Microsoft Power Automate Connector

Action "UpdateTask"

CustomContextParameter.<ID>

Conversation Context

As part of a context URL:

$(CustomContextParameters.<ID>)

Input Timeout
hh:mm:ss
(default: 00:01:00,
min 00:00:01,
max 02:00:00)

Defines the maximum time in which a caller can enter and complete the input:

If the time is reached and the caller didn't enter anything, the "No Input" exit is taken and nothing will be saved in the parameter as value.
The default parameter value - or in case of a loop - previous value entries will be kept unchanged when no entry is made.

Max DTMF Digits
(default: 1,
min:1,
max 999)

Defines the maximum of DTMF tone digits. The collection will be stopped automatically if the defined maximum is reached and the input is stored.

Further exit conditions may apply, see "Node Exits" description below.

Node Exits

The "input received" activity exit is taken under the following conditions:

When the caller entered the max number of digits.
When the the caller completes the input with the #. The # character will not be saved as input
When the timeout is reached and the caller has entered at least one digit (but less than < MAX DTMF Digits)

In all cases the parameter is stored and the default / previous parameter is overridden.

Account for parameter processing delays

A common use case is to add a "Check Parameter" activity right after your "Collect Information":

In a "same parameter / Nimbus internal" scenario this should work without problems, as there are no expected delays in parameter storage and processing.
in a "different parameter / external system" scenario a custom parameter input "lookup_param_1" could be used to store look-up info for handling in an external system. The results would be stored in "return_param_2".
This data-handling process may take time that a Nimbus workflow does not account for.

Recommendation: When involving an external system (e.g. using the Microsoft Power Automate Connector ), add an "Announcement" or other delaying workflow activity that allows "Check Parameter" to catch the updated return value.

Play Music

Plays a single music (or any other sound file) or a combined playlist.

Required Predecessor: Accept Conversation

Configurable Properties	Description
Resource Type	Allows to choose between resource types: a playlist (default) a single resource Playlists consists of one or multiple resources, defined via Configuration > Playlists.
Shuffle Playlist	Playlists only. Will shuffle the entries in your playlist before playback.
Duration ( toggle )	Limits the duration for this step: When Enabled: Plays the resource / list for the specified duration. When Disabled: Plays the resource / list for its full length. For single "resources" the duration setting will enforce a loop even if the file would be longer.
Duration (hh:mm:ss)	Determines how long the playlist or resource is played. If the same workflow activity is hit multiple times, the music is continued where it stopped before.

Disconnect Conversation

Terminates an incoming conversation or disconnects an accepted conversation.

Required Predecessor: None

Configurable Properties	Description
None	Acts as end node to terminate the call. Required to close the task for reporting purposes.

Voice Message (Recording)

Available for Advanced Routing and Enterprise Routing. Not available for cross-team Contact Center services as no single MS Teams channel can be attributed for handling and reviewing recorded messages.

Allows the caller to record a voice message. Exits when the maximum recording time is reached.

Required Predecessor: Accept Conversation

Configurable Properties	Description
Play Recording Tone (toggle)	Plays a beep tone. First action if this activity is reached.
Maximum Recording time (hh:mm:ss)	Starts the recording for the configured time span. Maximum 2 min. Afterwards the call is terminated. A caller has the chance to terminate the conversation earlier.
Message	Will send a message to the service chat channel within MS Teams. Example Message: `Voice message has been received from $(Customer.FirstName) $(Customer.LastName) / $(Caller.TelNumber)` CODE Also supports MSFlow Context - Fields and Parameters, like: CustomerFirstName, string CustomerLastName, string CustomerCompany, string CustomerTitle, string CustomerDepartment, string CustomerStreetAddress, string CustomerPostcode, string CustomerCity, string CustomerState, string CustomerCountry, string Learn more about this on: Microsoft Power Automate Connector
+System / Custom Parameter	Allows the use of custom user Parameters and System Parameters, in the message. → Selected Parameters are inserted at the current cursor position in the "Message" field. Learn more about this on: Context - Fields and Parameters. Parameters and Context will be exchanged with data once the activity is executed. The context info is also used in the adaptive card. → See info below

Interaction within Adaptive Cards

This activity interacts with "Adaptive Cards"

Once the "Voice Message" activity is finished:

An Adaptive Card is sent to the Teams Channel with the Message and the recorded Audio File being directly accessible.
SIP and phone parameters are added with a hyperlink.

By default the message state is: "New". The state updates according to the following actions from any of your team members:

Once it was listened to by a team member the message can be set from new / solved to "Listened" . → A message "Listened by <ms teams user name>" is added.
A team member can set the message to "Solved". → The message is set to "Listened" and a message "Solved by <ms teams user name>" is added.

This session is tracked as "Workflow Conversation Recording" within reporting data.

Transfer

Transfer the caller to another service, user (within tenant) or SIP-address.

Exits if the transfer to the target was not successful (either "declined" or "timeout").
A transfer results in a new session reporting in the new service. The old task will be closed and concluded a result. → Also see " Transfer Task Results " below.

Required Predecessor: Accept Conversation

Configurable Properties

Description

Target

Allows you to define a transfer target, with a choice between:

a Custom Parameter as transfer target. Requires a valid UPN / E.164 PSTN as transfer target. The behavior will be different depending on target:

Service: When the parameter is matching a Nimbus service, it will be treated like an internal service transfer. Timeout and music on hold playlist are ignored. Reporting treats this as "Service Transfer".
Known User: When the parameter is matching an internal user, it will be treated like any internal target. Timeout and music on hold playlist are considered. Reporting treats this as "Internal Transfer".
Unknown User: When the target is valid, but not recognized as internal user or service, it will be treated as external target. Timeout, music on hold playlist, and leave Nimbus flags are ignored. Reporting treats this as "External Transfer".

In any other case: – including UPN / PSTN number format incorrect – the "Failed" exit is taken. Please note that this activity does not perform any validity checks. Values must be well-formatted.

Show me how to verify this

To ensure your transfer is done correctly, precede with a "Check Parameter" step depending on what scenario you expect in the parameter content:

Check Scenario

Regex

Check Parameter Activity

UPN (Service or Teams User)

Use a custom parameter with a regular expression as follows:

^[^ @}+@.$

Route to a PSTN Number

Use a custom parameter with a regular expression as follows:

^\+[1-9]\d{1,14}$

Please note that the "Check Parameter" Activity will take the first valid Regex Check exit note.
Make sure to handle "No Match" and "Not Set" exits as well, e.g. by ...

... trying to retrieve the parameter input again
... adding additional "Check Parameter" steps or checks.
... by routing the call to the normal queue (without a preferred Agent).

Show me some Regular Expression examples...

These are some common Regular Expressions (RegEx) we recommend to use within Nimbus. To test your own regular expressions please consider using this online tool: RegExr: Learn, Build, & Test RegEx.

Description	Regular expression	Check perform on Fields and Parameters
Incoming Call is from an external PSTN number	^\+[1-9]\d{1,14}$	MicrosoftCallerId
Incoming call is from an internal Teams account (UPN)	^[^@]+@.+$	CallerUPN
Incoming number is from Germany/UK Germany +49 UK +44 Check country code	^([+]49)\d+ ^([+]44)\d+	MicrosoftCallerId
Caller is anonymous	^Anonymous	MicrosoftCallerId
The incoming call is from Switzerland OR Germany	^([+]49)\|^([+]41)\d+	MicrosoftCallerId
The value equals 1	^[1]$	Queue Position Custom Parameter
The value equals 2	^[2]$	Queue Position Custom Parameter
The value equals or is greater than 3	^[3-9]$\|^([1-9]\d\|[1-9]\d{2,})$	Queue Position Custom Parameter
No user is available	^[0]$	Available Users Custom Parameter
One or more users available	^[1-9]$\|^([1-9]\d\|[1-9]\d{2,})$	Available Users Custom Parameter
The value is true	^(true\|True\|1)$	Custom Parameter
The value is not Empty	^.	Custom Parameter
The lenght of the string is in between 5 or 10 and not less or more	^.{5,10}$	Custom Parameter
The lenght of the string equals 3	^.{3}$	Custom Parameter

Also refer to Context - Fields and Parameters for a comprehensive list on parameters handled by Nimbus.

a Service Line as transfer target.
You can search for Service Lines of the same Nimbus tenant.
a User to transfer to:
You can search for Users of the same O365 tenant
- Nimbus users are considered as an "Internal Transfer"
- Other users are considered as "External Transfer"
an external SIP, UPN or PSTN / Phone number.

Notes on Transfers

A transfer uses the external caller number (ID) as long as the call has not been escalated to a conference. A conference is created as soon as a Nimbus user joins a call (e.g. via queue distribution).
If an incoming caller is internally transferred from service 1 to service 2 - with external transfer configured on service 2 - the number of service 1 is carried forward.
KNOWN LIMITATION Federated transfers to users in another tenant are currently not supported.

Transfer to PSTN limitation

Out-of-the-box, Nimbus and affiliated addons can only perform PSTN transfers according to Microsoft's licensing and constraints.

Which PSTN license do I need to acquire?

As a tenant administrator you need to acquire the following licenses and assign them to the application instance of the respective Nimbus SOURCE service (team) that will act as PSTN transferor:

Your Setup	Required License
Direct Routing	"Microsoft Teams Phone Resource Account"
Calling Plan	"Microsoft Teams Phone Resource Account" + "Microsoft Teams Domestic Calling Plan" or "Microsoft Teams Domestic and International Calling Plan" or "Microsoft Teams Calling Plan pay-as-you-go" + "Communication Credits" (if these aren't already included as part of your plan)
Operator Connect	"Microsoft Teams Phone Resource Account"
*As of 2023 "Microsoft Teams Phone Standard"* licences are no longer supported by Microsoft*. Previously those licenses were viable for Nimbus. → Regardless if you are using Direct Routing, Calling Plans, Operator Connect* - the "Microsoft Teams Phone Resource Account" license is now always required. Please note that Luware staff cannot make 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. Also see: https://learn.microsoft.com/en-us/microsoftteams/teams-add-on-licensing/virtual-user

How does PSTN licensing affect Service and Call Transfers?

Assuming that Service A has a PSTN license assigned - but further Services don't - the following scenario may unfold:

Scenario A - Service A workflow is configured to transfer the caller to Service B. The license of Service A is used, the PSTN transfer occurs. The PSTN license is re-used throughout further transfers to Services C..D...x.
Scenario B - Service B is called directly instead. Now the workflow of Service B attempts a redirect to either service A or transfer to C. The PSTN transfer fails due to a missing license on Service B.

Learnings

For one first-level-response Service: If you handle first-response calls always via the same Service you need a PSTN license for that particular first-level Service.
For multiple first-level-response Services: If you handle first-response calls always via multiple Services you need a PSTN license for all those first-level Services .
Nimbus will attempt to use the PSTN license of the first service that responded to a call, regardless of how many further internal service transfers are performed thereafter.
If no PSTN license is found on a service that requires it for a transfer, the transfer task will be considered as failed and be treated as such by the system (e.g. workflow exit announcement, reporting "transfer failed" outcome).

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

Luware Support

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

Refer to the external reference: Microsoft Teams PSTN connectivity options and Microsoft Teams add-on licenses.

Transfer to Teams-native "Auto Attendants" and "Call Queues"

Nimbus does currently only support call-forwarding via Blind transfer to either UPN or PSTN numbers of Teams-native "Auto Attendants" and "Call Queues". Any safe transfer or consultation attempt will lead to a call abort.

Causes and Workarounds

This is caused by Microsoft Teams limitations and cannot be circumvented by Nimbus.

A possible workaround would be to force the call over your Direct Routing SBC by using an internal dummy number that isn't otherwise associated with any other Teams user or service already. This call would then be routed to your SBC, which can then re-direct it towards the actual number of the Call Queue / Auto Attendant on the Teams side again. As this workaround is dependent on voice infrastructure components outside of Luware's control and support scope, please reach out to your SBC provider or skilled personnel for its implementation.

The above mentioned workaround is not technically feasible if you are using Microsoft Calling Plans or Operator Connect to provision numbers directly through Teams. Forcing an external reroute as a workaround is not possible with these numbers.

Leave Nimbus

Available if the target is external or any O365 user.

Picking a user enables the "Transfer to Voicemail" option.
There is no control of outbound invitation timeouts and no waiting music.
On Transfer Nimbus considers the current Reporting call session as terminated.
Unsuccessful transfers will be returned and the "Failed" exit is taken.

Transfer to Voicemail

Available when the target is a MS Teams user and "Leave Nimbus" is enabled:

With voicemail enabled: the caller will directly hear the announcement to leave a message. The target will not receive a ringing toast, but instead get a voicemail notification within MS Teams.
With voicemail disabled: the call will attempt to ring at the target instead. If the target declines, ignores or is busy the "Failed" exit is taken.

KNOWN LIMITATION Currently there is no way to check ahead if a (target) user has voicemail features enabled. This is a design limitation by Microsoft which Nimbus currently cannot circumvent. Additionally the voicemail feature may also be deactivated as 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. MS Teams Client / License restrictions). → We highly recommend using this feature only in case voicemail is enabled for the Microsoft Teams user.

Timeout
(hh:mm:ss)

Available if the target is a user or parameter.

When the timeout criteria is met, the transfer is aborted ("Failed" exit is taken)

Waiting Music

Allows to choose a playlist (default) or a single resource to play.

Playlists and Resources can be uploaded and defined within the Configuration.

If the target is not a service line and waiting music is configured, it will be played until the call was accepted or cancelled.
It the music file reaches its end, it's played on repeat.

Transfer Task Results

Transfer task results – used for Nimbus KPI Calculations and the Reporting service / user task model – can depend on the following transcripts:

Show details...

Transcripts	Description	Transfer Task considered as handled
Customer Hangup Before Accept	Customer hung up the call before it was accepted	False
Customer Hangup In IVR Customer Hangup In IVR after queue	Customer hung up the call before it was put into the queue once	False
Customer Hangup In Queue	Customer hang up the call during the time the task was enqueued	False
User Accepted	User accepted the task and was connected to the customer	True
User Internal Transfer Success	User accepted the task and transferred it to another service Line or user	True
User External Transfer Success	User accepts the task and transferred to a non service line or user	True
Workflow Disconnect After Queue Workflow Disconnect System Failure	Workflow terminates the call after it was put once into the queue Workflow terminates the call, which was never put into the queue Something went really bad, including Microsoft infrastructure outage	False False False
Workflow Conversation Recorded	Workflow recorded a voice message / mail	True
Workflow Internal Transfer Successful	Workflow transferred the call to another Service Line Successful	True
Workflow Internal Transfer Failed	Workflow couldn't transfer the call to another Service Line	False
Workflow External Transfer Successful	Workflow transferred the call successful to a non service line target	True
Workflow External Transfer Failed	Workflow couldn't transfer the call to a non Service Line target	False

Save to Parameter

Enterprise Routing Contact Center

Allows to store Nimbus System Fields and Parameters and/or text into a Custom Parameter of your choice.

Required Predecessor: None. Relies on call Trigger Events to provide fields with actual content.

Configurable Properties

Description

Parameter

The Parameter of your choice to store a value in.

Availabiltiy of parameters in the selection depends on the Organization Unit of your current workflow. Note that parameters can have a default value that is overwritten once this activity is reached.

Value

A multiline textbox. Contents will be stored in your selected Parameter.

Tips

You can store a combination value of both Custom Parameters and/or System Fields and Parameters .

To form complex validation chains you can combine "Save to Paramater" with previous data handling activities. For example:

Add a "Collect Information" or " Input Customer " to get customer preferences first (e.g. Language, Type of Issue).
Follow with one or several "Save Parameter" steps, e.g. to form a code combination made out of user inputs and optional system Fields and Parameters.
End with a "Check Parameter" activity to ensure your output is correct, then route your workflow accordingly.

You can extend this scenario even further by including external systems via our Microsoft Power Automate Connector. Refer to our Power Automate Use Cases for creative inspiration.

KNOWN LIMITATION The value stored in "Save to Parameter" is text-only. Any relation to previous variables and parameter names to create this saved output is lost after exiting this activity. We are aware that having dynamic nested parameters in other activities would be very useful and are working to extend this functionality with future updates.

Queue Activities

Queue

Puts a task into the queue for the dedicated service line. Lasts until either of the following Activity is met:

Voice message
Transfer
Cancel task
Disconnect call

The following user-side actions also end the task:

hangup by customer
accepted by user

Required Predecessor: Accept Conversation

Configurable Properties

Description

Distribution Type

Distribution Type	Description	When to Pick
Broadcast	Rings users simultaneously, selected in a batch size of 10 longest-idle users. The first user to pick up the call via Microsoft Teams will handle the task. Does not apply RONA status as it would otherwise flag the entire user batch size.	Achieves a higher visibility, but the ringing call sets 10 selected agents as "Not Available", not allowing further calls to be distributed to them in the meantime. Makes little sense in high-speed scenarios when the agents are dedicated only to the client to accept calls within a few seconds. Situationally for very large teams where high-volume call handling is more important than equal work distribution.
Direct	Will distribute tasks directly to team members, prioritizing the longest idle (active) team member. RONA time is adjustable. No further actions are necessary aside from accepting the call via Microsoft Teams.	The call with the selected team member is first established via a Teams peer-to-peer call, before it gets escalated to the regular Nimbus conference session. Useful if you have "Busy on Busy" features enabled for your users. Otherwise slower than "Direct Conference" and generally not recommended.
Direct Conference	Same distribution as "Direct", but in this mode, the selected team member is directly invited to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner.	Our General recommendation for most services. Ensures faster handling of calls without blocking too many users at once for the same ringing call. Conference invitations get cancelled if a task was aborted (e.g. Hangup by User, Queue left, Max Wait Timeout Reached ). → See Nimbus Reporting Model.
Pickup	Will show extra "Pickup" controls in the Tasks list of the called team. A call session will be directly established without further intervention, and no further call reporting is possible after this point. If the Nimbus user is unavailable or the session is otherwise ended the call will be lost.	In small teams (e.g. volunteers) where it's acceptable to lose a call and reporting data isn't as important. Pickup by itself does not allow call transfers as Nimbus has no further control over the session.→ If you want to use Pickup with transfer, use "Pickup with Adjustable RONA" or "Pickup Conference" instead. KNOWN ISSUE When any "Pickup" type is selected, skill-based Contact Center Service types may still show the call in a queue, however without a pickup button. → We recommend not using any "Pickup" distribution type in a skill-based distribution scenario.
Pickup with Adjustable RONA	Same as Pickup, but with adjustable RONA. A call session that is not accepted (after "Pickup" is clicked) within the given RONA time can be re-inserted into the task queue or handled otherwise.
Pickup Conference	Same as "Pickup with Adjustable RONA", but will directly invite the agent to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner.	Best performance of all "Pickup" types. Unanswered calls can be re-inserted into the queue and no reporting data is lost. Suitable for scenarios in which the agents can keep an eye on the app. Or to "park" calls in a queue so that other calls can be answered first and then the parked call can be retrieved from the waiting queue. Conference invitations get cancelled if a task was aborted (e.g. Hangup by User, Queue left, Max Wait Timeout Reached ). → See Nimbus Reporting Model.

Conditional Options

^{(shown based on "Distribution Type")}

Description

Adaptive Cards
(toggle)

Requires a "Pickup" Distribution Type to be set.

Enable this for Adaptive Cards to be created automatically within the Service chat channel in MS Teams.

Adaptive cards will update with the call information. Team members can also opt to pick up calls, listen to voice recordings or mark the call as handled within the card itself.

RONA
(toggle, default 00:00:30)

Applies a RONA status flag whent he timeout for the current "Queue" Activity is reached.

This setting relies on "Distribution Type" chosen. If not available the RONA timeout is either hard-coded (field greyed-out) or the "Calling / Queue Timeout" settings apply instead. → Also refer to "Distribution Type" above for more info on RONA.

RONA status will not apply to "Broadcast" distribution type setting.

RONA Timeout

Specifies the time the system uses to ring a team member, then switches to the next available user in the queue.

Queue Timeout
(default 00:01:00)

Waits for the specified time, then uses the "Queue Timeout Reached" exit node.

Playlist

Sets a waiting playlist for to the caller while in queue.

Playlists and Resources (music) can be added and defined in the Configuration.

Queue Task

Enterprise RoutingContact Center

Puts a task into the queue for the dedicated service line. The caller will hear wait music. Allows further interactions when paired with "Check Task" and "Cancel Task".

Why pick this over the "Queue" activity?

While the default "Queue" activity will simply wait until the end criteria is met, the "Queue Task" activity allows for finer control.

For example you can:

Define workflow branching paths with the "Check Task" activity – at any point while the task is still "Queued"
Inform the user about ongoing connection attempts while wait music plays and continues to play after.
Specifically react to call with more control – e.g. only using the "End Task" activity once certain other steps have been performed.

You can find examples on how to use the "Task" type activities in our Workflow Templates.

The following user actions end this task

hangup by customer
accepted by user

Required Predecessor: Accept Conversation

Configurable Properties

Description

Distribution Type

Distribution Type	Description	When to Pick
Broadcast	Rings users simultaneously, selected in a batch size of 10 longest-idle users. The first user to pick up the call via Microsoft Teams will handle the task. Does not apply RONA status as it would otherwise flag the entire user batch size.	Achieves a higher visibility, but the ringing call sets 10 selected agents as "Not Available", not allowing further calls to be distributed to them in the meantime. Makes little sense in high-speed scenarios when the agents are dedicated only to the client to accept calls within a few seconds. Situationally for very large teams where high-volume call handling is more important than equal work distribution.
Direct	Will distribute tasks directly to team members, prioritizing the longest idle (active) team member. RONA time is adjustable. No further actions are necessary aside from accepting the call via Microsoft Teams.	The call with the selected team member is first established via a Teams peer-to-peer call, before it gets escalated to the regular Nimbus conference session. Useful if you have "Busy on Busy" features enabled for your users. Otherwise slower than "Direct Conference" and generally not recommended.
Direct Conference	Same distribution as "Direct", but in this mode, the selected team member is directly invited to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner.	Our General recommendation for most services. Ensures faster handling of calls without blocking too many users at once for the same ringing call. Conference invitations get cancelled if a task was aborted (e.g. Hangup by User, Queue left, Max Wait Timeout Reached ). → See Nimbus Reporting Model.
Pickup	Will show extra "Pickup" controls in the Tasks list of the called team. A call session will be directly established without further intervention, and no further call reporting is possible after this point. If the Nimbus user is unavailable or the session is otherwise ended the call will be lost.	In small teams (e.g. volunteers) where it's acceptable to lose a call and reporting data isn't as important. Pickup by itself does not allow call transfers as Nimbus has no further control over the session.→ If you want to use Pickup with transfer, use "Pickup with Adjustable RONA" or "Pickup Conference" instead. KNOWN ISSUE When any "Pickup" type is selected, skill-based Contact Center Service types may still show the call in a queue, however without a pickup button. → We recommend not using any "Pickup" distribution type in a skill-based distribution scenario.
Pickup with Adjustable RONA	Same as Pickup, but with adjustable RONA. A call session that is not accepted (after "Pickup" is clicked) within the given RONA time can be re-inserted into the task queue or handled otherwise.
Pickup Conference	Same as "Pickup with Adjustable RONA", but will directly invite the agent to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner.	Best performance of all "Pickup" types. Unanswered calls can be re-inserted into the queue and no reporting data is lost. Suitable for scenarios in which the agents can keep an eye on the app. Or to "park" calls in a queue so that other calls can be answered first and then the parked call can be retrieved from the waiting queue. Conference invitations get cancelled if a task was aborted (e.g. Hangup by User, Queue left, Max Wait Timeout Reached ). → See Nimbus Reporting Model.

Conditional Options

^{(shown based on "Distribution Type")}

Description

Adaptive Cards
(toggle)

Requires a "Pickup" Distribution Type to be set.

Enable this for Adaptive Cards to be created automatically within the Service chat channel in MS Teams.

Adaptive cards will update with the call information. Team members can also opt to pick up calls, listen to voice recordings or mark the call as handled within the card itself.

RONA
(toggle, default 00:00:30)

Applies a RONA timeout for the current "Queue" Activity.

This setting relies on "Distribution Type" chosen. If not available the RONA timeout is either hard-coded (field greyed-out) or the "Calling / Queue Timeout" settings apply instead. Also refer to "Distribution Type" above for more info on RONA.

RONA Timeout

Specifies the time the system uses to ring a team member, then switches to the next available user in the queue.

Check Task

Enterprise RoutingContact Center

Checks the current state of the task and takes exit paths accordingly.

Required Predecessor: Queue Task

Configurable Properties	Description
Queue Time Limit (toggle)	Enables a time limit for this task. Rules in the info box below apply.
Queue Time Limit (hh:mm:ss)	Sets the allowed maximum time limit.
Connection Attempts (toggle)	Enables an attempt check for this task. Rules in the info box below apply.
Connection Attempts (number)	Shown when attempts are enabled. Sets the amount of maximum connection attempts.
Both "Queue Time Limit" and "Connection Attempt" limits can be enabled / disabled. The following rules apply: If one criteria is met first, the according exit is taken. If both options are disabled, the "Limit not reached" exit node is used. If there is no task in queue during this step, the "not reached" exit node is used.

Cancel Task

Enterprise RoutingContact Center

Cancels a pending task and all ongoing connection attempts

Required Predecessor: Queue Task

Configurable Properties	Description
None	Important: If the task is currently ongoing with an assigned Agent, the service task is marked as "abandoned" in reporting.

Distribution Priority

Contact Center

This activity overrrides the default "Task Priority" (Default: Normal) configured in your within Distribution Service Settings > Task Priority section.

Required Predecessor: None.

Configurable Property	Description	Behavior	What it looks like
Task Priority	Strict* Highest Very High High Normal (Default for Services) Low Very Low Lowest Nothing Else* * see	When a new task enters the to the queue, it gets a priority according to the service setting: Tasks are distributed according to your currently applied Distribution Policy (e.g. "Longest Idle" or "Most qualified" users first). The order of Tasks is handled by priority, meaning: A new task of higher priority over existing tasks will take precedence and be handled as soon as possible. A new task of equal priority will be sorted in below already existing tasks of the same priority, as it entered the queue at a later point of time. A new task of lower priority will be sorted "in-between" higher priority task rounds, using a weighted round robin method. → See chapter below. When should I select "Strict" or "Nothing Else" as my priority? "Strict Tasks" will always be put on top of your queue. Use this for Emergency services and important VIP hotlines that always should get precedence over anything else in your queue. "Nothing Else" Tasks will only get distributed when your service queue is empty. Note that selecting either "Strict" and "Nothing Else" will ignore round-robin distribution. Tasks get lost due to potentially long queue times.	In views with a task list (e.g. My Overview or Personal Dashboards with "Task" widgets) a "Priority" column indicates how high this task is ranked in the queue. With this setting, tasks may now "displace" existing tasks to a new rank.

Weighted Round Robin Task Distribution

Due to the rules above, task may "starve" for very long in a queue. An example would be a "Lowest" priority task getting outranked by higher priority tasks. To avoid this, a weighted round robin method is in place to mix in lower-priority tasks, equally distributed amonst available users:

Learn more...

_{Q: Calls in Queue | H: Handled | R: Remaining}

Priority	Q	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R
1 (high)	12	2	10			2	8					2	6			2	4					2	2			2	0
2 (med)	6			1	5			1	4					1	3			1	2					1	1			1	0
3 (low)	3									1	2									1	1									1	0
Round Counter		Round 1				Round 2						Round 3				Round 4						Round 5				Round 6
Time (t)		t₁																													t_n
Weighted Round Robin The Round Robin procedure distributes the calls in such a way that the ratio between the individual priority levels is always 2:1. Each time another "Round" is started, that round counter is applied to the "weight" of the remaining tasks. The example above assumes a configuration with 3 priority levels. There are 21 calls in the queue, with the following priority: 12 calls with priority 1 6 calls with priority 2 3 calls with priority 3 Following the 2:1 rule, the calls are queue over time t as follows: Round 1: High Med tasks added in 2:1 ratio. No "Low" priority tasks in Round 1 as "Medium" task count outweighs the low task count. Round 2: High Med Low tasks added in 2:1 ratio. The "Low" priority tasks get a round-multiplier added to their weight, now outweighing "Medium" tasks and thus are added in a 2:1 ratio. Round 3: Same as Round 1. Sources: Weighted Round Robin (Wikipedia Article). Please note that this example only works as long as no new calls are being processed. Calls with strict or no priority are not considered in this rule.

Task Priority in "Queue" workflow activites

In a multi-service environment, the "Priority" setting effects your "Distribution Type" setting within a Queue Workflow Activity:

Scenario	Setup	Outcome	Learnings
2 Services A&B using a "Broadcast" Queue Activity setting in their Workflows.	Service A : Broadcast, Calling Timeout - 30, priority "Low" Service B: Broadcast, Calling Timeout - 30, priority "High" Both services pool the same 10 users, Active and Available	A first (low) call to Service A will block all 10 users with the call invitation. A second (high) call to Service B enteres the queue. All users are still blocked for the 30s timeout. The first (low) call is declined by 1 user, which then immediately gets the second (high) call distributed. All 9 users are still blocked by the (low) call engagement until it is handled. Only the 1 user finishing the (high) engagement may take the next (high) priority call.	The "Broadcast" Queue setting is fixed to a 10-user batch. In a Priority scenario the first call entering – even if lower priority – may block higher priority tasks.

Interaction with other Services

Since only Contact Center services make use of the priority feature, this activity has no effect on other Service types.
In a non- Contact Center service the task priority is reset to the Default (Normal).
If the task is prioritized but then transferred, the priority is reset as well and will change according the priority settings of that service.

Check Activities

Check Opening Hours

Performs a check on the current Opening Hours calendar applied to the service and exits accordingly.

Required Predecessor: None - can work even without accepting a call (e.g. to Transfer to Service, Accept Conversation or Disconnect Conversation immediately)

Configurable Properties

Description

None

Will exit based on currently active Opening Hour rule currently in effect for your General Service Settings.

Exits match the period types of opening hours (open, closed, holiday, special 1-4), allowing you to branch out your workflow accordingly.
If no opening hours are defined "default" exit on this activity is taken.

Notes on Opening Hours:

If no opening hours calendar is defined in your General Service Settings, the "Default" exit in your activity is taken.
Once created, an Opening Hour calendar must have a default opening state (e.g. "Closed") assigned.
If both primary and secondary opening hours are defined in your General Service Settings, precedence rules apply:

Click here to learn more...

Each team may decide if the opening hours are defined as primary or secondary. This is determined via service-individual Service Settings > "General" Tab.

Ruleset: Primary and Secondary Opening Hours

Opening Hours Period Ruleset:

If at least one defined period is found in the primary opening hours calendar, this period is prioritized.
If there is no period in defined primary calendar, the secondary calendar period is applied.
If no appointment is found in either calendar (with a secondary configured), the "Default" state of the first calendar is used.
The default of the secondary calendar never applies in a two-calendar scenario. If the secondary calendar has no periods defined it is effectively ignored.

Rule of thumb: Primary Defined? > Secondary Defined? > Both no? > Use Primary Default!

An example of how this rule is applied can be found below.

Service Settings with applied opening hours. The current applicable status is shown under "Active Opening Hours".

Show me an example

In this example there are two calendars defined: one provided the Admin (e.g. Company-Wide special holidays) and one "Service Specific" calendar created by a Team Owner.

For simplicity we're assuming these calendars operate on a "whole day" basis for one week.

Each day will be handled differently to illustrate a case from the rules above.

The calling customer will experience the service status as follows:

On Monday the primary calendar has a "holiday" defined. → The service workflow will react according to the path defined for holidays (usually a closed-announcement), otherwise the default applies (also closed).
On Tuesday the primary calendar is default "closed", however the secondary has a special period defined. → In this case the the secondary calendar takes precedence.
On Wednesday the primary calendar is default "closed", however the secondary has an "open" period defined. → In this case the secondary calendar "open" period takes precedence.
On Thursday the primary calendar and secondary calendar have a default status, but no specific periods defined. → The primary default "closed is used, secondary default gets always ignored.
On Friday the primary calendar has a special event type defined. → Depending on how the service workflow is configured, it will react to the "special" primary calendar period (e.g. same as Tuesday).

General recommendation: The safe bet is to handle all exits on your workflow activity, as you you may lose calls otherwise.

All cases in your activity should be handled

Availability Based Routing

Enterprise Routing Contact Center

Allows to route the call based on overall team availability.

Required Predecessor: None - can work even without accepting a call (e.g. to Transfer to Service, Accept Conversation or Disconnect Conversation immediately)

Configurable Properties

Description

Service

Allows to select the target Service (within your tenant) for which the availability check and routing is performed for.

Leaving this at "Current Service" will dynamically check the status of the service currently using this workflow. This allows for multiple services to use the same workflow with an "Availability based Routing" step without having to adapt the step's properties individually to their needs.

You can use this workflow step multiple times within the same workflow check different services simultaneously, e.g. to achieve an availability-based escalation and routing routine.

Current Availability
(Node Exits)

The activity has 3 exits based on the current overall team status (look-ahead). The availability depends on the User assignment type of your Service.

How can I determin the type of service I'm in? Team owners can access Distribution Service Settings and inspect the "User Assignment Type". Note that this type is determined during Service Provisioning and cannot be changed.

Service Availability (Exit condition)	MS Teams-based Service	Skill-based Service
No One Available	All users are inactive – or active but set "offline" in MS Teams)	No users online or available within the service's Distribution Policy levels.
In Time Available	All active users are not immediately available e.g. "DND/Away/Busy" or when occupied by another call.	No users in the 1st Distribution Policy level are not available, but in any other levels users are available.
Direct Available	At least 1 user is available = MS Teams presence set "available" and also set to "active" in Nimbus).	At least one in the 1st Distribution Policy is available and ready to take a task.
Notes	The "Active" state toggle in a team can make users unavailable regardless of MS Teams presence. Additionally, MS Teams Presence also impacts the service availabiltiy. See note below.	The Duty States toggle for each user determines a user's currently applicable Responsibility Profile considered for skill based distribution. Additionally, MS Teams Presence also impacts the service availabiltiy. See note below.

MS Teams Presence status impact on availability

You can adjust Distribution Service Settings to include / exclude users from the availability count, based on their MS Teams presence state.

Check Available Users

Enterprise Routing Contact Center

Performs a lookahead-check on the users / Agents available in a Nimbus service and stores the value in a Parameter.

Required Predecessor: None

Configurable Properties

Description

Service

Can either be the "Current Service" – e.g. in workflows used by multiple services – or a specific service.

Parameter

Requires at least one Parameter to be defined and available as selectable "placeholder" under the same Organization Unit (or higher up to Tenant level).

This activity stores output into a custom Parameter for processing, which can then be used within the same workflow (e.g. a " Check Parameter " activity). Note that the parameter's default value is being overwritten once it passes through this activity.

Once this activity is reached, it checks the number of available users of the specified Service:

- For MS Teams team-based Services all available team members are considered.
- For Contact Center Services only available users in the first Distribution Policy level are taken into consideration.

→ For more information, read our pages on Service Type and the according User assignment method.

Check Parameter

Enterprise Routing Contact Center

Allows to check and react on system Fields and custom Parameters.

Required Predecessor: None - responds to parameters updated during Trigger Events.

Configurable Properties

Description

Parameter Type

Offers a choice between:

Nimbus → See list of Context - Fields and Parameters
Custom parameters that you can define and fill using the Microsoft Power Automate Connector for Nimbus

Custom Type

Dependent on the "parameter type" selected:

A list of Nimbus Fields and Parameters
Custom Parameter of the following type:
- Context--> $(CustomContextParameters.<Name>)
- Customer Field --> $(Customer.CustomFields.<Name>)
- Customer Telephone --> Numbers $(Customer.TelNumbers.<Name>)

Name

Only shown when "parameter type" = Custom is selected.

Allows you to define the a name used for the parameter. This name must match the dynamic value when using the Nimbus Microsoft Power Automate Connector.
Note that the parameter name depends on your "Custom Type" choice above, e.g. $(Customer.CustomFields.YourExampleName

Checks
(Node Exits)
(1...10 allowed)

Allows to define one or many regular expression checks on the "parameter type / name" chosen above.

Notes:

By default 1 "Check" exit is defined. Up to 10 can be defined each with individual node exits. Note that you can also nest several "Check Parameter" activities if you need to handle more parameters.
Checks will be performed in your defined order. The first valid check will determine the activity exit. Any further matching expressions are ignored.
Regular expressions cannot be empty. By default ".*" will allow anything as a parameter content = Parameter is present.

Show me some Regular Expression examples...

These are some common Regular Expressions (RegEx) we recommend to use within Nimbus. To test your own regular expressions please consider using this online tool: RegExr: Learn, Build, & Test RegEx.

Description	Regular expression	Check perform on Fields and Parameters
Incoming Call is from an external PSTN number	^\+[1-9]\d{1,14}$	MicrosoftCallerId
Incoming call is from an internal Teams account (UPN)	^[^@]+@.+$	CallerUPN
Incoming number is from Germany/UK Germany +49 UK +44 Check country code	^([+]49)\d+ ^([+]44)\d+	MicrosoftCallerId
Caller is anonymous	^Anonymous	MicrosoftCallerId
The incoming call is from Switzerland OR Germany	^([+]49)\|^([+]41)\d+	MicrosoftCallerId
The value equals 1	^[1]$	Queue Position Custom Parameter
The value equals 2	^[2]$	Queue Position Custom Parameter
The value equals or is greater than 3	^[3-9]$\|^([1-9]\d\|[1-9]\d{2,})$	Queue Position Custom Parameter
No user is available	^[0]$	Available Users Custom Parameter
One or more users available	^[1-9]$\|^([1-9]\d\|[1-9]\d{2,})$	Available Users Custom Parameter
The value is true	^(true\|True\|1)$	Custom Parameter
The value is not Empty	^.	Custom Parameter
The lenght of the string is in between 5 or 10 and not less or more	^.{5,10}$	Custom Parameter
The lenght of the string equals 3	^.{3}$	Custom Parameter

Also refer to Context - Fields and Parameters for a comprehensive list on parameters handled by Nimbus.

Check Queue Position

Enterprise Routing Contact Center

Performs a lookahead-check on the (potential) queue position in a Nimbus service and stores the value in a Parameter.

Required Predecessor: None

Configurable Properties

Description

Service

Can either be the "Current Service" for workflows commonly used by multiple services or a specific service.

Parameter

Requires at least one Parameter to be defined and available as selectable "placeholder" under the same Organization Unit (or higher up to Tenant level).

This activity stores output into a custom Parameter for processing, which can then be used within the same workflow (e.g. a " Check Parameter " activity). Note that the parameter's default value is being overwritten once it passes through this activity.

Once this activity is reached, it checks the number of available users of the specified Service

- If the call was already added in queue (-→ "Queue Task" activity) the current position is saved into the parameter.
- If call was not added, the queue length +1 of the selected "Service" is saved into the parameter.

By default this activity does not create a "visible" outcome. We recommend to follow up with a "Check Parameter" activity and route your customers according to the queue position value (e.g. add further announcement, voicemail, play music activities).

Workflow Troubleshooting

The workflow editor is a very powerful tool, but also allows for misconfigurations and lost calls. Listed below are the most common issues our users report, and how to avoid them:

Issue	Caused by	How to Avoid
Calls are not getting accepted at all	"Start" node wasn't connected to any other Workflow Activity node.	Always ensure that the "Accept Conversation" activity is used as soon as possible.
Calls are accepted but not handled (to completion)	Announcements or similar activities have exit nodes which are not handled, resulting in stuck calls.	Always make sure to handle exit cases of activities. Always end calls with an escape - e.g. "Disconnect Conversation" (even after "transfer" scenario).
Calls are stuck in an infinite loop	Steps redirecting on themselves with no exit condition.	Always end calls with an escape - e.g. "Disconnect Conversation" (even after "transfer" scenario).
Calls were not re-entered in the same Queue	Calls reaching the end of a Queue e.g. "Timeout" getting re-inserted into the same queue. This causes inconsistent reporting states for the call and sometimes Infinite loops.	Always end calls with an escape - e.g. "Disconnect Conversation" (even after "transfer" scenario). "Queue" each caller only once per service. Use Multiple "Queue" activities within a workflow by clearly separating them, e.g. by "Input Customer (IVR)" so each path can only be taken once. Use the "Check Task" and "Cancel Task" activities to play announcements or react otherwise to calls already in a (long) queue.
Parameter checks fail or the default exit is always taken	Either the parameter is not written correctly (or not in time) or the validation with regular expression fails to find a pattern. In either case the workflow activity takes the default exits.	When accessing external systems, allow for time to process. Refer to Microsoft Power Automate Connector pages and Trigger Events to see when Context - Fields and Parameters are updated in Nimbus. Use "Announcements" or "Play Music" activities so external flows can finish. Refer to our Regular Expressions page for some examples and test your expressions with an external editor/validator.

Workflow Best Practice

Make sure to use Workflow Templates as pointers on how your workflows should be structured. Gradually expand and test your configurations to avoid mistakes.
We gradually expand our Power Automate Use Cases with examples that also include the workflow editor. Make sure to check back regularly get the most out of Nimbus and your external systems.
Keep in mind that any workflow changes (either in Distribution Service Settings or the workflow itself) take effect immediately. We therefore recommend to test larger changes on a (hidden) service with a test call.