OrganisationsPublic guide
Understand organisation roles
Separate provider membership roles from Quantify application roles and customer-specific stakeholder duties.
Purpose
Separate provider membership roles from Quantify application roles and customer-specific stakeholder duties.
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
- The role source is provider-authoritative.
- Application permission mapping is documented.
- Project stakeholder duties are scoped separately where needed.
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 organisation roles, 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
- Membership role.
- Workspace role metadata.
- Named review of elevated assignments.
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.