Identity & Access — Overview

Honeyframe keeps every identity in one directory — the people who build and administer your workspace, and the people who only ever open a published app — and governs all of them through one authorization engine. This section is the map. Each page below goes deep on one piece of it.

Two kinds of identity

	Platform users	Site users
Who they are	People with a seat in your workspace — build, administer, or consume	People who only open a published app (a webapp) — never the build surface
Licensing	Consumes a licensed seat (admin / designer / analyst / viewer)	Seat-free — invite as many as you need
Write access	Depends on seat + group grants	Never — read-only, unconditionally
Scope	The whole organization	One deployment (a subscription_id) at a time
Set up on	Groups & Permissions	Site Users

Both kinds of identity are authorized the same way underneath — the same groups, the same permission strings, the same resolver. What differs is who they are and what ceiling applies to them before that resolver ever runs.

Two axes: role vs. group

Honeyframe's access model is deliberately two-axis, and the two axes answer different questions:

• Role is the capability axis — "what you're allowed to attempt." A platform user's role (admin / designer / analyst / viewer) sets their baseline: can this person build recipes and flows at all, or are they read-only by design? A site user's role (viewer / editor) is narrower still, and — see below — doesn't actually widen anything today.
• Group membership is the authorization axis — "what you can see." Permissions are never granted to a person directly. They're granted to a group, and a person's real access is the union of every grant held by every group they belong to — narrowed to one dashboard or one project, or opened organization-wide. This is the mechanism in Groups & Permissions.

A person can hold the "right" role and still see nothing, if no group grants them anything. Role decides whether a capability exists for them at all; group membership decides which specific resources it applies to.

Building a dashboard requires a licensed seat

Dashboard and flow authoring is a project.edit-class capability — gated to a designer-or-better platform seat. Site users can't be promoted into it by giving them a wider group grant: every write-class permission is denied for a site user unconditionally, before any group lookup even runs. It isn't a gap that a broader grant would close — it's an architectural wall.

In practice: if someone who normally only opens a published app now needs to build or edit dashboards, they need a real platform seat, not an elevated site-user account. Site users are viewers by design.

Where to go next

Page	Covers
Groups & Permissions	Creating groups, granting org-wide vs. per-resource permissions, the Authorization Matrix
Site Users	Inviting and managing seat-free app end-users, site scoping, the login flow for app developers
Applications & SSO (OIDC)	Registering an application for "Login with Honeyframe"

For the full permission-string catalog, seat types, and superadmin rules, see Security → Users and Groups and Security → Permissions Reference. For minting a Personal Access Token for scripts and CI, see Developer → Authentication.