Administration

This section covers the questions an administrator answers rather than an analyst: who has access, what each of them can do, how they sign in, and how automation authenticates when there is no person involved.

Most of it is set up once and revisited rarely. The two things worth getting right on the first pass are roles, because the default is generous, and token naming, because a token you cannot identify is a token nobody will ever dare revoke.

Where do I start?

Setting up a new organization. Configure single sign-on first, then invite people. Doing it in that order means nobody establishes a password-based habit you later have to undo.

Adding people. User Roles and Types explains the four roles and, more usefully, which one is the right default. It is not the one Stairwell picks.

Connecting a script, a CLI, or a forwarder. Create and Revoke Auth Tokens, then What Auth Tokens Can Access for the scoping rule, which surprises people managing more than one environment.

Running several customers or business units. Multi-Tenancy and Organizations, read alongside Environments, since environments are what actually partition the data.

How does this relate to environments?

Roles decide what a person can do. Environments decide what data they can do it to. You need both to describe access, and confusing them is the usual cause of "why can they see that".

A Read Only user in an environment sees everything in it and can change nothing. A full User in a different environment sees nothing of yours at all. The role is not scoped to an environment; the data is.

What should I read next?

• Environments, the other half of every access question.
• Asset Identifiers, for the maintenance token, which is a different thing from an auth token and is often confused with one.
• REST APIs, for what a token is ultimately for.