Workflows and Workflow Actions
You can use workflows to automate common repetitive agent tasks. A workflow has a unique name and a helpful description. Use the Manage Workflows and Manage Workflow Actions gadgets to view, add, edit, or delete workflows and workflow actions.
All workflows are team-level workflows. You cannot create a global workflow. If you need a global workflow, create a team workflow and assign it to all teams.
Finesse supports the following number of workflows and workflow actions:
-
100 workflows per Finesse system
-
100 actions per Finesse system
-
20 workflows per team
-
5 conditions per workflow
-
5 actions per workflow
-
5 variables per action
-
queueNumber
-
queueName
-
callKeyCallId
-
callKeyPrefix
-
wrapUpReason
Click the column headers to sort workflows and workflow actions in ascending or descending order.
The following table describes the fields on the Manage Workflows gadget.
Field |
Explanation |
---|---|
Name |
The name of the workflow. The name must be unique and can be a maximum length of 40 characters. |
Description |
The description of the workflow. The description can be a maximum length of 128 characters. |
The following table describes the fields on the Manage Workflow Actions gadget.
Field |
Explanation |
---|---|
Name |
The name of the workflow action. The name must be unique and can be a maximum length of 64 characters. |
Type |
The type of workflow. Possible values are Browser Pop, HTTP Request. |
Actions on the Manage Workflows and Manage Workflow Actions gadgets:
-
New: Add a new workflow or workflow action
-
Edit: Edit an workflow or workflow action
-
Delete: Delete a workflow or workflow action
-
Refresh: Reload the list of workflows or workflow actions from the server
You can configure workflow actions to be handled by the Finesse desktop or in a third-party gadget. A third-party gadget can be designed to handle the action differently than Finesse does.
Each workflow must contain only one trigger. Triggers are based on Finesse dialog events. Dialog events include the following:
-
When a call arrives
-
When a call is answered
Note
If you set a workflow to trigger when a call is answered, the workflow runs when an agent answers an incoming call or makes an outgoing call, or when a customer answers an Outbound Option call.
-
When a call ends
-
When making a call
- While previewing an Outbound Option call
The workflow engine uses the following simple logic to determine whether to execute a workflow:
- To determine whether a workflow should execute, its trigger set and conditions are evaluated against each dialog event received.
-
The workflow engine processes workflow events for the first call that matches any configured workflow's trigger set and conditions. No other workflows run until this call has ended. If the agent accepts a second call while still on the first call, workflows do not run on the second call even after the first call has ended.
Note
Outbound Preview calls are an exception to this rule. You can have a workflow run while the agent previews the call as well as when the agent accepts the call.
- After a workflow for a particular trigger type (for example, Call Arrives) executes, it never triggers again for the same dialog ID.
The workflow engine caches workflows for an agent when the agent signs in. Workflows do not change for the agent until the agent signs out and signs in again or refreshes the browser.
Note |
Workflows that trigger when a call arrives, when a call is answered, or when making a call run whenever the browser is refreshed. When an agent refreshes the browser, the workflow engine sees the call as newly arrived or newly made. If an HTTP request action is part of the workflow, the HTTP request is sent when the agent refreshes the browser. Applications that receive the HTTP requests must account for this scenario. Otherwise, undesired results may occur. |
An example of a workflow is a Call Arrival event that triggers an action that collects information from the dialog event (for example, the ANI or customer information) and displays a web page containing customer information.
You can filter trigger events by the value of the data that comes in the event. You can configure a workflow to execute if any conditions are met or if all conditions are met.
Individual conditions consist of the following:
-
A piece of event data to be examined, for example, DNIS or call variables.
-
A comparison between the event data and entered values (for example, contains, is equal to, is not equal to, begins with, ends with, is empty, is not empty, and is in list)
When the trigger and its conditions are satisfied, a list of actions assigned to the workflow are executed. The actions execute in the order in which they are listed.
Workflows run only for agents and supervisors who are Finesse users. The Workflow Engine is a JavaScript library that runs client-side on a per-user basis within the Finesse desktop application. The desktop retrieves the workflows to execute for a user from the server when the user signs in or refreshes the browser.
Note |
Changes made to a workflow or its actions while a user is signed in are not automatically pushed to that user. |
It is possible to set workflows, conditions, and actions that are contradictory so that a workflow or action cannot function. Workflows are not validated.
If multiple workflows are configured for a team, the Workflow Engine evaluates them in the configured order. The Workflow Engine ignores workflows with no actions. When the Workflow Engine finds a workflow with a matching trigger for the event and the workflow conditions evaluate to true, then that workflow is the one used and subsequent workflows in the list are not evaluated. Workflows with no conditions evaluate to true if the event matches the workflow trigger. All workflows are enabled by default. Only one workflow for a specific user can run at a time.
The Workflow Engine retrieves dialog-based variables used in workflow conditions from the dialog that triggered the workflow. If a variable is not found in the dialog, then its value is assumed to be empty.
The Workflow Engine executes the actions associated with the matched workflow in the order in which they are listed. The Workflow Engine executes actions in a workflow even if the previously executed action fails. Failed actions are logged.
The Finesse server controls which calls are displayed to the Finesse user. If the user has multiple calls, the workflow applies only to the first call that matches a trigger. If the first call displayed does not match any triggers but the second call does match a trigger, the Workflow Engine evaluates and processes the triggers for the second call.
A call is considered to be the first displayed call if it is the only call on the Finesse desktop when it appears. If two calls on a phone are merged (as they are in a conference call), then the first displayed call flag value of the surviving call is used.
If the user has a call when the user refreshes the browser, the Workflow Engine evaluates the call as it is. If the dialog data (call variable values) change, the data may not match the trigger and conditions of the original workflow. The data may match a different workflow or no workflows at all.
If the user has multiple calls when the user refreshes the browser, the Workflow Engine treats the first dialog received from the Finesse server as the first displayed call. This call is not necessarily the same call that was the first displayed call before the browser refresh. Dialogs received for any other call are ignored because they are not considered first displayed calls. If dialogs for more than one call are received before the Workflow Engine is loaded after the browser refresh, no dialogs are evaluated because none are considered first displayed calls.
Workflows run for both Finesse agents and supervisors. The team to which the supervisor belongs (as distinguished from the team that the supervisor manages) determines which workflows run for the supervisor. You may want to put the supervisors in their own team to keep agent workflows from being run for them.
Workflow Triggers and Outbound Calls
Note |
When you create a workflow specifically for Outbound Option calls, add a condition of BAStatus is not empty (except for the Workflow Trigger 'When a call arrives' as BAStatus will be empty at that point of time). This condition ensures that the workflow can distinguish Outbound Option calls from agent-initiated outbound calls. |
The following table illustrates when workflows trigger in outbound call scenarios.
Workflow Trigger |
Direct Preview Outbound Call |
Preview Outbound Call |
Progressive/Predictive Outbound Call |
---|---|---|---|
While previewing a call |
When the agent previews the call (before accepting or rejecting it) |
When the agent previews the call (before accepting or rejecting it) |
Does not trigger |
When a call arrives |
Does not trigger |
When the agent accepts the call |
When the call arrives on the agent desktop |
When a call is answered |
When the customer answers the call and during failover |
When the customer answers the call and during failover |
When the customer answers the call |
When a call is made |
When the customer call is initiated |
When the customer call is initiated |
When the customer call is initiated, and during failover |
When a call ends |
When the customer call ends |
When the customer call ends |
When the customer call ends |