List of Workflow Activities

Notes

The following section will describe all workflow activities and their properties. The terms "Workflow Element" and "Workflow Activity" are used synonymous.
Certain Activities have required predecessors, stated with this icon:
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.

Known Issue - Unrecognized "Input Customer" DTMF tones when any user left a "Conference" call prior

There is a known issue where MSFT (Microsoft) doesn't recognize DTMF tones if any participant left the conference before. In Nimbus this issue occurs as the bot join any "conference" type conversation to deliver and retrieve call data.

When does this occur?

This issue occurs in the following specific call transfer cases:

transfer via Attendant to a target service where the "Input Customer" activity is configured. The issue occurs regardless of "Queue" distribution setting in the target service.
transfer via Workflow when the target service has a "Queue" with a "Conference" (Direct or Pickup) activity before the actual "Input Customer" occurs.

Effect: To Nimbus it seems like the customer didn't input anything (as MSFT doesn't pass the DTMF event). In a workflow the customer can repeat the input choice, but the "input is not recognized" response will repeat.

What are the workarounds?

Workarounds:

Attendant Console: Transfers will disable IVR on the receiving service (by using the NR-exit or skip over in case of a loop) during the call to improve the user experience. No further action is required.
Workflows: If you need to transfer to a service with an "Input Customer" workflow activity configured, do not pick a "Conference" (Direct or Pickup) type of call distribution in your "Queue" workflow step.
In a non-transfer scenario this issue does not occur and IVR works as intended.

When is this resolved? This issue needs to be fixed on MSFT side, so currently we cannot provide you with an ETA for this fix. Get in contact with Luware Customer support if you need help finding a solution.

Conversation Handling

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.

Required Predecessor: Accept Conversation

Configurable Properties

Description

Announcement Type:

Text-to-Speech with "Prompt Language" select & "Prompt Text" Field
Resources - define an audio file (e.g. speech announcement or music).

Resources are part of Service Settings.

Input Customer (IVR)

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 "Prompt Language" select & "Prompt Text" Field Resources - define an audio file (e.g. speech announcement or music). Resources are part of Service Settings.
Prompt Language	Allows to select the locale / voice to use when using the Text-to-Speech engine.
Input during announcement (Barge in)	Allows to react to caller input during announcement: enabled - from the moment when the main Prompt was started disabled - after the main Prompt was fully played When enabled, the "silence timeout" timer starts immediately upon input. Any prompts at this point are stopped.
Queue timeout toggle (Max Wait time)	Enabled a maximum timeout for this workflow activity.
Queue timeout time hh:mm:ss (default 00:00:30)	Specifies maximum waiting time for a response. The other (missing, wrong) input prompts will be played within this timeframe. If nothing was entered or this maximum timeout is met, the "No Recognition" (NR) exit node is used.
Time to complete started input hh:mm:ss (min 00:00:01, max 00:00:09)	Starts counting once a caller has entered the first digit. After expiration the expected input is checked and or wrong input section is handled.
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 of the "Expected input" 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 (ex. input 1: 123, input 2: 12, and the caller enters 12) the "time to complete started input" applies before the DTMF is evaluated.
Missing Input (Silence Prompt)	Description
Timeout hh:mm:ss (default 00:00:10)	Time for the caller to enter any input. Afterwards the silence Prompt is played. If any input was made the "time to complete started input" time applies instead.
1st Prompt AND IF CONFIGURED 2nd Prompt (escalation)	Message to play when the input was not occurring in the "time to complete" A selection of the following options: Text-to-Speech with "Prompt Language" select & "Prompt Text" Field Resources - define an audio file (e.g. speech announcement or music). Resources are part of Service Settings. If User enters no input within the silence timeout: 1st Prompt → (if configured) does the following: Play "1st Prompt" for missing input otherwise play the "Main Prompt" 2nd Prompt → (if configured) does the following: Play "2nd Prompt" for missing input Play "1st Prompt" for missing input otherwise play the "Main Prompt"
Wrong Input (no recongnition)	Description
1st Prompt AND IF CONFIGURED 2nd Prompt (escalation)	Message to play when the input was not recognized. A selection of the following options: Text-to-Speech with "Prompt Language" select & "Prompt Text" Field Resources - define an audio file (e.g. speech announcement or music). Resources are part of Service Settings. If User enters no input within the "time to complete started input" timeout: 1st Prompt → (if configured) does the following: Play "1st Prompt" for wrong input otherwise play the "Main Prompt" 2nd Prompt → (if configured) does the following: Play "2nd Prompt" for wrong input Play "1st Prompt" for wrong input otherwise play the "Main Prompt"

Collect Information

Enterprise RoutingContact 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

Prompt Type

A selection of the following options:

Text-to-Speech with "Prompt Language" select & "Prompt Text" Field
Resources - define an audio file (e.g. speech announcement or music).

Resources are part of Service Settings.

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

Allows to enter the DTMF digits already during the main announcement. The Announcement will stop automatically after the first DMTF input.

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 below.

Node Exits

Input Exit Conditions

Note 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

Required Predecessor: Accept Conversation

Configurable Properties

Description

Source

Allows to choose a playlist (default) or a single resource to upload

Playlists can be defined within the Settings Tab.

Duration

Enables or Disables (default) the specified duration for this step

Duration set: Play the list of files after each other for the defined time. Shuffle the playlist if enabled before start to play
Duration not set: play the list of files after each other, restart the list if the end is reached. Shuffle the playlist if enabled on each start

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.

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

Voice Message (Recording)

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	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 Voicemails channel in MS Teams. Example Message: `Voice message has been received from $(Customer.FirstName) $(Customer.LastName) / $(Caller.TelNumber)` CODE Also supports MSFlow Variables, 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.
Parameter (Custom / System)	Allows the use of custom-defined or system fields and parameters in the message. Choices are inserted at the current cursor position in the "Message" field. Learn more about Context - Fields and Parameters. Parameters and Context will be exchanged with data once the activity is executed. The context info is also used in Adaptive Cards. → See info below

Interaction within Adaptive Cards

This activity interacts with "Adaptive Cards" to the following effects:

An Adaptive Card is sent to the configured 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.

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 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.

Caller ID during transfer

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.

Transfer to PSTN limitation

Out of box Nimbus and affiliated addons can only perform PSTN transfers according to Microsoft services licensing & constraints.

Which PSTN license do I need to acquire?

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

Your Setup	Required License
Microsoft Phone System Direct Routing	"Microsoft Teams" (App license, available as part of the Microsoft 365 E1 / E3 / E5 and other packages) + "Microsoft Teams Phone Standard" or "Microsoft Teams Phone Standard - Virtual User"
Microsoft Phone System with Calling Plan	"Microsoft Teams Phone Standard" or "Microsoft Teams Phone Standard - Virtual User" + "Microsoft 365 Domestic Calling Plan" or "Microsoft 365 Domestic and International Calling Plan" + " Communication Credits" (if these aren't already included as part of your plan)

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 add-on licenses.

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

Nimbus does currently not support call-forwarding to either UPN or PSTN numbers of Teams-native "Auto Attendants" and "Call Queues". A transfer attempt will lead to a call abort.

Causes and Workarounds

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

If you are interested in a possible workaround via an existing direct routing SBC, get in contact with our support. However, please note that this solution can cause additional cost and negatively affect voice quality.

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.

Timeout,
hh:mm:ss

Precondition: Target is a an (internal) user in Teams. "Leave Nimbus" is disabled.

When the timeout is set and expires, the transfer task is aborted "Failed" exit is taken.

Leave Nimbus

Precondition: Target is a an (internal) user in Teams or an (external) PSTN Number.

When disabled (default) a conference will be started and the target will be invited by the Nimbus service to accept. → When the timeout is met or the target doesn't accept, the "Failed" exit is taken.
When enabled the caller is directly forwarded to the target without a service conference. If target has voicemail enabled on their side, then the call will be forwarded to VM in case target does not accept.

Direct Transfer to Voicemail

Precondition: Target is a an (internal) user in Teams. "Leave Nimbus" is enabled.

Directly attempts to forward the caller to voicemail. → When the target has disabled voicemail - or some other technical issue prevents call acceptance - the "Failed" exit is taken.

Waiting Music

Precondition: Target is a an (internal) user in Teams. "Leave Nimbus" is disabled.

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

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

Waiting Music will be played until the call was accepted or cancelled.
Music resources or playlists shorter than the timeout will put on loop playback.

Transfer Task Results

Transfer task results (for Service KPI and Reporting) can depend on the following transcripts:

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

Check

Check Opening Hours

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 - Exits the activity based on Opening Hours in effect.

Exit nodes match the types of opening hours (open, closed, holiday, special), allowing you to branch out the workflow accordingly.

Ruleset: Primary and Secondary Opening Hours

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

Selected primary, secondary and currently active opening hours shown

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 > Primary Default

Each Opening Hour calendar does have a "default" state. If a type is not defined, the "default" exit node of this activity applies.

Availability Based Routing

Enterprise RoutingContact 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 this "Availability based Routing" step without having to adapt the step's properties individually to their needs.

Tip: You can also 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 service status (look-ahead):

No One Available - Currently all users are inactive (or active but set "offline" in MS Teams)
In Time Available - Currently active users are not immediately available e.g. "DND/Away/Busy" or when occupied by another call.
You can further adjust Service Settings > Distribution Tab > "Conversations Distribution" to include / exclude users based on their MS Teams client presence state.
Direct Available - Currently at least 1 user is available = MS Teams presence set "available" and also set to "active" in Nimbus).

Availability in Skill-based distribution services

Contact Center

When using this activity in a skill-based service with Distribution Profiles and Policies applied, the availability is calculated based on rules as follows:

DirectAvailable: Applies when in the 1st distribution profile at least one user is available and ready to take a task.
InTimeAvailable: Applies when in the 1st distribution profile users are not available, but in any other profile users are available.
NoOneAvailable: Applies when in all distribution profiles no users are online / available.

Check Parameter

Enterprise RoutingContact Center

Allows to check and react on system fields or external 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:

Parameter Type

Parameters to pick from:

Custom

Custom Parameters of the following type:

Custom Context Parameter Predefined: A list of user-created Parameters. Must be within your selected service's Organization Unit to be visible.
Custom Context Parameters → $(CustomContextParameters.<Name>)
Customer Custom Fields → $(Customer.CustomFields.<Name>)
Customer Tel Numbers → Numbers $(Customer.TelNumbers.<Name>)

Context - Fields and Parameters can be retrieved and updated with the Microsoft Power Automate Connector e.g. by connecting and involving an external CRM system / directory for data exchange.

Nimbus

A list of Nimbus-native System Fields and Parameters.

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...n allowed)

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

By default 1 "Check" exit is defined. Further can be added, each with an individual name for the node identification.
Regular expressions cannot be empty. By default ".*" will allow anything as a parameter content = Parameter is present.
Checks will be performed in your defined order. The first valid check will determine the activity exit. Any further matching expressions are ignored.

Queue

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

→ voice message
→ transfer
→ cancel task
→ disconnect call

The following user actions also end this task

hangup by customer
accepted by user

Required Predecessor: Accept Conversation

Configurable Properties

Description

Distribution Type

The following types of queue distribution are available:

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.	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

Requires a "Pickup" Distribution Type setting.

Enable Adaptive Cards to be created automatically within the "Posts" channel. These cards include extended call information. Team members can also opt to pick up calls via from therein.

RONA

Applies a RONA timeout for the current Queue Activity.

This setting relies on "Distribution Type" chosen. If not available the timeout is either hard-coded (field greyed-out) or the "Max Wait Timeout" applies instead.

RONA Timeout

Specifies the time the system uses to ring a team member, then switches to the next in 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 played to the caller when in queue.

Playlists and Resources (music) can be defined within the Settings Tab .

Queue Task

Enterprise RoutingContact Center

Puts a task into the queue for the dedicated service line. The caller will hear wait music. Ends when max. wait time is reached. Allows for further interactions

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 different workflow branching paths with the "Check Task" activity and 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 to criteria with more control options, e.g. to cancel the task with 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
Conditional Options ^{(shown based on "Distribution Type")}	Description
Adaptive Cards	Requires a "Pickup" Distribution Type setting. Enable Adaptive Cards to be created automatically within the "Posts" tab of MS Teams. These cards include extended call information. Team members can also opt to pick up calls via from therein.
RONA	This setting relies on "Distribution Type" chosen. If not available the timeout is either hard-coded (field greyed-out) or the "Max Wait Timeout" applies instead. Applies a RONA (Return on no Answer) for the current Queue Activity. RONA flags the Nimbus user that didn't take the call for a certain time, so no further calls are distributed to the same user. The caller is returned to the queue.
RONA Timeout	Specifies the time the system uses to ring a team member, then switches to the next in queue.

Check Task

Enterprise RoutingContact Center

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

Required Predecessor: Queue Task

Configurable Properties	Description
Queue Time Limit	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 enabled	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.

Workflow Troubleshooting

Potential Issues with Workflows

The workflow editor is a very powerful tool, but also allows for misconfigurations. Listed below are the most common issues 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.

Check our Workflow Templates for examples on how a workflow should be structured. Gradually expand and test your configurations to avoid mistakes.