Summary
When a user is Out of Office, approvals and tasks are treated differently:
-
Approvals are routed to a Stand‑in – someone with similar authority, so that important business decisions continue to be made at the right level.
-
Tasks are reassigned to a Coverer – a teammate who has sufficient knowledge and access to continue working on the issues, even if they are not in the same role or seniority.
|
Concept |
Field affected |
Used for |
Typical usage |
|---|---|---|---|
|
Coverer |
Assignee
|
Handling and progressing issues |
“Who works on my tickets while I’m away?” |
|
Stand‑in |
Approvers (JSM custom field) |
Handling approval decisions in JSM |
“Who approves my requests while I’m away?” |
Background
The concept of Stand-in is introduced in version 4.4.0 to allow re-routing JSM approval requests to another approver when the original approver is out of office. This will unblock requests from being stuck waiting for approvals.
Why the need to differentiate them?
They exist because approvals are about authority, while tasks are about execution.
1. Stand‑in – same level of authority for approvals
For Jira Service Management approvals, the Stand‑in is typically someone who has the same level of authority as the original approver.
-
Approvals often represent management, budget, risk, or policy decisions.
-
When an approver is Out of Office, the Stand‑in:
-
Takes over approval responsibilities by being added to the Approvers field.
-
Is expected to have equivalent decision‑making power (e.g. same role, same seniority, or formal delegation).
-
-
This ensures:
-
Compliance with internal controls.
-
That no one with insufficient authority is making binding decisions.
-
So you can say:
“When an approver is away, approvals are routed to their Stand‑in – someone with similar authority who is trusted to make the same decisions.”
2. Coverer – teammate with sufficient knowledge to work on tasks
For day‑to‑day work on issues, the Coverer usually just needs sufficient knowledge and project access, not the same level of authority.
-
The Coverer becomes the Assignee for new issues:
-
Handles investigation, implementation, and communication.
-
Progresses the work while the original assignee is away.
-
-
It is completely acceptable (and common) to choose:
-
A peer or teammate as Coverer, even if they’re more junior.
-
As long as they:
-
Understand the domain,
-
Have the necessary Jira/project permissions, and
-
Know when to escalate decisions back to someone with higher authority.
-
-
You can phrase it as:
“Tasks can be reassigned to a teammate (Coverer) who has enough knowledge to work on them, even if they don’t have the same level of authority as the original assignee.”
Another advantage of this design is that it is possible to designate different people as the coverer and the stand-in within a Jira project.