The deployment owner, participant affiliation and application membership are separate concepts.
| Concept | Owner | Meaning |
|---|---|---|
| User identity | Identity provider | Authenticated account with a verified email. Provider IDs remain internal. |
| Deployment owner | Operator | Organization responsible for this executor and its resources. |
| Affiliation | Identity provider | Existing BA Labs, Soter Labs, Grove, etc. login organization. Not a data tenant. |
| Application role | Application declaration | Bundle of app-scoped permissions, assigned to emails. |
| Operator grant | Deployment operator | Explicit control-plane permissions, unavailable to app roles. |
| Template role label | Presentation | Friendly display metadata, not a membership assignment. |
See application access for the required policy and migration. An app cannot grant permissions to another app or platform administration. Emails are sufficient for declarative membership; account-linking and email-change lifecycle machinery are deliberately absent.
The trusted backend resolves the verified session, user ID, email and affiliation. For a process
operation it replaces provider/global permission claims with the selected app's declarations.
/api/me reports platform permissions and a separately keyed application permission map. Supply a
processId or templateKey to obtain target-scoped permissions. Never authorize a specific resource
using the union of other apps' grants.
The existing global-login → organization-selection → organization-login flow remains. The organization header must match the verified session; changing affiliation obtains a new token. This does not move records to a different owner or alter app membership. BA Labs users keep their existing accounts. OAuth signed state is also bound to the initiating browser with a per-flow HttpOnly cookie.
Within declared app membership, process access/start rules apply first, then step permissions, then field permissions. Step and field lists use OR matching. Unauthorized field writes are filtered, not silently made authoritative. Completion expressions can impose a separate finish condition. Existing source template permission metadata is not newly turned into a start gate.
Sharing can widen process access within app membership; it cannot bypass membership. Anonymous links are not a substitute for verified membership in this release. Review that access difference at cutover.
Only an explicit platform user:impersonate grant enables impersonation. Existing headers and user/org
selection remain, but the effective target's identity and app declarations determine authority.
The real actor remains on the principal and /api/me; canonical field audit records the effective
user. App roles cannot manufacture the platform impersonation grant.