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).
|
Announcement
Plays a defined resource or text to the caller.
Required Predecessor: Accept Conversation
Configurable Properties | Description |
---|---|
Announcement Type: |
|
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* |
|
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:
|
Queue timeout toggle | 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.
|
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.
|
Expected Input | Description |
Name | A clear name for the exit node.
|
DTMF | Allows to enter multiple DTMF tones / digits per exit node.
|
Missing Input (Silence Prompt) | Description |
Timeout | Time for the caller to enter any input. Afterwards the silence Prompt is played.
|
1st Prompt | Message to play when the input was not occurring in the "time to complete" A selection of the following options:
If User enters no input within the silence timeout:
|
Wrong Input (no recongnition) | Description |
1st Prompt | Message to play when the input was not recognized. A selection of the following options:
If User enters no input within the "time to complete started input" timeout:
|
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:
| ||||||||
Prompt Language | Allows to select the locale / voice to use when using the Text-to-Speech engine. | ||||||||
Prompt Text |
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 |
Custom parameters can be used in the following areas:
| ||||||||
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:
| ||||||||
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.
| ||||||||
Node Exits | Input Exit Conditions Note the "input received" activity exit is taken under the following conditions:
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":
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 |
Duration | Enables or Disables (default) the specified duration for this step
|
Duration (hh:mm:ss) | Determines how long the playlist or resource is played
|
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.
|
Message | Will send a message to the Voicemails channel in MS Teams. Example Message:
CODE
|
Parameter (Custom / System) | Allows the use of custom-defined or system fields and parameters in the message.
|
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.
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:
Caller ID during transfer
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?
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:
Luware Support
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 WorkaroundsThis is caused by Microsoft Teams limitations and cannot be circumvented by Nimbus.
| ||||||||||||||
Timeout, |
When the timeout is set and expires, the transfer task is aborted "Failed" exit is taken. | ||||||||||||||
Leave Nimbus |
| ||||||||||||||
Direct Transfer to Voicemail |
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 |
Allows to choose a playlist (default) or a single resource to play.
|
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 | |
Customer Hangup In IVR Customer Hangup In IVR after queue | Customer hung up the call before it was put into the queue once | |
Customer Hangup In Queue | Customer hang up the call during the time the task was enqueued | |
User Accepted | User accepted the task and was connected to the customer | |
User Internal Transfer Success | User accepted the task and transferred it to another service Line or user | |
User External Transfer Success | User accepts the task and transferred to a non service line or user | |
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 | |
Workflow Conversation Recorded | Workflow recorded a voice message / mail | |
Workflow Internal Transfer Successful | Workflow transferred the call to another Service Line Successful | |
Workflow Internal Transfer Failed | Workflow couldn't transfer the call to another Service Line | |
Workflow External Transfer Successful | Workflow transferred the call successful to a non service line target | |
Workflow External Transfer Failed | Workflow couldn't transfer the call to a non Service Line target |
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:
|
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.
|
Current Availability (Node Exits) | The activity has 3 exits based on the current overall service status (look-ahead):
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:
|
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:
| ||||||
Custom Type |
| ||||||
Name |
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. | ||||||
Checks (Node Exits) (1...n allowed) | Allows to define one or many regular expression checks on the "parameter type / name" chosen above.
|
Queue
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:
| ||||||||||||||||||||
Conditional Options (shown based on "Distribution Type") | Description | ||||||||||||||||||||
Adaptive Cards |
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.
| ||||||||||||||||||||
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.
|
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 |
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 |
Applies a RONA (Return on no Answer) for the current Queue Activity.
|
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.
|
Queue Time Limit | Sets the allowed maximum time limit |
Connection Attempts enabled | Enables an attempt check for this task.
|
Connection Attempts # (number) |
Sets the amount of maximum connection attempts. |
Both "Queue Time Limit" and "Connection Attempt" limits can be enabled / disabled. The following rules apply:
|
Cancel Task
Enterprise RoutingContact Center
Cancels a pending task and all ongoing connection attempts
Required Predecessor: Queue Task
Configurable Properties | Description |
---|---|
None |
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 |
|
Calls are accepted but not handled (to completion) | Announcements or similar activities have exit nodes which are not handled, resulting in stuck calls |
|
Calls are stuck in an infinite loop | Steps redirecting on themselves with no exit condition |
|
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 |
|
Check our Workflow Templates for examples on how a workflow should be structured. Gradually expand and test your configurations to avoid mistakes.