Administration
This section is for the person who answers for atmon inside an organization: who may do what, what happened and when, and how the usage compares against what was committed. It applies whichever shape you run, because administration is the same product on our cloud and on your machines.
An administrator's console opens on governance rather than on work. Spend against ceilings, which principal a call is attributed to, which providers are refusing traffic, the approvals waiting on somebody, and the administrative record. A member of the same organization opens the same console on their own work instead. The difference is the role, not a different build.
The three questions
| The question | The page |
|---|---|
| Who may do what | Roles |
| What happened, and who did it | The audit record |
| How much has been used against what was agreed | Usage and the license |
Organizations, projects, environments
An organization is the billing and membership boundary. It holds people, and it holds projects.
A project is the isolation boundary. Connected accounts, policies, keys, receipts and collections all belong to one project and reach no other. Two teams that should not see each other's connections are two projects, and that is the cheapest control in the product.
An environment sits inside a project, so a project can pin staging and production to different catalog snapshots and move one without the other.
A person holds a role in the organization, and can hold a different role on a given project. The narrower one binds.
Adding people
Invitations carry the organization role and the project grants in one act, so a person arrives with the access they are meant to have rather than with none and a follow-up ticket.
Two refusals are deliberate and worth knowing before you meet them. Accepting an invitation while signed in as a different address is refused, and the refusal names the address it was sent to, because silently re-pointing an invitation is how a forwarded mail thread grants the wrong person access. And member management is session-only: an API key has no person behind it, so no key can add, remove, or re-role anybody, however wide its role.
Removing a member ends their membership, their sessions, and their keys. The removal dialog lists the live keys they minted first, so you can see what stops working before it stops working, and keep one deliberately if something depends on it.
Single sign-on
Not built. It is on the enterprise roadmap. The role model that would sit under it is built and shipping today, so what SSO will change is how a person proves who they are, not what they may do once they have.
Until it lands, administrators sign in by email on the enterprise console, and there is no key entry and no address entry on that door.
Organization settings carries the setting that would make single sign-on the only way in, and it stays unavailable until a connection has been verified for the organization. Requiring it before there is one to require would lock everybody out, including whoever turned it on.