Configuring workflow processes

In FootPrints, a workflow process specifies how a record should be processed throughout its lifecycle. Workflow processes are comprised of states, transitions, and business rules. States and transitions can be customized by associating rules and roles to them. Workflow actions that can be managed by business rules include assignment and reassignment, notifications, escalations, and approvals. Workflow processes are configured for almost any type of item (except Contacts and Assets). You can design a workflow on the Workflow Graph page and then configure business rules to power it. 

Workflows can be simple or complex, automating a single action or many. You can create multi-step workflows based on any combination of criteria, including time, field, and process-based. You can also limit access for specific user roles based on status. For example, you could restrict an Open-to-Approval transition to only users with approval permissions.

Basic steps in a workflow are identified by the cells in the workflow graph; each cell represents a single state. Transitions define the progression between states from start to end. For a ticket, this might be a progression from New through Accepted, Open, and In Progress, to Completed and Closed.

To manage approvals, you can designate individual cells as Approval States. You can either designate existing states for the Approve and Reject cells or let the system create new cells for these purposes and insert them into the workflow. In either case, you can configure these states and the associated transitions to manage approval and rejection actions.

For example, you might create a workflow to manage incidents so that when a ticket is created it is automatically assigned to a particular agent or team. The ticket is escalated if the incident has not been resolved within a certain amount of time, and email notifications are automatically sent upon escalation.

The following topics are provided:

The following video (2:57) presentation gives information about Configuring Ticket Workflows.

https://youtu.be/JMWtQaVEqJc

Workflow graph

The workflow graph is a visual representation of a workflow. You can drag and drop icons representing the different states onto the graph, move cells around, draw transition lines to define how a ticket moves from one state to the next, and group states together that should be processed together.

Using workflows across multiple containers

Some customers use multiple containers to manage workflow due to volume or other considerations. You can move or copy tickets between workspaces by defining workflow processes to automate these actions.

Example

You might store and manage incoming customer requests in one container and copy the requests into other item types in a different container. Then, the appropriate agents could manage them to completion in that container. At that point, the original request could be closed and the requester notified.

Copying workflows

While you cannot copy workflows to other workspaces, you can copy a workspace and then modify the copy. You can manage workflow across workspaces and other containers using the copy and move functions.

Multiple workflows and sequencing

Workflows are configured at the item level. You can define multiple workflows for each item, such as a ticket, but only one workflow is applied at a time for each field. Multiple workflows may be applied at the same time if they do not affect the same field. The system follows the most suitable workflow that applies to the current state and field. Once the actions for that workflow are completed, the next workflow is followed.

Example

You might create one workflow to track work and another to track financial approval. The first workflow might be based on the Status field and the second workflow might be triggered by another field related to financial approval. These workflows would be followed in that order.

Workflow examples

The following is a basic Incident workflow process with rules for notifying the contact when the incident’s status changes.

State

Next state

Start

  • If incoming incident meets criteria, In Progress
  • All other incidents, Request

Request

In Progress

(Email is sent to contact on transition.)

In Progress

  • If waiting on internal dependencies, On Hold
  • If waiting on customer response, Waiting for Customer
    (Email is sent to contact on transition.)
  • Otherwise, Completed
    (Email is sent to contact on transition.)

On Hold

In Progress

Waiting for Customer

In Progress

Completed

Closed

Closed

End

The following is a basic Change Management workflow process. Rules can be defined for the states and transitions between them to automate the process so it better matches your business environment.

State

Next state

Start

Manager Review

Manager Review

If accepted, CAB Review

If rejected, Rejected

CAB Review

If accepted, Authorized

If rejected, Rejected

Rejected

Closed

Authorized

Assigned Out

Assigned Out

Built

Built

Testing

Testing

If successful, Scheduled

If unsuccessful, Failed

Scheduled

Implemented

Failed

Assigned Out and Back-Out

Back-Out

Closed

Under Review

If successful, Closed

If unsuccessful, Unsuccessful

Unsuccessful

Assigned Out and Back-Out

Closed

End

Next steps

Workflow prerequisites

Creating workflow processes

Adding and arranging workflow cells

Creating workflow states

Creating approval processes

Configuring defining criteria for a workflow

Related topics

Editing workflow processes

Deleting workflow processes

Getting started quickly for administrators

Was this page helpful? Yes No Submitting... Thank you

Comments