Before you start
Use roles only on the surface they belong to. Do not let runtime Project roles govern global console login, and do not block runtime auth changes because a Team Member has console access.
What you build
Lamba has three access layers:
| Layer | Applies to | Purpose |
|---|---|---|
| Workspace roles | Team Members | Workspace-wide console access |
| Project console roles | Team Members | Console access inside a selected Project |
| Project roles | Project Members | Runtime product access |
Implementation steps
1) Model console access first
Workspace owner, admin, developer, billing, support, analyst, and viewer roles describe workspace operations. They are not runtime product roles.
2) Model runtime access separately
Project roles govern product behavior such as viewing content, editing product resources, or administering Project member access.
3) Read authorization before rendering privileged UI
Always read effective authorization for the active session and context before showing privileged controls.
curl -X GET "$LAMBA_CUSTOMER_API_BASE/v1/me/authorization" \
-H "Authorization: Bearer $CUSTOMER_SESSION_TOKEN"
4) Still handle authorization failures
Permissions can change after a page loads. Handle 403 as a normal state, not as an impossible error.
Security and operational notes
- Do not treat Team Member status as Project Member status.
- Do not assign Project roles from Promote to Team Member.
- Keep permission labels user-facing and role IDs stable.
- Audit sensitive role changes.
Troubleshooting
If UI visibility looks wrong, compare the session context with the role catalog being used. Most mistakes come from checking a Workspace role when the page needs a Project role, or the reverse.
Related docs
- Permissions Catalog:
/docs/reference/permissions-catalog - Member Lifecycle:
/docs/concepts/member-lifecycle - Request Scoping:
/docs/concepts/request-scoping