Access Management
For compliance. Access Management shows:
- who can see what, and why;
- how that changed over time;
- regular reviews where the right people confirm or remove access;
- alerts when something unusual happens;
- an audit log you can search, export and prove untouched.
Access Management is a plugin. If you don't see Access Management under Plugins in the sidebar, an admin turns it on under Settings → Plugins. Most of it is for admins; anyone asked to review access sees their reviews there.
Who can use it
Needs the Access Management plugin.
| Who | Can |
|---|---|
| Access Manager | Everything: the access history, who sees what and why, alerts, reviews and their evidence, the audit log's seal; start and close reviews; the settings. |
| Auditor | Read the access history, who sees what and why, alerts, reviews and their evidence, and the audit log's seal. |
| Anyone asked to review | Their own reviews, under Access Management in the sidebar. |
| Administrator | Everything. |
Who sees what, in detail: Who can see this, and why.
People: what can this person see, and why
Access Management opens on the staff. Pick someone to see:
| Part | What it shows |
|---|---|
| The desk | An admin sees everything; an agent sees the units they are placed in, and every unit below each. |
| Plugins | The projects they can use, their role, and how they got it: through a business unit, or added by name. Someone can have access both ways at once; they keep it until the last way goes. |
| API tokens | The tokens that act as them (never the secrets), what they may do, and when they were last used. |
| Recent changes | Changes to their access. |
Who can see this, and why
Who can see answers it for a business unit, a case (by its reference) or a project: everyone who can see it, and how. For a unit or case: admins, people placed in it, and people placed in a unit above it. A case restricted to some countries says so for the people it hides from.
History
Every grant and revocation since the plugin was turned on, newest first:
- placed in a business unit, or taken out (and a unit deleted with people in it);
- admin rights given or taken away; an account invited, disabled or enabled;
- access to a project through a unit or by name, and role changes.
Each entry says who it was, what, how (through which unit, or by name), who did it and when, and the review it came from. Filter by kind and change, or by a person (their page links here), and Export CSV for a spreadsheet or an auditor. Names are kept as they were, so the history reads the same after a person or unit is gone.
Access reviews
A review asks the right people to confirm each person's access, by a date.
Start a review → Snapshot and emails → Keep or Remove → Close review → Evidence
Starting a review
Start a review (admins) asks for:
| Field | What it is |
|---|---|
| Name | The name and what to check, for the email. |
| Due | The due date. |
| What to review | Who is placed in each business unit (always), who has admin rights, and the plugins' things, like dev projects. |
| Reviewers | For unit memberships and admin rights. Project owners review the people of their own projects (their own access goes to the reviewers). |
It takes a snapshot of who has access now, and emails everyone with something to review.
Keep or Remove
Reviewers open it from the email or Access Management → Reviews, and for each person press Keep or Remove. What Remove does depends on the item:
| Removing from | What happens |
|---|---|
| A unit | Takes them out of it at once (as if done under Users; the history says it came from the review). |
| A project | Takes away access given by name. Access through a unit stays, and the item says so (remove them from the unit, or the unit from the project). |
| Admin rights | Someone takes the Administrator role away under Users; until then the item is marked as still to do. |
Reviewers are reminded a few days before the due date (three by default) and every day while it is overdue.
Closing a review
When it is done, Close review. Evidence (CSV) exports every item with the decision, who decided and when, the note, and whether the removal was carried out.
[!WARNING] A closed review can't be changed; it stays as evidence.
Alerts
An email to the admins (or the people you pick in the settings), and an entry under Alerts, when one of these happens:
| Alert | By default |
|---|---|
| Someone is made an admin | On |
| Anyone gets access to anything | Off; busy desks get many |
| Many people get access to one thing at once, like a unit with ten people connected to a project | Ten people |
Mark all seen when you've looked.
Audit log: search, export and seal
The desk's audit log under Settings shows everything, newest first. Access Management → Audit log adds:
- Search by kind of entry (the start of its name:
user.for people,dev.access.for project access,case.deleted), by words, and by period, and Export CSV of what you find. Exports are audited too. - The seal. Within a minute of being written, each entry is sealed: its hash covers the entry and the hash of the one before. Check the seal hashes them all again and reports any entry that was changed or removed after it was sealed.
[!NOTE] Entries removed on purpose by retention are counted as such, not as problems.
Settings
Admins, under Settings → Access Management → Alerts and retention:
| Setting | What it sets |
|---|---|
| Alerts | Which ones, and who hears (empty: every admin, except whoever made the change). |
| Audit log retention | How long each kind of entry is kept, at least 30 days, like case. for a year. Older entries go every night. |
| Access reviews | How many days before the due date reviewers are reminded. |
[!NOTE] The desk's own housekeeping (Settings → Housekeeping) can still remove the oldest entries of every kind.
For AI assistants and the API
| Token scope | Gives |
|---|---|
access:read | Admins: history, who and what, alerts, the audit log and its seal. |
access:review | Decide the reviews you were asked for. |
access:admin | Start reviews, settings. |
| building a plugin. |