How to use timers to keep track of your cards & automate your workflow processes
Contract & Vendor management processes can often be time-sensitive.
As a way to keep cards moving, you can make use of the SLA timer setting to ensure cards are monitored/escalated as needed for each specific workflow phase!
Below you will see some scenarios for using these timers to set expectations/escalate tasks/identify bottlenecks
Setting the SLA Timer
The timer for a workflow phase can only be set by workflow administrators
Head to a workflow & hit "Edit this Phase" against your desired phase
Here you will be able to navigate to the SLA tab
On this tab, you can set the desired SLA timer duration using an integer value and a setting of either Hours or Days, then hit ✅ Save
Once set, any cards on that phase will start counting down from the timer from the point they arrive there!
Using the Timer
Transitions
While editing your desired phase, navigate to the Transitions tab
NB. You will need to change the transitions for the phase to Conditional, if you have not already done so:
On the Transitions tab, hit ➕ADD TRANSITION
After choosing a name (ideally one which indicates what the transition will be used for) you will be taken through to the Transition-builder page
To enable the SLA timer to be used as a transition criterion, you simply need to add it in the Condition list using:
SLA Deadline Expiry + is expired
or
SLA Deadline Expiry + is expired by + [number of days]
Once you have finalised the rest of the transition config (choosing any other Conditions & setting the Transition to Phase value) you can enable this SLA transition by setting the Transition Status to Live
🛠 Standard Transition Use Case: Escalations 🛠
A prime use-case for the above SLA Transitions is in escalating
This can be used on more time-constrained processes (often found in managing contract renewals to ensure termination/renegotiation deadlines are not missed)
To do this, you can configure an escalation phase next to the original, usually with a different phase owner (Like a Dynamic Team Owner or a Workflow Group)
🛠 Standard Transition Use Case: Bypassing Roadblocks 🛠
Another (less common) use is in bypassing phases entirely
This can be used to skip workflow phases where input to the workflow process can be optional
Example: in final stages of a contract negotiation for simpler agreements, where proceeding to eSignature can be the default transition if no draft amendments are submitted by external or internal parties within x days (7 days for example)
As above, to do this, you can add the SLA transition to your pre-existing list of approval/rejection/submission transitions and Gatekeeper will apply this when the expiration criteria is met, as usual.
This means that new agreement requests are not slowed down waiting on every party to provide input when maybe the simplest option is proceeding straight to final signature and amendments are treated as the exception.
If implementing an SLA movement of this sort, it would be prudent to include this as context to users in notifications/description sections - see Setting Deadlines
⚡️ Expert Transition Use Case: Allowing optional re-submission/appeals ⚡️
Deciding what to when a request form is rejected can lead to a lot of "what if's"
Take this simple request & approve scenario:
Step 1: A team member requests a contract for a new service.
Step 2: Their Line Manager is dynamically assigned to approve or reject this request
Step 3: If Approved, the form can be assigned to the company legal/procurement teams to begin getting the agreed contract in place
But what should be done if the Manager hits "Reject"?
The 2 simplest & most -common options for this are:
a) What if the requestor wants a second chance?
-> Send the form back to the requestor
Here a rejection could mean "try again" - maybe if the requestor forgot include some context/documentation necessary for the decision/internal SOPs
b) What if the Manager's decision should be final?
-> Send the card to a "Rejected [Done]" phase and inform the requestor that they will not get this new service.
Here it's the case that this is the end of the line. Whether or not the requestor still wants the service, this particular card will go no further.
Maybe it isn't possible with the line manager's budget....Or maybe the company already pays for a service of this nature which can be expanded to more employees/teams...
Both have merits. But instinctively capturing which options a Manager wants to provide to their requestor (or which option the requestor would want to have) is not always so straightforward.
The best middle ground here is to allow for both with the click of the same "Reject" button!
To allow this, when a form is rejected, send it to a new phase (named something like "REVIEW REJECTION")
Here the phase owner can be set to "Card Creator" and all the same form sections from the initial request can be made "editable" (essentially allowing the requestor to update/amend any of their previous inputs)
The 2 -3 key differences between this new phase and the start phase request for are:
1) There is a notification here stating that their card was rejected (and potentially why if using the {{ approval.reason }} notification content tag)
2) There is an SLA to move this card to an actual done phase is the form is not resubmitted within x days (for example, giving the requestor 3 days to resubmit)
3) If necessary, you could even reveal a new form field at this phase named something like "Why should this request be reconsidered?" mandating the requestor provide a reason the manager should review their approval/rejection decision
This means that the requestor will have the option to resubmit their form (without having to fill out a brand new request from scratch) OR ignore the card and let the system automatically archive it off after the x days SLA timer.
NB. the movement of a workflow card is always captured in the card's History tab. Therefore, regardless of which transitions you configure, you will be able to check which transition was responsible for the progression of a card
Setting Deadlines
In workflow notification emails, you can dynamically pass in the SLA Due Date for a card, informing the recipient when the deadline for their action is using {{ enter_phase.sla_due_date }} in the email template
If this "due date" is actually used for any sort of transition (see above examples), including this in the workflow notification email sets clear deadlines past which a user may miss the opportunity to provide input!
(Even if the due date isn't used for a transition, including it in the email sets clear expectations and can be enough of a stimulus to ensure users respect the urgency of the processes you've configured)
Example Email Template Settings:
Email sent from the above template:
These due dates also appear at the top of workflow forms, so users will see their expected completion date:
Monitoring:
Workflows & My Dashboard
Without using SLAs for any Transition purposes, they can still be used to keep track of any overdue cards
For instance, My Dashboard can be configured to show only the overdue cards
In your My Dashboard view (which shows all workflow cards which you have visibility of in one view), you can hit a toggle from All to SLA, reloading your list to show only the cards whose SLA dates have passed
(This can be viewed most clearly in the List view where an SLA Deadline column is also visible)
Similar to the above, the All/SLA toggle exists on kanban board view
Reporting & Analysis
The Card Age workflow report is a key tool for viewing usage stats and identifying potential bottlenecks
Setting an SLA phase allows a visual comparison of average card ages vs the expected SLA deadline
See below example where the SLA ceiling is shown as a red line running along the graph of a selected "✅ Contract Approval Form ✅" workflow
FAQ 💬
Q: What happens to cards which are already on a phase when the SLA timer is configured?
A: The SLAs will calculate retroactively (after the SLA hourly calculation job runs)
Q: My card is past its SLA but hasn't been highlighted red
A: If this is within an hour of the SLA passing its due date, it may be awaiting the hourly SLA calculations job to apply the red border/highlights
Q: What if a card leaves a phase then moves back? Will the timer keep counting from the previous visit?
A: No! Whenever a card moves phases, the SLA clock is reset. If a card goes back to a phase it has visited previously, the SLA countdown will be for the full duration
Q: Why can I not set an SLA timer for "done" phases?
A: "Done" phases are just that; points in the workflow where no further interaction should be necessary. To need a timer here implies the process isn't actually "Done"