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.
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.
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.
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 |
|
Request | In Progress (Email is sent to contact on transition.) |
In Progress |
|
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
Adding and arranging workflow cells
Configuring defining criteria for a workflow
Comments
Log in or register to comment.