Unitlane FAQ

Unitlane builds focused software for Jira and Atlassian administrators. The current products help with two narrow workflows: reviewing Jira group impact before cleanup, and reviewing billable Atlassian access before license cleanup.

Use Group Impact Audit for Jira when the question is where a Jira group is used before delete, rename, or replacement. Use License Guard when the question is why a Jira user still has product access, app access, or billable access before cleanup.

No. Unitlane stays inside Jira admin review workflows: groups, permissions, project access, product access, billable users, inactive users, SCIM boundaries, and cleanup evidence. It does not replace an IdP, SCIM, Atlassian Guard, or an enterprise IGA platform.

No. Group Impact Audit is positioned as a read-only review workflow for finding group references and preserving evidence before a group cleanup decision. Use the product FAQ for the current detailed scope.

No. License Guard is for reviewing product access, billable paths, exception rows, approval, and proof. It is not account deletion, identity provisioning, or a replacement for Atlassian user-management controls.

Narrow scope makes the review easier to trust. A Jira admin can understand what was inspected, what was left out, what decision was made, and what evidence should survive after the admin console state changes.

Start by checking where the exact group appears in permission schemes, project roles, default access paths, and externally managed boundaries. The important part is not just finding a reference, but preserving enough evidence to decide delete, rename, replace, or hold.

Only after you know whether the group is still referenced, whether it is default or externally managed, who owns the affected access, and what proof another reviewer can inspect later.

Manual search can be enough for quick inspection. It becomes weak when cleanup needs exact matching, repeatable review, approval, evidence export, or comparison against a prior baseline.

Jira product access is the Atlassian app-level access that lets a user enter the product. It is separate from Jira project permissions, and it can be granted through groups, default groups, and other access paths.

No. Inactivity is a discovery signal. Billability depends on product access and billing rules. A row can be inactive but still need owner review, exception handling, or route-out before cleanup.

The user may still have access through another group, a default group, direct app access, an externally synced group, or a separate path that was not part of the first removal.

Keep the billable path, owner decision, held-out rows, approval, and cleanup proof tied to the same review cycle. A stale export is useful for discovery, but it is not enough proof by itself.

Use the support page for product support, evaluation questions, trust review follow-up, and vulnerability reports. Include the product name, site context, timestamp, and the exact workflow step when relevant.

Use the Trust Center first. It links to product trust boundaries, support, privacy, terms, DPA, and product-specific security pages.

Use the product-specific FAQ pages when the question is about product behavior. The sitewide FAQ is a routing page; product FAQs answer narrower evaluation questions.