During iterative workflow design and development, by mutiple 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 :
- Locking and Unlocking
- Simple Publishing (+ optionally Controlled Testing)
1) Locking & Unlocking
Flowset implements a well established mechanism for preventing mutiple edits to the same workflow diagram, known as locking. Locking ensures that only one administrator is permitted to edit the same workflow diagram at the same time. If, instead, multiple designer's were allowed to edit the same diagram simultaneously, the last designer to perform their save would accidentally overwrite the others' recently committed changes.
- Before an administrator can make any changes to a workflow diagram, they must obtain a lock.
- A lock can only be obtained if the workflow is currently unlocked
- A lock is automatically removed when the latest draft edits are published or discarded.
- In exceptional circumstances an administrator can remove someone else's lock.
A lock is represented by a colored icon at the left hand end of a workflow definition entry
Hovering over a lock icon shows details about the owner :
The "Lock" Command
The lock command is only available on workflow definitions that do not already have a lock. To lock a workflow definition locate its entry on the "Active" or "Inactive" tab and click the pop up menu at its right hand end 
Select the "Lock" option from the resulting popup menu
A green padlock appears against the selected workflow definition showing that the current user now owns the lock :
Automatic Unlocking
After new draft edits have been saved, the act of publishing or discarding those edits will automatically release the lock on the workflow definition.
In this example, the user has clicked the popup menu for the "Approvals" workflow definition
The user currently owns the lock
There are draft edits to the diagram
& Both the publish and discard commands make it clear that they will also remove the lock
Selecting the "Publish Draft and Unlock" command, presents the usual confirmation dialog ...
... and then selecting "Yes" publishes the draft changes and automatically removes the lock
The workflow definition is no longer locked
There are no draft edits to the diagram immediately after publication
Selecting "Discard Draft and Unlock", would show the same end result except in the background the draft edits would have been discarded rather than published.
The "[Unlock]" Command
Locks can also be removed explicitly using the the "[Unlock]" command on the workflow definition's popup menu. There are two use cases :
- removing one's own lock
- removing a lock owned by another user
Removing One's Own Lock
The current user is always free to remove a lock they already own; for example they may decide they no longer need to edit a workflow diagram and therefore remove the lock for others who may wish to instead.
In the following example the current user owns the lock on "Customer Services - Close Account".
Selecting "[Unlock]" removes the current lock from the workflow definition
Unlocking one's own lock is a fairly harmless operation and proceeds immediately with no confirmation dialog
Removing a lock owned by another user
In exceptional circumstances it may be necessary to remove a lock owned by another user. For example if an urgent update is required to a workflow and the current lock owner is unavailable.
All workflow designers are administrators, and the configuration tool does not enforce which administrators can remove another user's lock. However, as a matter of courtesy, one should not do so without consulting the lock owner first, if this is at all possible.
In the following example the current user does not own the lock on "Complaints Procedure".
This time selecting "[Unlock]" presents a confirmation dialog advising careful thought before proceeding
Selecting "No" aborts the operation.
Selecting "Yes" removes the current lock from the workflow definition
2) Controlled Updates
This section covers the two types of controlled updates 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 > Lock (Automatic) -> Edit -> Change -> Save -> Publish Draft & Unlock
- Lock > Edit > Change > Save > Publish Draft & Unlock
- Lock > Edit > Change > Save > Discard Draft & Unlock
- Lock > Edit > Change > Save > Edit > Change >Save > Publish Draft & Unlock
- Lock > Edit > Change > Save > Edit > Change >Save > Discard Draft & Unlock
or expressed more generally :
- Lock > [ Edit > Change > Save ]1..* > [Publish Draft | Discard Draft] & Unlock
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 availablity to agents.
The approach can be initiated whenever the workflow has a valid draft edit. 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 :
Lock > 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 and 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 & Unlock" 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
The new Test Icon indicates that there has been a Test submitted for evaluation
The Draft Icon indicates changes to the Test Workflow that could be resubmitted or discarded
The Draft Icon on a non test workflow indicates there are changes that can be immediately published
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.
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 lifecyle 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.