During iterative workflow design and development, by multiple parties, it is important to ensure that:
- Designers do not accidentally interfere with each others edits to the same workflow.
- Saved updates do not take immediate effect, but are instead applied to the runtime in a controlled way.
Flowset contains features to address both of these, respectively :
- Workflow definition locking
- Simple Publishing (+ optionally Controlled Testing)
1) Locking
When a workflow designer edits a workflow definition, it will become locked by the user. This prevents other workflow designers from editing the same workflow definition at the same time and overwriting each others changes. The workflow designer can edit any workflow definition providing
- The workflow definition is already locked by them (green lock icon)
- The workflow definition is not locked by anyone (no lock icon)
The workflow designer will not be able to edit a workflow definition if it is already locked by someone else (red lock icon). If the workflow designer needs to be able to edit a workflow definition currently locked by another user (for example if the other user not available), they can do this by running the 'Assume Control' command (see below).
- A green padlock indicates that the workflow definition is locked by the current user (1).
- A red padlock indicates that the workflow definition is locked by an administrator who is NOT the current user (2) Hovering the mouse over the red padlock icon will show a tooltip giving details of who has locked the workflow definition.
- No padlock indicates that the workflow definition is unlocked (3).
2) Automatic Unlocking
When a workflow designer has edited a workflow definition and saved their changes, a new Draft workflow definition will have been created. When ready, the workflow designer will typically
- Publish the changes from the Draft workflow design
- Discard the changes made in the Draft workflow design
In both cases, the workflow definition will become unlocked and available for others to edit.
3) Release Control
If a workflow designer edits a workflow definition but does not save any changes, the workflow definition will be locked, but there will be no Draft workflow design. In this case, if the workflow designer no longer wishes to edit the workflow definition, they can choose the "Release Control' option which removes the lock and makes the workflow definition available for others to edit.
- The workflow definition is locked by the current user (1)
- There have been no saved changes so there is no draft workflow design (2)
- Choose the "Release Control' option (3) to remove the lock
4) Assume Control
If a workflow definition is locked by another user, but the workflow designer needs to make changes to it, they can choose the 'Assume Control' option. Choosing this option switches the ownership of the lock to the workflow designer and leaves any Draft workflow design in place. The workflow designer can continue to modify the existing Draft and then Discard or Publish it as necessary.
- The workflow definition is locked by another user (1)
- Choose 'Assumer Control' option (2) to switch ownership of the lock to the current workflow designer. This option is available whether or not there is a Draft workflow design.
- The 'Assume Control' confirmation dialog shows details of who currently owns the lock. Click 'Yes' (3) to switch ownership of the lock.
5) Committing Workflow Design Changes
This section covers the two ways of committing workflow definition changes supported by Flowset :
- "Simple Publishing" - a simple 'Edit Draft <-> Publish' lifecycle
- "Controlled Testing" - a more thorough controlled lifecycle for testing draft edits before publication
Simple Publishing
Edits to a workflow diagram are always applied to a draft, never directly to a published workflow
The draft workflow diagram can be edited and saved as many times as you like but agents will not see the changes to the workflow on tickets until it has been published.
Publishing is deliberately designed to be a separate operation so that interim updates/edits to the workflow do not necessarily need to be logically valid or complete before being saved.
If later it is instead decided that the latest edits are not applicable they can also be discarded without ever having affected the published workflow.
Publishing/Discard can be performed on "Active" or "Inactive" workflows
Here are some example states that a designer encounters when using Simple Publishing
- Create > Edit > Change > Save > Publish Draft
- Edit > Change > Save > Publish Draft
- Edit > Change > Save > Discard Draft
- Edit > Change > Save > Edit > Change > Save > Publish Draft
- Edit > Change > Save > Edit > Change > Save > Discard Draft
or expressed more generally :
- [ Edit > Change > Save ]1..* > [Publish Draft | Discard Draft]
See The "Edit" Command for a full description of how to invoke the commands involved in this lifecycle.
Controlled Testing
Controlled testing offers a designer a chance to try out edits to their workflow, before it is actually published for general availability to agents.
The approach can be initiated whenever the workflow has a valid draft design. Rather than publishing the draft directly, it can be placed into a controlled testing cycle. At this point administrators (only) can initiate the workflow on test tickets to prove out any issues.
Test Lifecycle Commands
Several new commands are introduced on the workflow's popup menu to manage a testing lifecycle.
- Start Testing
- Submit Draft for Testing
- Complete Test and Publish
- Edit Test
- Delete Test
- Discard Test Draft
- View Test
The menu only ever includes those commands relevant to the current state of the workflow
Example Command Sequence
A typical sequence of actions for a testing lifecycle might be :
Edit > Change > Save > Start Testing > Submit Draft for Testing > {Test on a ticket} > Complete Test & Publish
Often a number of testing iterations may be needed before the workflow is considered satisfactory. To support this, it is possible to - re-edit the Test diagram and resubmit for testing several times before finally publishing.
..... [ Edit Test > Submit Draft for Testing > {Test on a ticket} ]1..* > Complete Test & Publish
There are many other possible sequences including those where unsatisfactory tests can be deleted, or Test Drafts discarded. It is outside the scope of this article to demonstrate them all. However this state diagram illustrates the possible command paths available :
Note that "Start Testing" initiates the Testing Lifecycle after which the workflow remains within this lifecycle until the user chooses either "Delete Test" or "Complete Test & Publish".
It should also be noted that "Complete Test & Publish" releases the lock on the workflow, in a similar way to "Publish Draft" within the Simple Publishing methodology. Except "Complete Test & Publish" promotes the last submitted Test diagram to be the published workflow, not the draft
The "Test" Workflow state
Simple Publishing has just two workflow states
Draft <--> Published
Controlled testing introduces a third test state
Draft <--> Test <--> Published
A third icon is introduced to represent the Test state for workflow definitions on the management screen
- Workflows within a Test Cycle are displayed in bold (1).
- The new Test Icon indicates that there has been a Test submitted for evaluation (2).
- The Draft Icon indicates changes to the Test Workflow that could be resubmitted or discarded (3).
- The Draft Icon on a non test workflow indicates there are changes that can be immediately published (4).
Evaluating the Test Workflow with the Workflow Assistant
After a draft has been submitted for testing it is time to exercise it on a test ticket using the Workflow Assistant. Note that a "Test" workflow does not need to be active to achieve this (although it can be.)
Only Administrators are allowed to start a Test workflow on a ticket.
- In addition to the existing published workflows, Administrators will see this additional [Testing] workflow (1). Notice, we can see the published and the testing versions of the 'Customer Service - Close Account' workflow.
Although the Administrator may wish to test the entire workflow alone, other agents can be invited to be involved in its evaluation. It is advised therefore that test tickets are isolated from general visibility to agents and an administrator specifically invites them to participate if required.
At the end of a successful evaluation, it is likely that the designer will "Complete Test & Publish" and the testing lifecycle completes
If issues are found then it is time to remain in the testing lifecycle use "Edit Test" again to try to resolve the issues. Followed by "Submit Draft For Test" again
Comments
Please sign in to leave a comment.