Delegate Line Manager Approval

[Amarpreet Sawhney]

Hi All,

In our Jira Service Management portal we have various service request types where we have added a filed called "Manager". The requester provides the name here and the approval goes to that person. 

We want this to automate where the request picks the line manager of the person from AD and send the approval to them. But we also need a way where if the line manager is on leave we should have some way to delegate teh approval to some other person. Can you advise how we can achieve this ?

[Walter Buggenhout]

Hi @Amarpreet Sawhney,

If you want to solve this the easy, native way in JSM, probably the simplest solution might be to replace the manager on leave by the backup person inside the logic you use to fill out the manager in your current logic (I am assuming you use a default value for the manager field or an automation rule, possible combined with assets in the background to assign the proper manager ...

You could also leverage assets to manage the backup manager and e.g. a status field or start / end dates there to give automation more context so it knows to assign either the manager or the backup user to newly created requests requiring approval.

However, you will always need to put some sort of governance in place to manage the absences of people (as well as the duration of the absence). The second solution (using assets) may be somewhat more flexible than manually updating the default values of your request types - depending on how many different ones you have, of course. And there will always be certain limitations - e.g. what happens if both the manager AND the backup person are out ... ?

There are also a couple of marketplace apps out there that may help you manage this type of delegation more comfortably, such as Out of office automation for jira-outlook-google-tempo -> be sure to check if they are able to delegate approvals properly if you decide to explore marketplace options.

Hope this helps!

[Shreyas_Quietmill]

In addition to Walter's comments above — two mechanical bits for the AD half, since that's where this usually stalls, and an honest note on the delegation half.

1. Getting the line manager into the field automatically: Keep an Employee object type in Assets with a Manager attribute and a "Jira user" attribute, and a rule on request creation does the rest: Lookup objects with AQL like objecttype = "Employee" AND "Jira user" = {{reporter.accountId}}, then an Edit action that fills your Manager field from the looked-up Manager attribute. Atlassian's KB walks through the pattern: https://support.atlassian.com/jira/kb/how-to-auto-populate-approvers-from-asset-objects-attributes-using-automation-in-assets/. One caveat worth respecting: write the manager's accountId, not the object key or a label — rules fail quietly otherwise. Assets can pull the Employee data in from Entra ID with its import connectors, so nobody ends up maintaining the org chart by hand.

2. Fill the field before the approval spawns: The approval step reads its source field at the moment the request enters the approval status. So populate the manager in a short triage status first, then transition in. A rule that sets it on the same transition can lose that race and create an approval with nobody in it.

3. The delegation half: Nothing native covers "the approver is away" — that request is https://jira.atlassian.com/browse/JSDCLOUD-7867, open since 2018 and sitting at 249 votes under Future Consideration. So it's Walter's Assets-backup pattern with your own automation on top, or an app.

Disclosure, since it's directly relevant here: I build Approval Nudge (https://marketplace.atlassian.com/apps/971596656/approval-nudge-reminders-escalation-for-jsm-approvals). Its absence cover does exactly this: when a named approver stays pending past a threshold you set, or their account is deactivated, a stand-in you configured is added as an additional approver, and it stands down the moment somebody answers. Nobody's identity or decision transfers, which auditors tend to care about.

Both together get you what you described — the right manager on every request without anyone typing a name, and no request stuck because that manager is on a beach.