Marcin Nowak (Radrly) Atlassian Partner

To answer your question: in the audits I've seen, the approval comes first, and the very next question is "who could have changed this?". That's exactly where your "not verified" label points. Two things that make that label easier to defend: Capture who can edit those work items and pages for the period the pack covers.…

Great to see the impact analysis step before Apply. That's exactly the part admins usually do by hand, opening every board, filter and dashboard one by one. Two habits that pair well with the agent, especially once the request flow is on and space admins start asking for fields: Check your field limits before creating new…

Thanks Victor, that's a useful angle. A period work item with a Closed transition limited to the finance role is a good native way to record who approved Day 4 and when. One thing to keep in mind: the approval covers the work item, while the hours sit in worklogs that can still be edited afterwards, so whichever tool you…

Thanks, Anna. Agreed, revenue at risk and delivery cost are two halves of the same question, and it's good to hear Mria's Rovo answers respect the same user roles. I like the complementary angle: the deal and renewal view from the CRM, the worklog cost and margin view from MarginRadar, both read in the same Jira site. If…

Nice write-up, Prabhu. Keying on the numeric project id is the detail people usually learn the hard way, right after the first group move. One thing I'd add from the security side. When a scan flags a repo like payments-api, the ticket that lands in the service desk often carries the finding itself: a pasted token, a…

Thanks Druvis, and good catch on the app account. We see exactly that with Tempo Cloud: the worklogs synced to Jira are recorded under Tempo's app account, not the person's. So work item and space totals are right, but any per-person figure built on Jira's worklogs comes up short for those hours. For anyone checking this…

Very useful checklist, especially step 3. Writing down how each saved report is actually used is the step that saves the most time later. Two more things I'd add to step 6 when you compare old and new for a closed month: Rates, not just hours. If the old report also turned hours into money, check which rate it applied to a…

Nice ritual, Tiffany. One prompt tweak I'd suggest for the "Time & Energy Patterns" part: point Rovo at your Jira worklogs, not only at activity. Ticket updates, edits and Slack threads show what you touched, but not how long it took. A five minute status change and a two day investigation look the same in an activity…

Great write-up, Anna. Use case 3 is the one I'd pick too. The gap between "the deal looks fine" and "delivery is quietly struggling" is where most bad surprises come from. To answer your question, the first task I'd delegate is the money side of that same picture. Before an account call I want to know whether the work we…

Quick update, Caner: both roadmap items from my comment above are now live in MarginRadar. Tempo: hours that Tempo Timesheets syncs to Jira worklogs are counted in every edition. Tempo stores them under its own app account, so they're priced at the space default rate, or an admin can choose to count the hours with no cost.…

Thanks Nicolás, this matches what we saw. Point 4 is the one people get wrong most often. Two things we'd add from audit prep: Freeze the data, not only the document. A content fingerprint tells you two copies differ, but if someone edits a worklog or a group membership after the report was issued, a regenerated report…

Great write-up, and the "act at the moment of change" point is the right one. In my experience the scan itself is rarely the hard part; the hard part is the window between a paste and someone noticing, so tying detection to page and comment events plus a notification to space admins closes most of it. I also like that you…

Thanks for a fair comparison, Caner, and for the disclosure. Same from me: I'm Marcin, founder of Radrly, and we make MarginRadar, so weigh this accordingly. For anyone comparing, here is how MarginRadar fills your rows, based on its public docs: Rates with effective dates: yes, cost and billable rates by role, person or…

Thanks Sarah, a useful summary. The snapshot point matters most for access questions, because the audit log records the change, while a snapshot shows the state a reviewer actually looked at.

Thanks Nicolás, that's a good way to close it. Linked removal work items make sampling quick, and the same filter becomes the starting point for next quarter's review.

Hola Sergio, coincido con Arkadiusz en que la clave no debería viajar en el ticket. Lo más limpio suele ser un enlace de un solo uso desde un gestor de contraseñas o una herramienta de secretos que caduca, y en el ticket solo una nota de que se envió. Así nada queda en comentarios, notificaciones por email ni historial.…

Good points above. One gap I'd add: whatever validation you put on the portal, the email channel skips it. Requests created by email arrive without form validation, and that is where people paste the most. So the realistic setup is prevention where you can (form validation, field design, training) plus fast detection for…

Great list from Evgenii. One gap worth planning for before you start finding things: deleting the value is only half the job. A secret edited out of a Jira description still sits in the field history, and a Confluence page keeps it in older versions until you remove those from page history. The order that works is rotate…

Hi James, one thing to add for duplicates that still hold data: pick the surviving field first and move the values before you trash the other one. Add a temporary context for the affected spaces so the values show on work items again, copy them over with an Automation rule, confirm with JQL, and only then remove the…

Hi Volker, nice progress getting to 740. On the API-only worry, one native check that helped me: for each candidate, open a few recent work items that hold a value and look at the History tab. If the latest writes come from an integration or bot account, that field has a consumer outside Jira and goes on the keep list.…

Adding one practical habit to the great answers here: stage the removal. Take the field off screens first, wait a full reporting cycle, then move it to trash. Trashed custom fields can be restored for 60 days, which gives the export and API consumers you can't see time to speak up. Also keep in mind that private filters…

One thing that helped me once the banner showed up: each permission row is its own budget of 50, so the useful question is which rows are close. Open the permission scheme and start with rows that have direct user grants, since those usually inflate the count. Swapping individual users for a group or space role, and…

Hi Endri, Arkadiusz's Site optimizer tip covers screens, contexts and last used. Two items from your list it won't close are automation and private filters. For automation, export your rules as JSON from Automation settings and search the file for the field's customfield_ ID as well as its name, since rules and smart…

Thanks Nicolás, that's a good habit. Linked removal items also make the review easy to sample: an auditor can pick a few at random and confirm the access was really gone on the date shown. Useful thread for anyone getting ready for an ISO 27001 audit.

Thanks Nicolás, agreed. That's the part that turns a list into evidence. I'd add one control from the auditor's side: freeze the reviewed list at sign-off and keep it together with the changes the review caused (who was removed, when, and why). The next quarter's review can then start from that record, and an auditor can…

Hi Nicolás, good guide. The point about putting approvals in a status rather than a comment is the one I see missed most often. One gap worth adding for ISO 27001: two kinds of evidence never show up as work items. Auditors ask for access reviews (Annex A 5.15 and 5.18): who could reach which space, through which group,…

Hi Ari, Germán and SPHIOR covered the two logs well, so one practical point on the "who had access last quarter" question. Group membership changes alone don't answer it, because access in Jira is the join of three layers: permission scheme grants (including grants to groups, application roles or "Any logged in user"),…

Hi James, SPHIOR covered the review evidence well, so I'll take the dormant access part. On the Jira side, the native signal is in Atlassian Administration: the user list shows each person's last active date per product, and Directory > Users > Export users puts it in a CSV you can filter. Keep in mind it's per product, so…

Hi Daniel, one part of your question the replies above haven't covered yet is the internal/external split. The script reads emailAddress from the REST API, and that field is often empty because of each person's profile visibility settings (that's the "No Public Email" fallback in Nikola's script). An org admin can get the…