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:  (tick)
  • 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.

(question) 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 PropertiesDescription
None

Controls when your call will be accepted (also for Reporting / KPI purposes).

(lightbulb) 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.

(tick) Required PredecessorAccept Conversation

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

(info) 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.

(tick) Required PredecessorAccept Conversation

Configurable PropertiesDescription

Main Prompt Type*

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

(info) Resources are part of Service Settings.

Prompt LanguageAllows 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 

(lightbulb) 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. 

(lightbulb)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.

(lightbulb) 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.

(lightbulb) 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.

(lightbulb) 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.

(lightbulb) 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). 

(info) Resources are part of Service Settings.


If User enters no input within the silence timeout:

  1. 1st Prompt → (if configured) does the following:
    1. Play "1st Prompt" for missing input
    2. otherwise play the "Main Prompt"

  2. 2nd Prompt → (if configured) does the following:
    1. Play "2nd Prompt" for missing input
    2. Play "1st Prompt" for missing input
    3. 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). 

(info) Resources are part of Service Settings.


If User enters no input within the "time to complete started input" timeout:

  1. 1st Prompt → (if configured) does the following:
    1. Play "1st Prompt" for wrong input
    2. otherwise play the "Main Prompt"

  2. 2nd Prompt → (if configured) does the following:
    1. Play "2nd Prompt" for wrong input
    2. Play "1st Prompt" for wrong input
    3. 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.

(tick) 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). 

(info) 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

(tick) 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

(tick) 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:

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

(info) 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"
    (warning) 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

(tick) Required PredecessorAccept Conversation

Configurable PropertiesDescription

Source

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

(info) 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

(lightbulb) 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

(lightbulb) 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 PropertiesDescription
NoneActs 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.

(tick) Required PredecessorAccept Conversation

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

(lightbulb) 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

(lightbulb) 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

(info) 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.

(lightbulb) Choices are inserted at the current cursor position in the "Message" field.

(info) Learn more about Context - Fields and Parameters.

(info) 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.

(lightbulb) 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.

(tick) Required PredecessorAccept Conversation

Configurable PropertiesDescription

Target 

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

  • a Service Line as transfer target.
    (lightbulb) You can search for Service Lines of the same Nimbus tenant
  • a User to transfer to:
    (lightbulb) 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?

(tick) 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 SetupRequired 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).

(warning) 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:


(info) 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.


(lightbulb) 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.

(lightbulb) 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

(tick) 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

(tick) 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

(tick) 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 

(tick) 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. 

(info) 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 AcceptCustomer hung up the call before it was accepted(error) False
Customer Hangup In IVR
Customer Hangup In IVR after queue
Customer hung up the call before it was put into the queue once(error) False
Customer Hangup In QueueCustomer hang up the call during the time the task was enqueued(error) False
User AcceptedUser accepted the task and was connected to the customer(tick) True
User Internal Transfer SuccessUser accepted the task and transferred it to another service Line or user(tick) True
User External Transfer SuccessUser accepts the task and transferred to a non service line or user(tick) 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
(error) False
(error) False
(error) False
Workflow Conversation RecordedWorkflow recorded a voice message / mail(tick) True
Workflow Internal Transfer SuccessfulWorkflow transferred the call to another Service Line Successful(tick) True
Workflow Internal Transfer FailedWorkflow couldn't transfer the call to another Service Line(error) False
Workflow External Transfer SuccessfulWorkflow transferred the call successful to a non service line target(tick) True
Workflow External Transfer FailedWorkflow couldn't transfer the call to a non Service Line target(error) False

Check


 Check Opening Hours 

(tick) Required PredecessorNone - 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.

(lightbulb) Rule of thumb: Primary Defined > Secondary Defined > Primary Default

(info) 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 .

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

Configurable PropertiesDescription
Service

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

(lightbulb) 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.

(lightbulb) 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.
    (lightbulb) 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.

(tick) Required PredecessorNone - responds to parameters updated during Trigger Events.

Configurable PropertiesDescription
Parameter Type

Offers a choice between:

Custom Type

(info) 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>)

(info) 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

(tick) 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.
(lightbulb) 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


 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 

(tick) Required PredecessorAccept Conversation

Configurable PropertiesDescription
Distribution Type

The following types of queue distribution are available:


Distribution TypeDescriptionWhen to Pick
BroadcastRings 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.

DirectWill 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  (star)

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.

(star) Our General recommendation for most services. Ensures faster handling of calls without blocking too many users at once for the same ringing call.

(info) 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 (warning)

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.

(warning) 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.

(info) 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

(tick) 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.

(info) 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.

(info) 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 

(question) 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.

(lightbulb) 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 

(tick) Required PredecessorAccept Conversation

Configurable PropertiesDescription
Distribution Type

Conditional Options

(shown based on "Distribution Type")

Description

Adaptive Cards

(tick) 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
 

(tick) 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.

(lightbulb) 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.

(tick) Required PredecessorQueue Task

Configurable PropertiesDescription

Queue Time Limit

Enables a time limit for this task.

(info) 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.

(info) Rules in the info box below apply.

Connection Attempts #
(number)

(tick) 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

(tick) Required PredecessorQueue Task

Configurable PropertiesDescription
None(warning) 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:

IssueCaused byHow to Avoid
Calls are not getting accepted at allStart 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.

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