Working with Workflows

Introduction

Tickets can be configured to implement a workflow, which is an orchestrated, repeatable pattern of activities that walks a ticket through initial creation to completion. This article describes the workflow process and technicians responsibility when they are assigned a workflow activity.

Estimated Time to Complete

Reviewing this guide will take no more than 15 minutes.

Vocabulary

Term Definition
Approval Step The Approval Step allows a workflow to notify one or more approvers and wait for them to decide how the workflow should proceed.
Branch Step The Branch step allows workflows with multiple paths.
Choice Step The Choice step allows a workflow to present a user or group with multiple choices in order to determine the path for the following steps.
Collector Step The Collector Step joins several paths of a workflow and waits for ALL of the paths preceding it to complete.
Condition Step The Condition Step allows a workflow to automatically route one way or another based on the values on the ticket.
Notification Step The Notification step allows a workflow to automatically notify one or more recipients.
Task Step The Task Step adds a Ticket Task to the ticket.
Timer Step The Timer Step causes the workflow to wait until a specified time passes.
Web Service Step The Web Service Step allows call to an external RESTful web service.

Special Concepts

In TeamDynamix, a set of tasks can be added to a ticket using two techniques:

  1. Task Template is a list of standardized tasks that help technicians complete a service request.
    1. Activities can be sequential with dependencies between tasks.
    2. Activities can be unrelated and accomplished concurrently
  2. Workflows are an orchestrated set of activities that help clients, technicians, and management fullfill a service request.
    1. Workflows activities can take different activity paths based on ticket attributes.
    2. Workflows allow for approvals, automatic notifications, tasks, and web API method calls.
Guidance: For work that does NOT require approvals or "decisions", use a Task Template. For work that requires approvals, decisions, or web methods use a workflow

Workflow Panel

Tickets that have a workflow assigned will have at least one additional panel on the right of the ticket. The first panel, which everyone that has access to the ticket will see, is the workflow panel that specifies the name of the workflow. This panels have the following informational sections:

  1. History, which gives a list of the workflow steps with the current step highlighted in blue (and a rectangle in the steps column). Note, there may be multiple "current steps" if there are activities being done in parallel.
    1. Current Activities shows the list of current steps that have not been completed.
  2. View Progress, which provides a graphical view of the flow activities: (Note: if there are parallel steps there may be multiple steps highlighted)
    1. Steps in "light blue" have been completed, with the action taken also highlighted in "light blue".
    2. Steps in "dark blue" are current steps that have not been completed.
    3. The final, complete state is either
      1. Approved, which means the ticket is "closed", with the work being successfully completed.
      2. Reject, which means the ticket is "cancelled", with the work NOT being completed.
  3. Current Activities panel, shows the list of tasks and approvals that are pending.
    1. "Future" activities that depend on a "current" activity will not be displayed until the current, dependent activity is completed (you can see a list of all activities by viewing the History or the Progress).
Workflow Panel History
Workflow panel example showcasing the workflow name and activities list Workflow table showcasing the steps to each action
Workflow Progress
Workflow path progress visual

Workflow Actions

  1. Approval steps have "Approve" and "Reject" operations, and each approval step will have a title, a description of the activity, and the approval authority (which may be a person or a group).
    1. Responsible persons for approvals do not have to have a Technician license, Clients can be assigned tasks.
    1. Subsequent workflow activities will not be initiated until the responsible person/group selects either approve or reject and selecting either approve or reject trigger the next step in the work.
    2. Selecting:
      1. Approve means that you consent to the activity and acts as your "signature" of approval for that activity only.
      2. Reject means that you do not approve the current step.
      3. While not shown, there are two additional approval actions that you may see (not used often):
        1. Approve Item allows the current approver(s) to approve the ticket as a whole and by-passes all other workflows steps and completes the ticket.
        2. Reject Item permits any current approvers to reject the ticket as a whole, which bypasses any other workflow steps and causes the ticket to be rejected.
      4. While not required, it is recommend that the person completing the approvals provide value added comments.
  2. Task steps, are work activities assigned to a group or a person. Once the responsible person completes the task, they will Mark Complete.
    1. People responsible for tasks must have (at least) a Technicians licences.
    2. Clients cannot be assigned task
    3. While not required, it is recommend that the person completing the task provide value added comments.

Notifications

  1. Notifications for both approvals and tasks are sent to the responsible person(s) during the execution of the workflow.
    1. Approval notifications allow the responsible person to approve/reject the ticket without opening the ticket, but the approver will have to sign in.
      1. Clients can only approve a step using this method.
      2. Technicians can approve the step by opening the ticket.
    2. Task notifications are sent to the responsible person/group.
      1. Technicians can only update the Task from within the ticket
Approval Notification Task Notification
Approval notification with highlighted link to approve or reject the step Task Notification message with ticket number and service status links highlighted

Adding/Removing Workflows

The typical mechanism for assigning workflows is when a service is assigned a workflow, either with an automation rule or as part of the service setting. However, if a Technician has the correct permissions, they can remove a workflow or restart a workflow:

  1. To remove a workflow open the ticket and select Actions|Remove Workflow.
    1. This removes the workflow and any history associated with the workflow
    2. No workflow will be attached to the ticket.
  2. To restart a workflow open the ticket select Actions|Reassign Workflow
    1. This removes any history a previously assigned workflow
    2. Re-starts the workflow from the beginning.
Removing/Restarting Workflows
Reassign and remove workflow options from Actions menu

Conclusion

Ticket workflows are powerful tools that help service resolution in an orchestrated, repeated processes that provide consistent and measurable activities.  Whenever, you have a set of repeatable tasks, that require approvals and “decision making”, workflows are a viable option.

Details

Article ID: 98017
Created
Mon 2/10/20 3:48 PM
Modified
Fri 9/8/23 10:54 AM

Related Services / Offerings (1)

Use this service for technical assistance with EMU building systems. This includes support for building maintenance and monitoring systems as well as access and specialty systems