Skip to content
flowlakes FlowLakes documentation home

Identity and access

Identity and access decides who a request is and what they may do. Who they are comes only from their signed login token, never from a request header, and every request is scoped to their tenant. What they may do comes from two layers: Platform Capabilities named platform.<area>.<read|write> govern the admin areas and the tables those areas own, and per-table RBAC governs your application tables. If a permission check cannot be evaluated, the answer is deny. The same rules apply to API calls, AI agents, and blueprint installs alike.

When you’d use it

  • Give a role the right reach with capabilities for the admin areas it needs.
  • Grant access to an app table with per-table read and write.
  • Let people sign in with Entra over SSO instead of a local password.
  • Keep Entra groups in sync with platform roles through a projection.

What you manage

Identity and access lives under Access & Governance. What you configure:

  • People (/admin/iam/users). One row per person, written from their grants: the level, the desks they work in, their teams, the last sign-in, and a status flag when access has expired, is not active, or was never given. Search by name or email, sort any column, and use the filter buttons (each shows its count) to find admins, people with no access yet, expired or inactive access, or the accounts the platform made for its agents. A person’s page is where access is given: the level, one role per desk, and Try it, which answers “Can this person change an incident?” with the same check the app runs and shows the chain behind the answer.
  • Teams (/admin/iam/groups). Who is in a team and what the team brings.
  • Roles (/admin/iam/roles). Grouped by desk, each with the one sentence a person’s page shows. A role’s page lists what it grants by record kind and verb, who holds it, and the platform capabilities as sentences. The roles the platform makes (the base levels, the capability blocks, agent roles) are listed read only.
  • Capabilities on a role. The platform.<area>.<read|write> grants that open admin areas.
  • SSO (/admin/settings/sso). Entra sign-in over OIDC.
  • Group projections (/admin/entra-group-projections). Mapping an Entra group to one or more platform roles.

Manage roles and capabilities, and set up Entra sign-in, in the admin guides.

Good to know

  • A capability governs the tables its area owns. Holding platform.rules.read grants read on that area’s tables; app tables outside any area stay on per-table RBAC.
  • A menu item and the page it opens resolve to the same authorization, so navigation and data never disagree (no “shown but 403”).
  • Entra sign-in is validated end to end (signature, issuer, audience, nonce, tenant binding), with no unvalidated shortcut.
  • A group projection records provenance on the grants it creates, so disabling it removes exactly those grants and nothing else.
  • Permission checks fail closed. An evaluation error denies rather than allows.
  • A table with no access rule is no longer open to staff by default. Record-level access (internal notes, every record versus only your own) is declared per table. A table that declares no rule used to read as “everyone who can read it sees every record,” which quietly made every holder of read staff. It no longer does: staff status on a table with no rule still requires holding administer on that table (or on the root table a shared rule reaches), the same requirement a table with a declared rule already has. A desk role that should see every record on such a table needs administer, not a looser read grant.
  • A role can see every record of a kind without being that table’s administrator elsewhere. The Request Fulfiller role, for example, sees every Service Request through its own administer grant on Requests; that grant is scoped to Requests and carries no power over any other table. There is no narrower level that gives full visibility without also giving full record management: holding administer is what “sees every record” means today.
  • One person, two user records is reported and merged in one place. When Entra and Active Directory each created a record for the same person, the Entra source page lists the pairs (joined by the directory link, or by an identical name, labelled as such) with a Merge action. Merging keeps the Active Directory record, moves the Entra identity onto it, and deactivates the other record. A record still referenced elsewhere is refused and named.

How it connects

This primitive owns identity, capabilities, per-table RBAC, and tenant scoping. It does not model org hierarchy (that is tenant data) and it does not store secrets (those live in Credentials and secrets). AI agents obey this same model through their service-account user, covered in the agent safety model.

  • A person’s profile picture belongs to their account: anyone in the tenant sees it, only they set it, and an admin with platform.iam.write can remove it.
  • Manage roles and capabilities in the admin guides. Which role an application ships with, what each grants and who may change which Setup stage: Roles: who sees what, who configures what.
  • Exact shapes: the capabilities reference lists every platform.* capability and the tables each area governs; capabilities follow platform.<area>.<read|write>; the principal is derived from the token’s user id and tenant id; every term in the glossary.