Body
This getting started article will help Application Administrators and TDX global administrators learn about how workflows function within TeamDynamix. This content for workflows lives within the Ticketing application’s workflow section in TDAdmin.
Overview
Ticket workflows are designed to automate the approval and fulfillment process a request must go through.
Features
Where to Find This
To locate Workflows, you will need to access your TDAdmin environment
- TDAdmin > Applications > Ticketing application > Workflows
Where to Start
Understanding How Workflows are Assigned
For a workflow to be assigned to a ticket, the person who made the request must be listed as a customer or user in the TeamDynamix system. This is required, so if a requester is shown as read-only, then it must be updated to a Customer or User record before any workflows can be assigned.
A workflow can be assigned to a ticket automatically if the ticket was created through a service that has a workflow configured. Or, a workflow could be assigned to a ticket manually.
Whenever a workflow is assigned to a ticket, a copy of the workflow is applied. This means that any changes to the workflow configuration DO NOT apply to workflows which are already assigned to tickets.
Automatic Workflow Assignment
A ticket can be automatically assigned to a workflow if it is defined at one of two places within configuration.
- Default the Workflow on a Service in the TDAdmin > Client Portal application > Services.
- Utilizing an Automation Rule to assign a workflow based on the conditional the rule has.
When a request is automatically assigned to a workflow, the classification is always set to Service Request. This only applies when a workflow is assigned during ticket creation.
Manual Workflow Assignment & Other Information
A ticket can be assigned by a Technician or User who has access to the Ticketing application in TDNext to a workflow after the ticket has been created.
For a workflow to be assigned to a ticket, a Requestor must be specified on the ticket and the person assigning the workflow must have access to the ticketing application and either be a reviewer of the ticket or have the Can Edit All Tickets permission. The ticket cannot be converted to a project task while a workflow is active on a Ticket.
If a ticket already has a workflow assigned when another workflow is assigned, any existing workflow on the ticket is removed. This includes if the ticket is already assigned to the same workflow being selected, in which case this action re-starts the workflow. Any incomplete workflow ticket tasks are removed.
During workflow assignment, you’ll see a Convert this Ticket to a Service Request checkbox. If the checkbox is selected, the parent/child relationships and maintenance activities are removed from the ticket because these are not valid for Service Requests.
If the first step of a workflow is configured as the Classification Promotion step, the ticket is never converted to a service request upon workflow assignment (this rule does not apply during ticket creation).
Understanding How Tickets Move Through a Workflow
Though a single workflow step is indicated as the starting step, as the workflow progresses from there, multiple workflow steps can be active in parallel. Steps can branch to many other steps.
Attempting to start a workflow step that is already in process will have no effect: it will stay current but will not restart.
Tickets that are converted to project tasks will have any associated workflow removed. This is owing to the fact that upon conversion, the completion status of the ticket should be always driven by the corresponding project task instead of by the workflow.
Workflow Statuses
Each workflow which is applied to an item has a status. This status is separate from the status of the item itself. The possible statuses of the workflow are:
- In Process
- Approved
- Rejected
As soon as a ticket is assigned to a workflow, the status of the workflow is In Process. Again, this does not affect the status of the ticket itself, but the workflow which is applied to the ticket.
A workflow becomes Approved as soon as it reaches the final Approve step. Similarly, a workflow becomes Rejected as soon as it reaches the final Reject step. This will take place regardless of whether there are other steps still active in a parallel branch.
Additionally, some workflow steps may allow a shortcut to approve or reject the workflow as a whole immediately, without requiring the workflow to move through each step in the workflow.
Whenever a ticket workflow is finished, both the reviewer and the requestor are notified via email of what happened.
Note that not every step requires direct user interaction to move to the next step or even finish the workflow.
Workflow Approval
When the last step of a workflow is completed (or if an Approve Item action is taken), the workflow's status is changed to Approved. In addition, the following actions are taken on the ticket:
- The status of the ticket is changed to the Approval Status setting on the workflow.
- The requestor and reviewer are both notified via email of the approval (if the workflow has an Approval Status configured for the ticket). Reviewing group will not be notified.
Workflow Rejection
When the workflow is rejected (or if a Reject Item action is taken), the workflow's status is changed to Rejected. In addition, the following actions are taken on the ticket:
- The status of the ticket is changed to the Rejection Status setting on the workflow.
- The requestor and reviewer are both notified via email of the rejection (if the workflow has a Rejection Status configured for the ticket).
The workflow system will only try to notify a particular email address one time. For example, if the same person is the ticket reviewer and the ticket requestor, that person will receive one email for workflow rejection. Furthermore, when a person is both the ticket reviewer and requestor and is receiving the workflow rejection notification, they will receive the Reviewer notification only.
Promotion Classification
The classification of "Service Request" was intended to be a temporary classification, and any ticket that started out as a service request would not remain permanently as a service request. The final classification of the ticket is specified on the workflow as the workflow's "Promotion Classification", which can be applied when the workflow as a whole completes or a predetermined step starts or finishes.
The following rules govern promotion:
- A Service Request can be promoted to any other ticket classification.
- Nothing can be promoted to a Service Request.
- A ticket can only be promoted upwards in the hierarchy, using the following ranking:
- Release
- Change
- Problem
- Incident
- Service Request
The name of the classification may differ depending on what has been customized in your ticketing application, but no matter what the name, the fixed System Type is what drives the hierarchy above.
For example, if a workflow is configured so that the Promotion Classification is Change, and an Incident is sent through the workflow, the Incident is promoted to a Change. If, however, a Release is sent through the workflow, its classification is not changed.
If a ticket enters as a Service Request and you would like it to remain as a Service Request upon exit, Promotion Classification is not a required step.
Summarizing Workflow Progress with Stages
Stages are designed to abstract the details of what could be a complicated workflow in order to provide a quick status summary. Stages have the benefit of being visible through the Client Portal so that requestors can easily see where the request is in a workflow. Use stages to communicate to your customers where your requests are; and use steps to manage your internal workflows. The statuses of the stages are automatically handled by the workflow as the ticket moves through the workflow.
Each step MAY be associated with a stage. The status of each stage is one of the following:
- Pending
- In Process
- Complete
When a workflow is started, each stage's status is set to Pending. The stage statuses are changed based on the following rules.
- When a step starts which is associated with a stage, the stage's status is set to In Process.
- When a step is approved or completed, and there are no other in-process steps associated with the stage, the stage's status is set to Complete.
- When a step is rejected and the next step which starts is associated with a different stage, the stage's status is set to Pending.
What these rules mean is that if there are several steps associated with a stage which happen sequentially, that stage appears as In Process until the ticket makes it to a step which is associated with a different stage, at which point the stage is marked complete.
This allows a complicated workflow to be summarized by a short list of stages.
Viewing and Reporting on Workflow Status and History
My Approvals
Technicians can see the steps awaiting their approval (either individually or on behalf of a group) in the My Approvals section of the My Work application.
Client requestors can similarly view the steps awaiting their approval in the My Approvals section of the Services tab in the Client Portal.
Workflow Progress and History
As the ticket moves through the workflow, the current state of the workflow is displayed on the ticket's General tab within the main ticketing application. The current steps awaiting user interaction appear in the Current Activities section on the General tab.
Any actions taken on the workflow are included in the feed of the ticket. If the workflow is removed from the ticket (or if the ticket is assigned to a different workflow), the feed entries will remain, though the detailed workflow status and history information listed above will no longer be accessible.
Report Builder Reporting
High-level workflow information can be retrieved and filtered on for each ticket in Ticket Report Builder Reports under the Workflow section of available columns.
Even though a copy of the workflow configuration is made every time it is applied to an individual ticket, the system stores a reference to the underlying workflow, steps and stages to the new copy of the workflow. This allows for filtering on the associated workflow configuration, current stage, or current step.
It should be noted that this link will be maintained even if the original workflow, step, or stage is reconfigured. For example, if a workflow containing a step named CAB Approval is applied to an item, and the step in the workflow configuration is later renamed to ECAB Approval or even re-assigned on the configuration, filtering on ECAB Approval will still match the CAB Approval step on the ticket because of that original linking.
Scenarios Where Services Fail to Assign a Workflow
It is possible for services to fail to assign a workflow. These scenarios are valid and should be kept in mind in case it ever happens in your organization.
Perhaps the most common scenario is when the form which you've assigned your service to use has a default value supplied for the Service field, which is different than the service being requested, OR it sets a different Workflow than that service is configured to set.
In some other cases, the Requestor is entered as a Read-Only value. If you set your service to be publicly requested, and do not set it to perform Requestor Name Matching (specifically where it will create a People record when the entered email does not match an existing record), it will create a Read-Only Requestor value. This is not tied to a user account, and because of that lack of a requestor, workflows will be prevented from being added by the service or manually by a TDNext user. This is because a workflow can have approval steps which the requestor is responsible for. If a requestor is not recognized by the system, it wouldn't be able to set them as responsible and the workflow would be broken. To prevent that break, we simply do not apply the workflow, regardless of whether the service should apply it or an automation rule.