Atlas security policies are made of rules, and every rule grants exactly one level of access to a role, a user group, or a single user. There are five levels.
The levels
Discover lets someone know a thing exists. It comes first: with an explicit policy, someone who can’t discover a classification can’t get to it at all.
Read lets them open it and see what’s inside.
Write lets them change it.
Archive lets them take it out of use.
Manage makes a user group answerable for it — which is how Atlas knows whose work it is. Manage is only ever given to a user group.
Grantees
Each rule names one grantee:
- A role — everyone who holds a role, such as Crew Lead.
- A user group — a team, such as North Region Crew.
- A single user — one person.
Roles suit permissions that follow a job (“every crew lead can read properties”). User groups suit ownership and team-based access (“this team manages these properties”). Single-user rules are best kept for exceptions.
Why Discover is separate from Read
It might seem odd that knowing something exists is its own level. It matters because with an explicit policy, Discover is the gate: a person who can’t discover a classification can’t navigate to it. Separating Discover from Read lets you show someone that a module exists — so they know whom to ask — without showing them what’s inside.
Why Manage is different
The other four levels are about what a person can do. Manage is about responsibility. Giving a user group Manage access makes that group answerable for a classification and its topics, so work raised against them reaches a team rather than nobody. That’s why Atlas warns when a top-level data module has no user group with Manage access, and why topics created by an administrator appear under Unassigned Topics until they’re assigned a group. See Why every topic needs an owner.
Inherited and explicit rules
Rules come from two places:
- Inherited rules come from the policy’s Default Access Rights and apply to every classification using that policy. They appear dimmed in a classification’s Access Rights table.
- Explicit rules are created on one classification with Create a rule. They belong to that classification only and cover everything beneath it.
Worked scenarios
A crew lead who should find properties but not edit them. Grant the Crew Lead role Discover and Read on the Properties classification. They can navigate to properties and open them, but not change them.
An office administrator who maintains customer records. Grant the Office role Discover, Read and Write on Customers. Add Archive if they’re responsible for retiring old records.
A team responsible for a region’s properties. Grant the North Region Crew user group Manage on the relevant topics, so work raised on those properties reaches that team.
A contractor who should see one classification only. With an explicit policy, grant that single user Discover and Read on the one classification. Without Discover elsewhere, they can’t reach anything else.
Troubleshooting access
Someone can’t find a classification. Check Discover. With an explicit policy, no Discover means no access at all.
Someone can see it but can’t open it. They have Discover but not Read.
Someone can’t save changes. They need Write.
Work isn’t reaching anyone. Check that a user group has Manage. Atlas warns when a top-level data module has no user group with Manage access, and topics without an owner collect under Unassigned Topics.
Someone has access you didn’t grant. Look for inherited rules — they come from the policy’s default access rights and apply to every classification using that policy.
Levels and the rest of Atlas
Access levels connect to other parts of the platform:
- Manage and ownership. Manage is how Atlas knows whose work a topic is — see Why every topic needs an owner.
- Work queues. Work is scoped to roles, so the people who hold a role see the queue for it.
- APIs. Namespace-scoped access keeps API consumers inside the permissions you’ve set, so an application can’t reach data its users shouldn’t.
Frequently asked questions
Can one rule grant two levels? No. Each rule grants exactly one level; add several rules if someone needs more.
Can I grant a level to everyone? Grant it to a role that everyone holds, or use an inherit policy where no restriction is intended.
Is Archive the same as delete? Archiving takes something out of use; Atlas’s model is built around archiving rather than destroying history.
Why can’t I give Manage to a role? Manage is only ever given to a user group; choosing it switches the grantee type to Group and locks it.
Documenting your access model
Access decisions are easy to make and easy to forget. A short record saves time later:
| Information | Role or group | Level | Why |
|---|---|---|---|
| Properties | All staff | Discover | So people know what exists and whom to ask |
| Properties | Field crews | Read | They need site details on the job |
| Properties | Office | Write | They keep records current |
| Properties | Regional crew group | Manage | They answer for the work |
Keeping this table alongside your security policies makes reviews fast: you’re checking reality against a stated intention, rather than trying to reconstruct the intention from what exists.
Choosing levels: a starting point
| Who | Typical level |
|---|---|
| Everyone who should know a module exists | Discover |
| Staff who look things up | Read |
| Staff who keep records current | Write |
| Supervisors who retire records | Archive |
| The team responsible for the work | Manage (user group) |
Start narrow and widen as needed. It’s easier to grant access someone turns out to need than to take back access they shouldn’t have had. Least-privilege access for business data explains the reasoning.
