Automate handling of agent requests

Workflows provide a way to automate the handling of agent requests. You can configure workflows to automatically approve or deny requests or to force manual handling for schedule changes. Workflows are triggered by different types of agent requests (called “events”). You can create separate workflows for every type of event.

Workflows are created from a default rule and rules that you supply. Each workflow has a set of rules, and each rule has a list of conditions. When a rule’s conditions are met, then the action configured for that rule is performed, and subsequent rules are not evaluated. Rules are evaluated in the order in which they appear in the Rules table. If the event does not meet any of the configured rules, then the default rule goes into effect.

By default, workflows are applied globally. However, you can add conditions that keep a rule from being applied globally.

EXAMPLE A rule for automatically approving a mentoring request has a condition that restricts it to a single service queue instead of the whole contact center.

You must have the Administer WFM Workflows permission to access this page. Because workflows are global, the Administer WFM Workflows permission grants you the Enterprise view just for this page.

If you do not already have the Enterprise view assigned, the Administer WFM Workflows permission grants you the Enterprise view for this page only.

Create a workflow

Select the type of request you want to automate from the Event drop down.
(Schedule Edit requests only) Assign users to whom the workflow applies by selecting their names from the Available column and moving them to the Assigned column.
Click Add under the Rules table.
Enter a name for the rule in the Rule Name field.
(Optional) If you do not want the rule to be active immediately, uncheck the Activate box. Otherwise, leave the box checked.
Set the conditions for the rule under the Conditions section. For more information about conditions, see Building rule conditions.
Select the action that happens when all the conditions are met from the Action drop down.
Click Save.

Workflow example

You want to set up a workflow for exception requests. You want there to be two rules: one for approving the request and one for denying the request.

Approve rule

In this example, for an exception request to be automatically approved, the request must meet two conditions: the requester must support the email service queue and must have worked for the company for at least 90 days.

The conditions for the Approve rule look like the following table. Match all of the conditions.

Variable	Operator	Value
Service queue	Equal to	Email
Days since agent company start date	Greater than or equal to	90

Select Approve from the Action drop down for this rule.

Deny rule

For an exception request to be automatically denied, the requester must meet either of two conditions: the agent is not scheduled and eligible for activities, or the agent has been employed by the company for fewer than 90 days.

The conditions for the Deny rule look like the following table. Match any of the conditions.

Variable	Operator	Value
Agent is scheduled and eligible for activities	Equal to	False
Days since agent company start date	Less than	90

Select Deny from the Action drop down for this rule.

Default rule

The Default rule is executed if all other rules are not met. As a result, there are no conditions associated with it. The Default rule is present in every workflow event and is always the last in the Rules table. In this example, the action taken if none of the other rules are met is Manual Handling.

Automatic denial and manual handling

Automatic denial and manual handling occur if the following trigger conditions are met regardless of whether any workflow rules are configured.

Automatic denial

The following conditions trigger the automatic denial of a request.

Request Type	Trigger Conditions
Exception	The agent is not active. The agent is not employed on the dates of the request.
Mentoring	Either agent is not active. Either agent is not employed. The request is for a schedule date in the past or the current date.
Schedule Edit	The agent is not active. The agent is not employed during the dates that were edited.
Schedule Offer	Either agent is not active. Either agent is not employed on the dates of the request. The request is for a schedule date in the past or the current date. The request’s expiration date is in the past or the current date. The request’s desired date is in the past or the current date. The receiving agent already has scheduled activities other than Available/Not Available in the time where the copied scheduled activities will be placed. The offering agent has no scheduled activities on the schedule date.
Schedule Trade	Either agent is not active. Either agent is not employed on the dates of the request. The request is for a schedule date in the past or the current date. The request’s expiration date is in the past or the current date. The request’s desired date is in the past or the current date. The agent has scheduled activities other than Available/Not Available in the time where the copied scheduled activities will be placed if that is not being traded away. The offering agent has no scheduled activities on the schedule date, or the receiving agent has no scheduled activities on the desired date.
Time Off	The agent is not active. The agent is not employed on the dates of the request. The agent does not have an assigned main service queue. The remaining time off allotments for the agent’s main service queue are not enough for the requested time off. The default FTE per day configured in Global Settings is not positive. The agent does not have an FTE profile assigned. The request date is in the past, including if the request date is the current date but the time is in the past. The request has an overlapping date and time range. The request has identical start and end times.

Automatic manual handling

The following conditions trigger the automatic manual handling of a request.

Request Type	Trigger Conditions
Exception	The request would have been approved, but the workflow exception for the exception type in the request is inactive. The request would have been approved, but no workflow exception was specified for the exception type in the request. The request would have been approved, but the agent does not have available work shift periods within the request date/time range.
Mentoring	The request would have been approved, but the workflow exception for the exception type in the request is inactive. The request would have been approved, but no workflow exception was specified for the exception type in the request. The request would have been approved, but there are no periods within the request date/time range where both agents have available work shift periods.
Schedule Edit	The request would have been approved, but the agent does not have available work shift periods on the date of the schedule edit.
Schedule Offer	None
Schedule Trade	None
Time Off	The request would have been approved, but the workflow exception for the specified vacation type is inactive, is no longer associated with the specified vacation type, or no exception associated with the specified vacation type is a workflow exception. The request would have been approved, but the agent does not have available work shift periods within the request date/time range.

Field descriptions

The fields on the Workflows page are described below.

Field	Description
Event	The event whose workflow you want to edit.
Assign Users (Schedule Edit requests only)	The users to whom the Schedule Edit workflow applies. Schedule Edit workflows allow WFM administrators or analysts to prevent supervisors or junior schedulers from editing agent schedules.
Rules table	The Rules table lists all rules configured for the selected event. Use the up and down arrows to reorder the rules within the list. The Default rule is always last in the list and cannot be moved or deleted. You can add, copy, or delete rules using the buttons below the table.
Rule Name	The unique name for the rule. This name is added to a request’s Comment section when the request is processed successfully by the workflow.
Activate this rule	This check box to activates the rule. By default, a rule is activated. It will not be evaluated if this check box is cleared.
Conditions	This section builds the list of conditions for the rule. Conditions can be nested up to five levels deep. Click Add Condition to add another row. Click the x button (x) to delete the current condition row. Click Add Dependent Set to add a subcondition group. For more information about how to build conditions, see Building rule conditions.
Action	The action to take when the conditions in the rule are met. Approve—The request is approved. Deny—The request is denied. Manual Handle—The request must be approved or denied by a supervisor. Wait List—The request is neither approved nor denied, but is in a holding pattern. WFM continues to evaluate the request on a daily basis until a different rule affects the request or the request is handled manually.

Building rule conditions

The Conditions section allows you to build rule conditions that an event must satisfy for a rule to evaluate as true. Conditions are sets of AND statements and OR statements.

NOTE It is possible to build rules and conditions that cannot work or where later rules will never be evaluated. Calabrio ONE does not validate the rules and conditions you build. Carefully review the logic of your rules and conditions to ensure they do what you want them to do.

Every level of a condition set is an AND statement (“match all of the following conditions”) or an OR statement (“match any of the following conditions”). In general, you alternate AND and OR statements when nesting conditions. If the primary statement for the condition set is an AND statement, nesting another AND statement immediately under it makes no difference, although you might want to do that to visually group some condition statements that relate to each other in some way.

Each condition row has three components: the variable, the operator, and the value (a few variables have a fourth component: percentage). The operators and types of values are dependent on the variable you choose. Conditions use these controls:

New Condition—Adds a new condition row at the same level as the current row
X—Deletes the row
Add Dependent Set—Adds a new AND or OR statement
Remove Set—Removes the dependent set from the condition

NOTE The first condition row cannot be deleted. A rule must have at least one condition row.

The following is an example of a condition set. The callout numbers are explained below.

Callout	Description
1	This AND condition group is the overarching condition group. Each condition statement at this level must be met for the rule to be true.
2	This AND condition group defines the time period within which the requested dates occur. The request must be for a period between 7 and 14 days from the current date. The conditions in this AND statement could have been placed at the first level. They are grouped together to provide a visual cue that they are related.
3	This OR condition group defines the agents whose request will be considered. The agent must have been employed at least 1,825 days. The agent must have a rank less than or equal to 10. The condition group in callout four must evaluate as true.
4	This AND condition group is a subcondition of the group in callout three. It defines the agents whose request will be automatically approved. The agent needs to belong to the Senior Team, but Joanne Short and Leonard Quinn are excluded for some administrative reason.

Variables

The following table defines the variables available to use in a condition statement. Not every variable is available for every event.

Variable	Description
Agent	The agent’s ID (the agent name is displayed). If two agents are involved in the request, the request is checked against both agents. If the operator is Equal to, the condition evaluates to true if either agent ID is equal to the value. If the operator is Not equal to, the condition evaluates to true if both agent IDs are not equal to the value.
Agent is scheduled and eligible for activities	Whether the agent has scheduled activities for the dates and time ranges in the request. An agent is considered to have scheduled activities for a date (and time range, if applicable) if the agent is scheduled for anything except Not Available for the date (and within the time range, if applicable). If the agent has only some of the request’s time range scheduled, it is still considered true. If there are two agents involved in the request, the variable is checked against both agents. The variable is true if both agents have schedules for all the dates in the request. For the following specific types of requests, the variable is true if the listed criteria are met. Time Off requests—The agent is scheduled for all the dates or time ranges in the time off choice. Schedule Offer/Schedule Trade requests—Both agents are scheduled for any activities except Available/Not Available. Schedule Offer requests—The check for the requesting agent is for the schedule date. This check is not done for the responding agent. Schedule Trade requests—The check for the requesting agent is for the schedule date, and the check for the responding agent is for the desired date. Mentoring requests—Both agents must have scheduled activities for the same periods in the time range.
Below minimum days per week	The agent’s work shift is below the minimum days per week set by the min/max hours condition.
Below minimum hours per day	The agent’s work shift is below the minimum number of hours per day set by the min/max hours condition.
Below minimum hours per week	The agent’s work shift is below the minimum hours per week set by the min/max hours condition.
Days since agent company start date	The number of days between the agent’s company start date and the request evaluation date. If there are two agents involved in the request, it is checked against both agents. Both agents must evaluate as true for the condition to evaluate as true. Format: number up to five digits (cannot be negative).
Days since agent department start date	The number of days between the agent’s department start date and the request evaluation date. If there are two agents involved in the request, it is checked against both agents. Both agents must evaluate as true for the condition to evaluate as true. Format: number up to five digits (cannot be negative).
Days to earliest request date	The number of days from the current date to the earliest date in the request. The current date is the date when the request is evaluated by the workflow. Format: number up to five digits, positive or negative.
Days to latest request date	The number of days from the current date to the latest date in the request. The current date is the date when the request is evaluated by the workflow. Format: number up to five digits, positive or negative.
Days to request date	The number of days from the current date to the request date. The current date is the date when the request is evaluated by the workflow. Format: number up to five digits, positive or negative.
Exceeds maximum days per week	The agent’s work shift exceeds the maximum days per week set by the min/max hours condition.
Exceeds maximum hours per day	The agent’s work shift exceeds the maximum hours per day set by the min/max hours condition.
Exceeds maximum hours per week	The agent’s work shift exceeds the maximum number of hours per week set by the min/max hours condition.
Exception (Scheduled)	The exception selected is in the agent’s schedule. This criteria applies to both scheduled and assigned exceptions that overlap with the requested time off day or time (if partial day). NOTE A time off workflow using an exception as the criteria won’t work for a cross-midnight workshift and assigned exceptions (no schedule yet). In situations like these, use manual handling.
Exception Type	The exception type selected in the agent request.
Gap between available hours and requested hours	Available hours is based on the Remaining Hours field in the Time Off request. The value can be a decimal. If HRMS integration is not enabled, the number of available hours is calculated at the time the request is processed by the workflow for the vacation year in which the request date falls. If HRMS integration is enabled, the number of available hours is based on the last imported data from the HRMS and is not tied to any vacation year. This value is not adjusted for other time off requests entered since the last HRMS import/export. NOTE If the entire day is specified for the time off date, the time off per day used is equal to the minimum hours per week for the FTE profile associated with the agent divided by five. If the agent does not have an FTE profile assigned, the condition (and workflow rule) is not applicable. Note that if the minimum hours per week in the FTE profile is zero, the time off hours for the entire time off date is also zero. Format: number up to 10 digits with one decimal, positive or negative.
Gap between scheduled agents and forecast agents	The number of scheduled agents minus the number of agents forecast (worst case for all service queues associated with the agents), for all the dates and time ranges in the request. For every service queue associated with the agent via skill mapping and every member service queue of multiskill groups associated with the agent, the workflow checks every five-minute period in the request dates and time range to get the difference between scheduled and forecast agents. If the entire day is checked in the request, all the agent’s available periods on the date are checked. It will not adjust the scheduled agents for shrinkage. If at least the specified percentage of periods meets the condition, the condition evaluates to true. If there are two agents involved in the request, both agents must evaluate to true for the condition to evaluate to true. For Time Off requests, all the dates in the specified choice must evaluate to true. All the agents’ service queues must have a forecast for the dates, and the agents must have scheduled activities for all the dates and time ranges in the request. This variable has two value fields, one that accepts a decimal and one that accepts a percentage. The decimal field contains the gap value. The percentage field contains the percentage of five-minute intervals in the dates and time ranges in the request that must meet the condition. Format: number up to 10 digits with one decimal, positive or negative.
Gap between scheduled agents with shrinkage and forecast agents	The number of scheduled agents minus the number of agents forecast (worst case for all service queues associated with the agents) adjusted for shrinkage for all the dates and time ranges in the request. The shrinkage applied to the forecasted number of agents is computed based on the shrinkage categories and scenarios selected in the forecast request for the service queue. For every service queue associated with the agent via skill mapping and every member service queue of multiskill groups associated with the agent, the workflow checks every five-minute period in the request dates and time range to get the difference between scheduled and forecast agents. If the entire day is checked in the request, all the agent’s available periods on the date are checked. It will not adjust the scheduled agents for shrinkage. If at least the specified percentage of periods meets the condition, the condition evaluates to true. If there are two agents involved in the request, both agents must evaluate to true for the condition to evaluate to true. For Time Off requests, all the dates in the specified choice must evaluate to true. All the agents’ service queues must have a forecast for the dates, and the agents must have scheduled activities for all the dates and time ranges in the request. This variable has two value fields, one that accepts a decimal and one that accepts a percentage. The decimal field contains the gap value. The percentage field contains the percentage of five-minute intervals in the dates and time ranges in the request that must meet the condition. Format: number up to 10 digits with one decimal, positive or negative.
Paid hours per day	The number of paid hours per day for both agents after the schedule trade or schedule offer for the affected days. This condition validates only when it is true for both agents. Format: number up to two digits with one decimal.
Paid hours per week	The number of paid hours per week for both agents after the schedule trade or schedule offer for the affected schedule weeks. NOTE This condition considers only work shifts beginning in the current schedule week. Time belonging to a shift from the previous schedule week does not carry over to the current week. Any time that extends into the current week as part of a shift from the previous week is considered part of the previous schedule week. This condition validates only when it is true for both agents. Format: number up to two digits with one decimal (allowable values: —168 to 168).
Partial day request	Indicates it is a partial day request.
Project	One or more projects selected are in the agent’s schedule. The project overlaps with the requested time off day or time (if partial day).
Rank	The agent rank. If the agent rank is not specified, it is treated as 99999. If there are two agents involved in the request, both agents must evaluate to true for the condition to evaluate to true. Allowable values: 0 to 99999.
Remaining time off allotments	The time off allotments remaining for the agent’s main service queue that is associated to the agent via a skill mapping or multiskill group. The time off allotments are configured in the default time zone. The agent must be associated with a valid FTE profile. If the request is for the entire day: The allotment is taken from the date of the start of midnight of the request date in the agent’s display time zone converted to the default time zone. The time off allotment = (FTE profile weekly hours ÷ 5) ÷ (Default FTE per Day) If the request is for a partial day: The request timespan is the agent’s display time zone is converted to the default time zone. The converted timespan is split at midnight. Each sub timespan is divided by the Default FTE per Day Remaining Time to arrive at the value taken off for each date. If any of these dates do not have time off allotment configured, the condition and workflow rule is ignored.
Same schedule week	Indicates whether both dates are for the same schedule week.
Same service queues	The agents support the same set of service queues. For example, an agent who supports SQ1 and SQ2 via skill mapping is considered to support the same set of service queues as another agent who belongs to a multiskill group that consists of SQ1 and SQ2. If the multiskill group contains more service queues, it does not count as the same. An agent who supports SQ1 via skill mapping is considered to have a different set of service queues than another agent who supports SQ1 and SQ2 via skill mapping. If one agent in the request does not have an associated service queue, the agents are considered to support the same service queues only if the other agent also has no associated service queue.
Same team	The agents have a team in common.
Service Queue	The service queues associated with the agent through a skill mapping or a multiskill group. If there are two agents involved in the request, this condition is checked against both agents. If the operator is Equal to, the condition evaluates to true if either agent has a service queue whose ID is equal to the value. If the operator is Not equal to, the condition evaluates to true if both agents do not have any service queues whose ID is equal to the value. If there are no service queues associated with the agents involved in the request, the condition (and the workflow rule) is considered not applicable and is ignored.
Service queues have forecast	If there is a forecast for all the dates in the request for every service queue associated with the agent via skill mapping and every member service queue of a multiskill group associated with the agent. If there are two agents involved in the request, this condition is checked against all of both agents’ service queues. For a Time Off request, this condition is checked against all dates in the specified choice. If there are no service queues associated with the agents involved in the request, the condition (and the rule) is considered not applicable and is ignored.
Team	The name of the team the agent belongs to. If there are two agents involved in the request, this condition is checked against both agents. If the operator is Equal to, the condition evaluates to true if either agent has a team whose ID is equal to the value. If the operator is Not equal to, the condition evaluates to true if both agents do not have any team whose ID is equal to the value.