Dovetail Agent 12 – now with Change Requests
The recent release of Dovetail Agent 12 adds support for Change Requests. This post will walk through an overview of Change Request functionality within the app.
What is a Change Request?
From the Clarify documentation:
A change request is a task you create in response to a reported software bug, hardware defect, or enhancement request. It constitutes a complete and formal record of the problem or enhancement request, and what has been done to fix the problem or implement the enhancement.
Overview of Features
- Create and Edit Change Requests
- Workflow: Accept, Assign, Dispatch, Forward, Reject, Yank
- Status Changes: Fix, Fix Failed, Close, Close as Duplicate,Reopen
- Actions: Log Email, Log Notes, Replicate Change Request
- Change Requests are available in My Work, Queries, and Recent Items
- Batch actions are available from My Work and other queries
Naturally, the querying functionality includes support for Change Requests.
Users can create their own queries, share queries, favorite them, and download the result set into CSV or Excel formats.
From a query result set, you can select multiple change requests, and easily perform the same action on all of them – such as logging a note, dispatching, or assigning them.
Change Requests can be easily searched, using keyword searching, property searching, or a combination of both.
Dovetail Agent supports the status/condition transition model, allowing organizations to define the specific workflow, and also enforce who is allowed to make which transitions.
The Change Status menu item shows the allowed changes.
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.
Transitions allow for this type of workflow granularity.
I have an upcoming blog post queued up that discusses transitions in much more detail. Stay tuned.
Integration with Solutions
Solutions provide the link between cases and Change Requests.
How do Change requests, Solutions, and Cases work together?
- Customer reports a problem, which creates a Case.
- The tech support rep confirms that this is indeed a bug, so a new Change Request is created.
- The tech also creates a Solution to share the knowledge to other agents, and to customers through SelfService, that the bug exists. There may or may not be a workaround at this time.
- The Solution is linked to the Case and to the Change Request.
- Many customers may report this same issue, and they would also get linked to the existing solution.
- Once the Change Request is fixed/closed, the solution owner can be notified, and the solution workaround can be updated (for example – problem is fixed in a new version)
- All of the case contacts can also be notified, letting them know that the problem they reported has been fixed.
And that’s your closed loop between Support, Development, and QA.
Solution –> Change Request
On the Solution page, we show Linked Change Requests.
(Notice that we also have a tab that shows the Linked Cases)
From a Solution, users can link to an existing Change Request, or there is a Create Change Request button which will start the creating of a new Change Request.
The Change Request Title and Notes will be automatically populated with information from the Solution
Once the Change Request is created, it will be automatically linked to the Solution.
Change Request –> Solution
On the Change Request page, we show Linked Solutions
From a Change Request, users can link to an existing solution, or there is a Create Solution button which will start the creating of a new solution.
The solution Title and Description will be automatically populated with information from the Change Request.
Once the Solution is created, it will be automatically linked to the Change Request.
From the Clarify docs:
When you replicate a change request, you quickly create a change request that is identical to an existing change request.
For example, if a customer reports a software bug for release A, you create a change request. But you also want to make sure that the change request applies to the next release, release B. You replicate the change request for both release A and release B.
A replicated Change Request will be automatically linked to the original, and this association is shown within the History, and also on the Linked Change Requests tab.
Close as Duplicate
From the Clarify docs:
When you mark a change request as a duplicate, you are grouping change requests that are created in response to a single defect or enhancement request.
For example, a quality assurance engineer receives a change request. The engineer queries the database and discovers that the change request already exists against a known problem. The engineer marks the change request as a duplicate by identifying the master (original) change request and closing the duplicate change request. The engineer only has to fix one change request, but management can track all the change requests about the same the problem.
A duplicate Change Request will be automatically linked to the original, and this association is shown within the History, and also on the Linked Change Requests tab.
Change Requests can be tagged, allowing greater flexibility for organizing your work, as well as for keeping track of Change Requests that you’d like to track.
Log Email and Log Notes allow for markdown, which allows for styling of text, links, tables, inline images, videos, code snippets, etc.
Change Request History showing rendered markdown with headings, lists, images, and videos:
Canned Responses are supported when logging notes and when logging an email to a Change Request.
And of course, canned responses can also contain markdown.
Keyboard Shortcuts allow your users to move quickly throughout the application, and speed up common tasks when working with Change Requests.
The preview pane allow you to quickly view the Change Request History, without navigating away to an individual Change Request page.
Once you navigate to a Change Request page, it’s added to the Recent Items list, making it easy to quickly return to an item you were recently viewing.
Printing Change Requests
We also make sure that a printed Change Request looks nice.
What if I’m not using Change Requests?
If you’re not using Change Requests, they can easily be disabled through out the app by simply setting the ChangeRequest.FeatureEnabled key within the appSettings file to False.
There are still a number of Clarify/Dovetail customers using Change Requests, and we’re excited to be able to bring this functionality into the current Dovetail Agent application.
We think the usability, performance, and features within the latest Dovetail Agent allow for a much more pleasant user experience than both our older Agent versions, as well as Clarify applications.
Hope you dig it as well.