Hi All, would like to know is there anywhere that I can do the below to correct the above scenario.
I have an automation workflow that match the dept and auto select the approval. while in the midst of domain migration, there are few jira ticket that stuck with the old acc ID where the approval cant approve the ticket.
Appreciate anyone can advise i have used the transition it failed not any reaction.
Community moderators have prevented the ability to post new answers.
I work at Ballon Apps. Adding to Dexter's answer with the concrete steps.
1. Find the stuck tickets. Jira Cloud searches by accountId, not by name or email; you can get the accountId from the user's profile URL (Atlassian has a KB for this: How to get the accountId for Customer Accounts in JSM).
Two queries, worth running both:
project = YOUR-PROJECT-KEY AND status = "For Approval" AND Approvers in ("<old-account-id>")
project = YOUR-PROJECT-KEY AND approvals = pendingBy("<old-account-id>")
The first looks at the field, the second at the approval itself. If they return different counts, that tells you the field and the approval have drifted apart — important for step 3.
(in rather than =: which operators a field accepts depends on the searcher configured for it, and in tends to keep working. If your field name is awkward, use cf[12345] instead.)
⚠️ Approvals = myPending() has known inconsistencies (JSDCLOUD-10409); pendingBy() with an explicit account is more reliable.
2. Bulk edit. Custom fields can be bulk-edited — only Import Id and Read-only text are excluded by type. Two things it usually trips on:
Change Custom Fields requires the field to be global, or all selected issues to be the same issue type (for an issue-type field), or all in the same project (for a project field). After a migration spanning multiple projects, that's often why the field doesn't show up in the list.
Max 1,000 issues per run, and you need Edit work item permission on all selected issues.
Which operations you get (replace, add, remove) vary by field type — check what your screen actually offers before selecting.
3. Test on one ticket first — this is the most important step. Update the field on a single issue and confirm the approval actually becomes approvable. Reason: for Assets-sourced approvers, it's documented that an already-running approval doesn't pick up a field change (JSDSERVER-12730) — the edit succeeds, the field looks right, and the ticket stays stuck. Whether the same applies to a plain User Picker (multiple users) field, I don't know — haven't tested it. If it turns out to be the case, the fix is: reject the approval and transition back to Waiting for approval so the list repopulates.
If you have automation rules that populate this field, turn them off during the bulk edit.
4. On team-managed vs. company-managed: adding transitions is possible in both project types. What's company-managed-only is the richer set of workflow rules — conditions, validators, post-functions, and triggers. If Dexter's option 2 needs one of those, that's the actual limitation — not the transition itself.
Hi @PMO ,
If you are looking to change the approver for a specific ticket, and you have either Product Admin access or Project Admin access (for team-managed projects), you may use one of the following approaches:
1. Manually update, or perform a bulk edit on, the user in the Approvers field (assuming the workflow approval is based on the Approvers field). Once updated, the new approver will be able to approve the ticket.
2. Modify the workflow by adding a new transition from the For Approval status to the Approved status. After publishing the workflow changes, you can manually transition the affected ticket to the Approved status.
Don't forget to update your Approval Automation with correct user.
Hope it helps
Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @PMO
Welcome to the Atlassian community.
What type of Space does this concern? I assume it is a Service space, but is it Team-managed or Company-managed? You can get that information by clicking the ellipses button next to the Space name in the navigation panel on the left. The information will be the last two lines of the pop up that displays.
Do you have any level of admin access? Are you an admin for the Space or an admin for the Jira app?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Community moderators have prevented the ability to post new answers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.