Jonas Nilsson | Unitlane Insider

Hi KC, you may not need the REST loop. inactiveUsers() has no section of its own on that page, but it works on custom user fields: cf[10100] in inactiveUsers() finds every work item where that field holds someone who is no longer active. It should catch deleted accounts too, not only deactivated ones. The same page, under…

Hi Joshua, "Never accessed" is a good sign. It means those accounts never opened Jira or JSM, so they almost certainly don't own any filters or dashboards there. A few things I'd still check before deleting 175 at once. The delete closes the whole Atlassian account, not just its Jira access, so open a couple of them and…

Hi Ralf, that's a workable definition, and both of the things blocking you have a way around them. One addition to Fabio's warning: a deleted person's work items and comments stay, but their name turns into "Former user" after the 14 days in which you can still cancel the deletion. So keep your own list of names and…

Hi Lenny, you're right to steer away from request participants here. As Andrea said, a participant gets every customer update from then on, which is the barrage you want to avoid. I'd split it into two jobs in the escalation rule. First use Andrea's lookup to find the manager, then add Send customized email (the…

Hi Priyadarshini, Arek has the pop-up right. Your screenshot says the Jira User role comes from a group that also grants an admin role, so for those people you take them out of that group instead of clearing the role on their profile. Worth a look at who else is in there too, since someone inactive for 90 days rarely needs…

Kevin, the structure you describe is what James Gamble laid out, so it sounds right. Two things I'd check before it goes live, since I can't see your screenshots from here. First, the trigger. You wrote that the emails go out when the SLA goal is triggered. If that means the clock starting, the email arrives at the…

Tomer, I'd start with the setting Igor Medeiros mentioned. In the Scheduled trigger, tick Run a JQL search and execute actions for each issue in the query, otherwise Send email to Assignee has nobody to send to. That is the usual reason a first scheduled rule does nothing. One change to Varun Chillamcharla's JQL: created…

Harry, Sussi Åström's reply is the one I'd test first, because it explains something that can change for everyone at once without anyone touching the rule. If the agent who replies is in the same organization as the reporter, or is a participant on the request, Jira treats them as a customer and the status stays put. Quick…

Glad the automation-added form worked out, Abilash. If you ever want the checklist to be real work rather than a form, sub-tasks are the native way to do it. A rule on request created can use the Create sub-tasks action, one per line (Disable tenant DAGs, Drop tenant schema, Delete S3 buckets and so on), so each step gets…

Building on Habib's automation idea, here's a native way that works without an app: let Automation keep a label on the blocked items, then filter on the label. Rule 1, when a blocker starts: Trigger: Work item transitioned, to In Progress or In Review Branch: Linked work items, link type "blocks" Action: Edit work item…

Posted by mistake, please see my answer below.

Paul, Andrea's checkbox is the right native route, and Monika is right that it turns into an honour system if an agent just ticks it by hand. What I'd do is let the box tick itself from something Jira can actually see: an automation rule that sets the field when an approval comes through, a linked work item reaches Done or…

Lucas, I'd go with Marc's NOT status CHANGED AFTER -14d, plus Gabriela's small cleanup rule that removes the label, so the second waiting period gets its reminder too. One more thing from Atlassian's own follow-up article: a comment counts as an update, so if your reminder is a comment, anything built on "last updated"…

Jeremy, your three follow-ups only got half an answer, so here is how I'd build on Brant's clone idea. The SLA stays on the JSM request because that is the item you never move, and the customer keeps their portal view. Put the rule on the project item: trigger on work item transitioned or commented, add a branch on linked…

Hi Aary, Rilwan and Sarah have the recovery side covered, so here's the next step once you're back in, because that old account still being active is its own small problem. Before you switch it off, move what it owns. Shared filters and dashboards can get a new owner under Settings > System > Filters (and Dashboards).…

Nice rundown from Nikola, Arek and Mihai. One more thing worth knowing: Last seen only means someone opened Jira, not that they did anything in it. Before you keep a seat for someone who looks active, try issuekey in updatedBy("<account ID>", "-90d") in work item search. If nothing comes back, they haven't created or…

Hi Thomas, To add to James's checklist: two Okta settings can cause exactly this with no error anywhere, because the group still looks fine in both places. Group Push deactivated. Okta keeps the group in Atlassian, but membership changes you make in Okta no longer reach it. The group was unlinked with "Leave the group in…

Hi Radia Dev, Tomislav's audit log route is as close to real visit data as it gets, if you have Guard. Your monthly re-login idea could work together with it: with a shorter idle session in the authentication policy, people who only read have to log in again, and that shows up as a "Logged in to account" event. I haven't…

Hi r ghisa, To add to what Fadoua, Trudy and Danno said, a few things worth knowing before you automate the delete: * After the delete the owner shows as "Former user". Shared filters keep working, but a private filter stops working for any board built on it, and only an admin can change its owner from then on. Their…

I would separate the system of action from the system of evidence. For AI tool access, JSM can work well as the front door and review surface, while IAM/IGA remains the enforcement source for provisioning, deprovisioning, and recertification. The part I would be careful not to lose is the evidence handoff between those…

One thing I would separate here is: 1. finding the offboarding tickets, and 2. preserving what those tickets can actually prove later. JQL can help with the first part if your offboarding issues have a consistent project, request type, label, component, or custom field. But for audit evidence, I would also think about what…

@Julia Foden Hi Julia, circling back because your workflow conditions point was exactly the right gap. The app has now been rebuilt into Group Cleanup Radar for Jira. It starts with all groups, then lets you open a group preflight before delete, rename, or replacement. The coverage is broader now: project roles, permission…

Hi @Julia Foden, yes, that’s right. The current scan covers project roles and permission schemes. Workflow conditions are not included in the scan today, and you’re right to call that out. They are a very relevant next layer for group-impact checks, especially when a group is used in transition restrictions. I’m looking at…

If native Jira does not record attachment-download events in the way you need, I would first define the audit requirement before choosing a workaround. Useful questions to write down: - Do you need evidence that a file was downloaded, or only evidence that the attachment existed and was accessible? - Is the requirement for…

I would separate this into three checks, because Jira access can fail at more than one layer: 1. Product access: confirm the user has access to Jira in admin.atlassian.com. 2. Space/project role: confirm the user is actually in the role used by the space/project. 3. Permission scheme: confirm that role has Browse projects…

For this kind of internal/external split I would treat the group rule as an access-governance workflow, not only a one-time user-management task. The practical checklist I would use: - Confirm whether Atlassian Access + SCIM is available for the organization. If yes, group sync from the IdP is usually the cleaner long-term…

Yes, that makes sense. For a one-off review, API inventory plus spreadsheet filtering is a sensible fallback. The gap I keep coming back to is when teams need that step to be repeatable, easier to review, and less dependent on rebuilding the same scan-and-spreadsheet workflow each time.

Thanks for laying that out. That is a very tightly governed model, with single-purpose groups, admin-managed membership, and relatively little room for drift. In a setup like that, I agree the review stays much simpler. The cases I tend to worry about more are the less controlled ones, especially where groups start…

Thanks, that helps. A clean designated-group model like that definitely removes a lot of ambiguity up front. The part I still find interesting is that naming tells you intended use, but not necessarily every actual dependency that may have built up over time, especially once permissions are additive. That is also why the…

This is exactly why service accounts need a different review path from ordinary user cleanup. They may look inactive by human standards, but the real governance questions are ownership, purpose, scope, and whether they are explicitly excluded from automated cleanup logic. That exclusion/proof step is one of the main…