AccountsPublic guide
Understand account classifications
Use test, Solo, Practice, Firm, Enterprise, platform and unassigned labels consistently without treating them as secret privileges.
Purpose
Use test, Solo, Practice, Firm, Enterprise, platform and unassigned labels consistently without treating them as secret privileges.
Obedience Cloud is the shared identity and tenant-control surface. It does not turn a platform role into a customer workspace role or a corporate owner, and it never exposes readable passwords or authentication-factor secrets.
Checks before action
- Test status is explicit metadata.
- Commercial class derives from organisation plan.
- Platform role is held only in server-side identity metadata.
Safe process
- Use the canonical hostStart on cloud.obedience.global or the approved obedience.cloud entry and confirm the secure browser origin before entering account information.
- Verify scope and authorityFor understand account classifications, confirm the account, organisation, role and customer case or contract reference before continuing.
- Complete the bounded actionUse the narrow control provided. Elevated operations require personal 2FA, exact-origin requests, unique request identifiers and durable audit availability.
- Review the resultConfirm provider-authoritative state, record the outcome and route any inconsistency to support without repeating a high-impact request blindly.
Expected records
- Derived account class.
- Underlying plan memberships.
- Separate role and security posture.
Security boundary
- Administrators can lock an account, revoke sessions or start a bounded support flow; they cannot read or choose the user’s password.
- A support actor session is time-limited, labelled, auditable and blocked from non-read HTTP methods.
- Tenant metadata is validated server-side and cannot contain executable JavaScript, secret credentials or hidden role elevation.
Did this guide help?
Only your answer, guide slug and version are recorded.