Skip to main content

Administrator Roles

An administrator role decides what someone can do in the admin console — which pages they see, and which actions they can take on each one. Beak ships a catalogue of built-in roles so you can delegate console work without designing permissions yourself.

These roles are separate from the product roles you assign to a tenant's own users. A product role decides which Beak products someone can open; an administrator role decides what they can administer. Assigning one has no effect on the other.

How a role decides what someone can do​

Every role is a set of permissions at a scope. The scope is the part people most often miss, so it is worth stating plainly:

  • Global — the role reaches every tenant, including tenants created after the role was assigned.
  • Tenant — the role reaches one named tenant.
  • Company — the role reaches one company inside one tenant.

An administrator can hold more than one role. Their access is the sum: someone with a tenant-scoped role in two tenants administers both, and nothing else.

Note: Two kinds of access are account tiers, not roles, and neither appears in the catalogue below. The platform super administrator has full access to everything and exists so the platform can be bootstrapped and recovered. A Tenant Administrator has full control of one tenant — every company and every setting in it — and holds no roles, because the tier itself is the access. Everyone else is a delegated administrator, and gets their access entirely from the roles assigned to them.

Global Administrator​

Global Administrator carries every permission, in every tenant. It is the console equivalent of the platform super administrator, granted as a role rather than as an account tier.

Use it for the small number of people who genuinely run the platform. Before this role existed, the only way to give someone complete control of Beak IAM was to make them a platform administrator — which is an account tier, not something you assign, revoke, or see on the Administrators list. Global Administrator closes that gap: it is assignable, revocable, and visible.

Someone holding it can do everything the console offers, across every tenant:

  • Users and access — create, invite, import, export and delete users; reset passwords; assign product roles; revoke sessions.
  • Tenants — create, suspend, activate and decommission tenants and their realms.
  • Security and sign-in — password policy, two-factor policy, brute-force protection, IP rules, and identity provider / SSO / LDAP configuration.
  • Platform configuration — platform settings, the role-service catalogue, module categories, branding, email configuration, API keys and webhooks.
  • Administration itself — create administrator roles and assign them to other people.

That last point is the one to weigh before you assign it. A Global Administrator can grant Global Administrator to someone else, so the decision propagates.

Prefer a narrower role where one fits. Most console work does not need everything, and the built-in catalogue below is deliberately split so that it usually does not have to.

The built-in catalogue​

Built-in roles are marked System on the Administrator Roles page. They cannot be edited or deleted, so the meaning of a role name never drifts between environments. You can always create your own role alongside them.

Reaching every tenant​

  • Global Administrator — everything, everywhere. Described above.
  • Global User Administrator — create, invite, import and manage users and assign product roles in every tenant. Cannot manage tenants, security or sign-in configuration.
  • Global Reader / Auditor — read-only visibility across every tenant, plus audit export. The right role for compliance and security review.
  • Global Helpdesk Administrator — cross-tenant break-glass: reset passwords, revoke sessions, resend invitations. Cannot create users or change roles and policy.
  • Global Security Administrator — cross-tenant security posture: password policy, two-factor, brute-force, IP rules, identity provider / SSO / LDAP configuration. Reads users but does not create them.
  • Tenant Provisioning Administrator — platform operator: create, suspend, activate and decommission tenants and realms, and manage the role-service catalogue. Does not manage end users.
  • Role Administrator — define product-role bundles and their product codes. Separate from who assigns them.

Reaching one tenant​

  • Tenant User Administrator — manage users and assign product roles within one tenant. No security or sign-in configuration.
  • Tenant Security Administrator — manage security policy and identity provider configuration within one tenant. Reads users but does not create them.
  • Tenant Helpdesk — reset passwords and revoke sessions within one tenant.
  • Tenant Auditor — read-only visibility within one tenant, plus audit export.

Reaching one company​

  • Company Administrator — manage users and assign product roles within a single company inside a tenant.

Assigning a role​

  1. Open Administrators in the admin console.
  2. Choose the administrator, then add a role.
  3. Pick the role, and — for a tenant- or company-scoped role — the tenant or company it applies to. A global role needs no binding; it already reaches everywhere.

Three rules constrain every assignment, and they apply to you as much as to anyone else:

  • You cannot grant what you do not hold. If your own access does not already include a permission, you cannot put it into a role or hand it to someone. In practice this means only a platform super administrator, or an existing Global Administrator, can assign Global Administrator.
  • You cannot grant beyond your own reach. An administrator scoped to one tenant can never assign a global role, even inside that tenant.
  • Nobody edits their own assignments. You cannot grant yourself a role, which stops an administrator using their own account to widen their access one step at a time.

Every assignment is recorded in the audit trail, with who made it and when.

Changing what an administrator can do​

Edit on an administrator's row opens the same questions you answered when you created them — how far they reach, which tenant or company that applies to, and which roles they hold. Changing any of it takes effect immediately.

  • Tick and untick roles to grant and revoke them. The list you see is the whole of what the administrator will hold when you save: a role you untick is revoked. Roles you leave alone are untouched, so their original assignment date and the name of whoever granted them are preserved in the audit trail.
  • The roles offered match the reach you have selected. Switch from one tenant to all tenants and the list changes, because a role's scope is what decides where it applies. If the administrator holds roles of a scope the form is not currently showing, it says so and names them before you save.
  • A delegated administrator must keep at least one role. An account with none can sign in and do nothing, which looks broken rather than restricted. To remove someone's access entirely, disable the account instead.
  • Promoting someone to Tenant Administrator revokes their roles. That tier already holds full control of the tenant, so roles attached to it would appear in the console and grant nothing. The dialog warns you before this happens.
  • Name and phone number are editable too. Both are contact details on the administrator's record rather than access, so anyone who can edit an administrator can set them — including for someone else, and including on your own account.

Editing is bound by the same three rules as assigning. You still cannot grant a permission or a reach you do not hold yourself, and you cannot change your own roles — though you can correct your own name and phone number. Revoking is not restricted the same way: you can strip a role that is wider than your own access, because taking access away cannot widen anyone's.

Everything about the change is recorded in the audit trail, including which roles the administrator held before and after.

Note: The email address and home tenant cannot be changed here. The email is the account's identity in the console, and the home tenant is what every tenant- and company-scoped role is bound to — moving either one is a new account rather than an edit. Passwords and account status have their own actions on the administrator's row.

Best Practices​

  • Keep Global Administrator to a small, named group. It is the widest access the console offers, and it can hand itself out. Two holders is a sensible floor — recovery from a lost device runs through another administrator — and a short list is a sensible ceiling.
  • Reach for the narrowest role that does the job. Someone who resets passwords all day wants Global Helpdesk Administrator, not Global Administrator.
  • Prefer tenant scope where the work is tenant-shaped. A global role silently covers tenants created next year; a tenant-scoped one does not.
  • Review assignments when people change roles. Revoking an administrator role is immediate and does not touch the person's product access.