Workflow Rules - Workflow Status Role-based Actions
B
Baiano Simelane
I have been using Zoho Projects blueprint feature which enforces workflow maintenance in specific sequence, where, if Blueprint is defined and enabled, the user doesn't change status manually using dropdown list from one status to the other, but they change the status by progressing the record using suitable buttons e.g. transitioning a status from [Open] to [Under Review] status, the user must click (Send for Review) button, etc. So, I was wondering if the same or a similar feature is available in SmartSuite.
The use case for this feature is for Quality Management System (QMS) in Pharma, which would work almost the same as CRM as it has record in Open, Review, Approval / Rejection status:
USE CASE - SIMPLIFIED EXAMPLE of CHANGE REQUEST:
Note the Nomenclature: [Status], (Button)
Overview:
Change Request (CR) record is the parent. Task record is a child/sub-item of the CR. Meaning, one CR can have many Tasks. A Task has to belong to a CR (parent), it cannot stand by itself. In order for the CR to be transitioned to the [Closed] terminal status, all Tasks must also be either in [Closed] or [Cancelled] status. If any of the Task has [In Progress] or any other status other than [Closed] or [Cancelled], the CR cannot be closed.
Here is the workflow example:
STEP 1a
[Open] > (Submit) > [In Review] - the user fills certain mandatory fields in the CR record <mandatory fields: Assigned, Reviewer, Approver, Description of the change, etc> and save the record.
The record acquires [Open] status after saving. The user <CR creator / Assigned> clicks (Submit) button, and the record's new status becomes [In Review].
The Reviewer person gets an alert about record pending his review.
STEP 1b
[Open] > (Cancel) > [Cancelled]
When the record is in [Open] status as above, the creator/Assigned person can opt to cancel the record by clicking (Cancel) button. The user is prompted for a mandatory justification windows to justify cancelling the record, followed by mandatory credentials (username/password - which acts as an Electronic Signature) to commit the cancellation, and the record acquires [Cancelled] status, and locked for all type of editing (all fields greyed-out) //NO DELETION OF RECORD IS ALLOWED IN PHARMA QMS SYSTEM - hence the [Cancelled] workflow status//
STEP 2a) [In Review] > (Reviewed) > [Implementation]
The person in Reviewer field reviews the details of the change, edit if necessary and save the record, followed by him clicking the (Reviewed) button. The record then acquires [Implementation] status.
STEP 2b) [In Review] > (Reject) > [Cancelled]
The Reviewer person can opt to reject the the change for whatever reason by clicking (Reject) button. He is then prompted for Reject Reason and entering his/her credentials to commit the rejection - and the record acquires [Cancelled]. All fields remain locked / greyed-out.
Etc, etc.
The Reviewer person has to belong to the Reviewer Group - and only a person in that group will have the buttons (Reviewed) or(Reject) available to them for actioning from [In Review] workflow status. The Assigned / CR creator cannot have access to such command buttons - aka Role Segregation. The same applies to Approver user.
If the user attempts to transition CR to [Closed] terminal state while there are pending tasks, the Validation Rule windows prompts the user to first all the Tasks before closing the CR.
Certain fields can be set to be greyed-out at certain Workflow status - for example, if the CR status is in [Implementation], no changes should be made in the Description and other fields as it may obscure what triggered the change in the first place.
Can this Workflow functionality be achieved in SmartSuite?
Jon Darbyshire
Hey Baiano Simelane, thanks for your feedback! I have a few more questions for you:
- Can you provide more details about the roles and permissions of different users in the workflow?
- Are there any specific fields that should be editable or locked at each stage of the workflow?
- Are there any specific notifications or alerts that should be triggered at each stage of the workflow?
B
Baiano Simelane
Hi Jon
Thanks for your reply.
1A. SMARTSUITE PERMISSION:
The SmartSuite 'General Access' permission should be sufficient because the user, whether he's Assigned, Reviewer or Approver, they need to be able to edit the content of the record, depending on where the record is in the workflow.
1B. ROLES:
The general rule when it comes to Pharmaceutical Manufacturing Industry and "FDA 21CFR Part 11" system design is that, the system shall enforce Segregation of Roles. Meaning, the CR initiator / Assigned person shall not be able to act as a Reviewer nor as an Approver. These three fields shall have different users.
In the example of Change Request, the Requestor / Assigned person will complete fields such as 'Title, Justification for Change, Current State, Proposed State, Impacted Department, Change Type, etc' - which are fields that helps the Reviewer and Approver to decide whether the change proposal is valid or not. The record moves to [In Review] status from [Open] status via (Send for Review) button.
At [In Review] status, the Assigned / initiator shall not be able to edit the record because he has passed the record to the next person, which is to the Reviewer. (#)
The Reviewer will open, edit the record, if necessary, followed by saving and progress it to the Approver user (normal QA User). The QA Approver can amend, edit or rephrase some fields - this is ok because the QA Approver user is high up in the hierarchy (he is the entire business compliance custodian) At [Pending QA Approval] status, both Assigned and Reviewer shall not be able to edit the record because now it is with Approver person (#)
(#) - In all the Workflow status except in [Closed] status, the Assigned, Reviewer and Approver field shall be editable to allow the record to be re-assigned to someone else for Assigned, Review and Approval - in case the person is off-sick or has left the company. This is not a problem because all these re-assigning shall be captured in the Audit Log for Data Integrity regulatory compliance purposes (to attribute all actions to individual users).
- EDITABLE AND LOCKED FIELDS:
Yes, there should be fields that are locked and editable at each Workflow status depending of user preference. Generally, when the record is created and saved and is at [Open] or [Draft] status, there's normally no locked fields as the initiator can fill as much details as possible. However, once the record is progressed to the next Workflow status, the Workflow Rules kicks in.
In one of the systems I worked with, this was achieved by, when configuring the Start Status to End Status to choose which field should be required from the user before transitioning (i.e. Mandatory Fields at Workflow Status) and which fields should be editable in the next Workflow Status, together with which User Role Group (e.g. Approvers or Reviewers role group) should be able to do such editing. So, it would be advisable to allow the user flexibility to choose which fields to be locked or editable as they design their solution.
3) NOTIFICATIONS:
Notifications shall be sent to the next person in the workflow during record transition. In this positive Workflow direction: [Open] > [In Review] > [Pending QA Approval], etc, the Assign person progresses the record to the Reviewer, the Reviewer shall receive a notification, and the same that apply to when the record is progressed to the Approver.
Also, in the negative workflow direction in cases, where the Approver rejects or is requesting more information e.g. transition from [Pending QA Approval] to [In Review] via (More Info Required) button, the Reviewer shall receive a notification with the note made by the Approver detailing the info that is required.