Shreyas@Quietmill Atlassian Partner

Hi Phương, You have found the main risk with this Automation approach. If the rule replaces the Approvers field, it can remove people who were already meant to approve the request. If you continue with Automation, make the field update additive and test it on a request containing several existing approvers. The result…

@Naveen Suneja Rik and ben have the shape covered between them: the approval lives on a workflow status, and the workflow follows the work type — so a dedicated work type with its own workflow is what keeps the approval specific to this one request type. Two catches are worth knowing before you build it, because both make…

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…

@Naveena Tati Ah - a Sprint board changes the answer. That means Jira Software, and native approvals don't exist there at all: they're a JSM feature, and the request to bring them across (JRACLOUD-62053) has been open for years. That's also why the suggestions keep coming back to custom fields - on a Software board,…

Hi @joanna_natial Cristian's branch pattern works, but before you build it: Jira can already do the per-person version of this on its own, with a filter subscription. Save a filter like `resolution = EMPTY AND due <= 3d AND assignee = currentUser()`, share it with the team, then subscribe the group to it (filter details >…

Hi @Naveena Tati The answers above have the structure right: two statuses, each carrying its own approval step. Two things to add from setting these chains up, because both bite late. 1. Set the approvers before the request reaches the approval status, not on entry. The approval step reads the Approvers field at the moment…

One thing nobody's mentioned yet - timing. The approval gets created the second the ticket enters the approval status, using whatever is in the Approvers field at that moment. Post functions run inside the transition, so you're always safe. Automation runs after its trigger - if your rule reacts to the transition itself,…

@Benjamin Zhou You're right - the automation runs after submit, and there's no way on JSM Cloud to throw an error before submission. The portal can't compare two fields at submit time, with or without Forms. Instead, I would add a workflow status, i.e. a stage in the ticket's life (like "To Do → In Progress → Done").…

This one was useful. Done and dusted. Love it!

Hi @Brian Dowling Adding one option to Graham's, because there are really two different fixes depending on what you want: If the goal is removing the question entirely, Graham's toggle is it - Project settings > Access > Customer permissions, turn off sharing with organizations, and the dropdown disappears from the portal…

Hi @Thomas Behlau The reason you have nothing to diagnose with: the automation audit log only records requests the webhook endpoint actually accepted. A request that fails token validation is rejected before any rule runs, so it leaves no trace on the Jira side. Silence in the audit log almost always means the URL is…

Hi @Benjamin Zhou You don't need to change either field - you need one extra hidden field that mirrors the Assets object's user, because the native "Exclude approvers" setting only speaks user-picker. The pattern: 1. Create a new user picker field (call it "Affected person (user)") and keep it off the portal form entirely…

@Wyatt Drummond That error page is hardcoded - there's no way to customise what an approver sees when they click a button on an already-decided approval. The practical fix would be to stop the stale click from happening rather than improving the error after it: add an automation rule with the "Approval completed" trigger…

Hi @László Kíra The root problem is the trigger type: a scheduled rule can only run at fixed intervals (hourly at best), so there's no way for it to fire "15 minutes before" a specific date-time - the rule has no concept of counting down to a field value. What works instead: schedule the rule to run every hour, and make…

Hi @Community Manager, may I please have permission to write articles in App Central? I'm the developer of Approval Nudge - Reminders & Escalation for JSM approvals (https://marketplace.atlassian.com/apps/971596656/approval-nudge-reminders-escalation-for-jsm-approvals) from Quietmill Apps, a Marketplace partner. My…

The reason it only works when you're the approver is the token, not Power Automate. The JSM approvals endpoint records a decision as whoever owns the API token, and Jira will only accept a decision from someone who's actually a pending approver on that request. Your webhook carries your token, so yours are the only clicks…

You've hit a genuine team-managed limitation - the workflow editor there only binds the built-in Approvers field to an approval step, and it won't accept a filtered custom user picker the way company-managed does. Since you're open to automation, this pattern works in team-managed: 1. Keep a controlled dropdown on the…

The lookup is pulling closed tickets because the JQL only filters on the due date. Add a status category exclusion to the Lookup issues query: due <= 3d AND due >= startOfDay() AND statusCategory != Done statusCategory != Done covers every closed/resolved/completed status in one go, regardless of what the statuses are…

(Disclosure: I'm a Marketplace vendor in this space; partial answer below.)You have found a real data-model limitation, not just a template-syntax issue: the approvals API reports every member as an individual approver with an individual decision, and it keeps no link back to the group that put them there. So once one…