Understanding Change Request Workflows and Transitions
Dovetail Agent includes support for Change Requests.
Recall that a change request is a task you create in response to a reported software bug, hardware defect, or enhancement request.
As Change Requests are worked, they follow a workflow process. We use Statuses and Transitions to define the process, and define who can move the Change Request through its workflow steps.
Technically, Cases also support a workflow and defined transition. It’s just a very simple one.
We can use Cases as a simple example before moving on to the more robust workflow options with Change Requests.
Case Workflows
Cases have just 2 conditions: Open, and Closed.
A case can move from Open to Closed, and from Closed to Open.
Within each of those conditions, there are also a set of allowable statuses.
For example:
- Open status options may be: Researching, Working, and Waiting.
- Closed status options may be: Closed, Duplicate,and Spam.
When a case is Open, its status can be changed, but it still remains in an Open condition.
We can illustrate the condition/status workflow as a simple state machine diagram
We can see:
- The Close Case action moves the case from Open to Closed.
- The Reopen Case action moves the case from Closed to Open.
- The Change Status action keeps the case Open.
Now that we’ve illustrated a simple workflows using Cases, lets look at the more complex workflows for Change Requests.
Change Request Workflows
Dovetail Agent supports the status/condition transition model for Change Requests, allowing organizations to define the specific workflow, and also enforce who is allowed to make which transitions.
Change Requests have 4 real conditions: Open, Fixed, Closed, and Duplicate/Closed.
We can illustrate the condition/status workflow as a simple state machine diagram
We can see:
- The Fixed action moves the CR from Open to Fixed.
- The Fix Failed action moves the CR from Fixed back to Open.
- The Change Status action keeps the CR in its current condition.
- The Close action moves the CR from Open to Closed, or from Fixed to Closed.
- The Close as Duplicate action moves the CR from Open to Duplicate/Closed.
- The Reopen action moves the CR from Closed or Duplicate/Closed to Open.
For simplicity, the above diagram is really only showing changes between conditions.
In reality, the transitions are between statuses within conditions.
Status
Within each of the conditions, there are also a set of allowable statuses.
Example statuses:
- Open: Unconfirmed, Confirmed, Being Fixed, Deferred, Test Failed
- Fixed: Fixed, Fixed with Code Change, Fixed with Documentation
- Closed: Test Passed, Will Not Fix, User Error
- Duplicate/Closed: Duplicate
When a CR is Open, its status can be changed, but it still remains in an Open condition. For example, a developer may change the CR status from Unconfirmed, then to Confirmed, then to Being Fixed.
Looking at the basic happy path workflow, we have this:
So we go from Unconfirmed –> Confirmed –> Being Fixed –> Fixed –> Test Passed
Pretty simple.
Now, we need to account for every possible path that we want to allow.
All of this means our diagram gets a lot more complex:
I warned you it looks complex! And that’s with less than a dozen total status values.
CR Null
I said earlier that there are 4 real conditions. There is also an additional condition of Null, as seen in the workflow diagrams above. The Null condition is never seen by a normal user. It’s the state that a CR is in before it’s actually created, i.e. before it’s actually saved to the database.
So why do we need this condition?
It allows us to define different transitions for creating a CR versus re-opening a CR or saying that the Fix Failed.
Here’s an example:
When creating a CR, I don’t want to start a new CR in an Open Condition with a status of Test Failed. That doesn’t make sense.
But I do want to be able to go from Fixed back to an Open Condition with a status of Test Failed.
Having the Null condition allows for defining transitions that support this type of workflow.
Privileges
Unlike Case workflows, Change Request workflows allow us to have additional granularity when defining who can make a transition.
For example, perhaps we want to allow our developers to be able to move the CR from Confirmed to Being Fixed and then to Fixed.
But we only want our QA team to be able to move the CR from Fixed to Closed, or from Fixed to Test Failed.
Remember that a set of privileges make up a Privilege Class, and a user belongs to one Privilege Class.
Working CRs within Dovetail Agent
When working Change Requests within the app, the Change Status menu item shows the allowed changes.
Only the allowable changes are enabled.
Which choices are enabled is determined by the current state of the CR, and the privileges of the current user.
Statuses
Status values and managed within Dovetail Admin.
As a system administrator, you can create, edit, and delete statuses and transitions.
You cannot create or edit conditions. These are hard-coded within the system.
Transition Management
Transitions are setup and managed within Dovetail Admin.
In the screenshot above, that transition is saying the CR can move from Fixed to Test Failed, and only QA Engineers and QA Managers can perform this transition.
Workflow Process Bloat
It’s really easy to get carried away with defining your workflows, and before you know it, you have dozens of statuses, dozens of privilege classes, and hundreds of transitions.
This can make your sys admin duties much more complex and time-consuming than you probably want.
Refer back to the earlier diagram showing the Change Request Workflow including Status, and notice it’s complexity. And that’s with less than a dozen total status values.
So my advice would be to keep it as simple as possible, and really think about the on-going maintenance you’re taking on when adding new workflows. I gave similar advice earlier when discussing business rules.
Wrap-up
So that’s a brief overview of workflows and transitions for Change Requests.
Note that I didn’t cover normal workflow operations like Dispatch, Accept, Assign, etc. Those function the same way they do for other objects (cases, subcases, etc.), so I chose not to include that here.
Hopefully I’ve successfully illustrated what can be accomplished, and given fair warning about not introducing too much complexity.
And if you still have questions, or need some assistance with your workflows, feel free to reach out. This is an area we have tons of experience in, so we’d love to help.
Rock on.
Dig this?
Sign up to get this information delivered to your inbox.
