About Workflows

Workflows provide a mechanism for applying a sequence of rules on activities. Flexible and easy to use, they allow administrators to define rules to modify business objects, automate the progression of activities through the system, raise alarms and send notifications about the status of activities, etc.

Visually, a workflow is defined as a set of interconnected nodes created with the help of the Workflow Editor. Each node contains definitions of a list of rules that are applied as an activity passes through that node. Each rule consists of a set of conditions along with the set of actions to be performed when the conditions evaluate to true or false.

There are four types of workflows: Alarm, General, Inbound, and Outbound.

Alarm Workflows

Configure alarm workflows to process activities in the system and perform actions such as notifications, reassignments, etc. depending on the specified conditions. Alarm workflows are typically used to provide customer service based on customer value. Alarm workflows act on all activities except for chat activities.

Additional workflows can be configured to work on activities processed by the alarm workflows.

Alarm workflows can be run on:

Users and user groups
Queues

The system comes with a default alarm workflow:

Exception Queue Alarm Workflow: A workflow configured to send notifications when activities are routed to the exception queue because of workflow errors encountered while processing activities. This workflow is active by default and it runs every 12 hours to check if there are any activities with the substatus “Workflow-Error” in the exception queue. If any such activities are found, a notification email with the list of activity IDs is sent. The notification email is sent to the address specified in the “To address: for Notification for services” setting. This is the default configuration of the workflow; however it can be changed to meet the business' needs. Although the workflow can be deleted, it is recommended that it is not deleted and is instead made inactive.

General Workflows

General workflows are meant to be used mainly for handling activities that are not created through a customer interaction channel like email. Most often, these are tasks type activities, or other custom activity types. This workflow acts on activities that are in the Ready for General Workflow status.

Activities from general workflows can be routed to:

Users
Queues
Other general workflows
Other departments

Inbound Workflows for Email Activities

Inbound workflows define rules for all activities coming into the system. Some special inbound workflows also route activities transferred from other departments.

Activities from inbound workflows can be routed to:

Users
Queues
Other inbound workflows
Other departments

Each department comes with three default inbound workflows. New workflows can, of course, be created and configured. The three default workflows are as follow:

Start Workflow - Standard: The first workflow that acts on all new, incoming activities. This workflow is ignored for activities transferred from other departments.

The system provided workflow creates a new case for activities that do not have a case, and for activities which already have cases, it associates the activities with the existing cases. If the existing case is closed, the workflow reopens the case and assigns the activity to the reopened case. Then, the workflow checks if the incoming activities are bounce backs, and routes such activities to the Exception queue. This is the default behavior of the workflow and it can be changed to meet the business' needs; however it cannot be made inactive.

Start Workflow - Transfer: This workflow is responsible for transferring activities from one department to another. Users from other departments can transfer activities only to the departments that have active transfer workflows. The system provides a blank transfer workflow. The workflow can be further configured according to requirements of the business.
Finish Workflow: This workflow applies on activities only if no user-defined inbound workflow has been applied to the activity. For example, if there are three configured aliases in the department and one configured inbound workflow for only one alias, the activities from that alias are handled by the configured inbound workflow. Activities from the other two alias are handled by the finish workflow.

The system provides a blank finish workflow which can be modified to suit the needs of the business. Alternatively, it does not need to be used and can be ignored.

In addition to the pre-packaged workflows, new workflows can be defined in a department. Also, workflows can be chained in such a way that one workflow takes over the processing of activities after another one has finished.

If there are no inbound workflows configured in a department, or if the inbound workflows are marked inactive, all the incoming activities coming to the aliases configured in the system are moved to the exception queue after an hour.

Inbound Workflows for Social Activities

The inbound workflow for social activities processes and routes all the social activities that are created from the Social Console. These activities can be created automatically when the search is run, or manually by the Social Manager analyzing the search results from the Social Inbox in the Social Console.

Social activities from inbound workflows can be routed to:

Users
Queues

Each department comes with a default social workflow. New workflows can, of course, be created and configured.

Default Social Workflow: This workflow applies on activities only if no user-defined social inbound workflow has been applied to the activity. For example, if three searches have been configured in the department and an inbound workflow has been configured for only one search, activities from that search are handled by the configured inbound workflow. Activities from the other two searches are processed by the default social workflow.

Outbound Workflows

An outbound workflow identifies the set of rules that are applied on activities that are generated when email responses are sent out manually in the system. One of the primary use of outbound workflows is to have a control on the quality of outbound email responses.

Outbound workflows are applied on outbound email responses generated by a configured set of users or user groups. In addition to this, outbound workflows can be configured to apply on responses to activities belonging to certain queues. However, outbound workflows are not applicable to emails forwarded and redirected from the system.

When there are multiple outbound workflows configured in a department, and an activity qualifies for all the workflows, then the workflow for a user take precedence over the workflow for a user group, and the workflow for the user group takes precedence over the queue. For example, if there is one workflow for a user group and another workflow for a queue, and the user from the user group defined in the workflow sends out an email, which belongs to the queue defined in the other workflow, then the workflow configured for the user group will act on the activity, and the workflow for the queue will be ignored. Likewise, if there is another workflow configured for the user, and an activity qualifies for all three workflows, then the workflow for the user group and queue will be ignored and the workflow for the user will act on the activity.

Social activities are not processed by outbound workflows.

Outbound Email Review Workflows

To ensure high quality replies to email inquiries, customer service managers may wish to review the content of replies before they are sent out to customers. The outbound email review workflow can be used to set up a supervisory loop that addresses this need. A supervisory loop allows the application to route a reply from an agent to another user – a supervisor - based on pre-determined conditions, before the reply leaves the system. The supervisor can then accept the reply, sending the email to the customer, or reject it, returning it to the original agent for revision. During this process, supervisors can edit replies, modify attachments, and provide feedback to the agent using notes. Activities that are generated as part of the supervisory loop are not included in activity reports.

Some important things to note about outbound email review workflows are:

The end node of an outbound email review workflow must be a queue. No other end nodes are supported.
Multi-level supervision cannot be configured. Once a supervisor approves an email, the email is sent out of the system. If another outbound workflow is configured for the supervisor, the email is processed by all the nodes, but it is not routed to another queue. The email is sent out to the customer.