Before you begin
Use a work email address that you control. Your organization must designate an authorized workspace owner and decide which people may administer policy or review evidence.
- Ask whether your organization uses an approved SSO connection or the local sign-in path.
- Have the identity administrator agree to any membership and provisioning change.
Supported scope and current status
The public guided-pilot path verifies an identity before an employee reviews the workspace request. The broader self-service account, federation, SCIM and role workflows in the market plan need release-specific proof before use.
- Read /get-started for the currently published request flow.
- Do not interpret a login screen or verified address as workspace admission.
Compare this path with the published coverage table and the coverage guide.
Set up the path
Use the request and sign-in steps actually offered for your release; verify the email and complete the offered MFA challenge when directed. A RedactWall employee must approve the scoped request before owner access is available.
- Ask an authorized owner to assign the minimum role needed for each person.
- Confirm the provider and current role after the first sign-in.
Use the workflow
Use the console only under your own identity. An authorized owner reviews membership and role changes; a separate policy approval is still required before protection changes.
- Invite or change a member only through an authorized workspace control when available.
- Sign out when leaving a shared workstation.
Verify the result
Read back the active workspace, role and member state after a change. For revocation, verify the old session no longer reaches that workspace; a list update alone is insufficient.
- Check the current session and MFA state on a fresh sign-in.
- Use a second authorized reviewer for a privileged role transfer when your policy requires one.
Coverage references: 13 requirements, 0 currently passed
This guide is bound to 13 requirements in RedactWall's acceptance crosswalk, which is maintained internally and not published. A requirement counts as passed here only after current evidence for every bound scenario and authority has been published; none has been published yet.
See the public verification overview and the documentation coverage guide.
Denials and recovery
A pending, stale or denied request must not be treated as access. Use the offered recovery path for a lost factor or password; support can guide the request without asking for a password or factor code.
- Record only the error and approximate time when contacting support.
- After recovery, confirm MFA and workspace membership independently.
For customer-side next steps, read Recovery and support.
Billing and integration handoffs
Identity and membership are separate from purchased device capacity. SSO or SCIM setup requires your identity administrator and the exact supported provider scope; a verified person does not consume a managed-device seat.
- Ask for the current supported identity integration before changing your provider policy.
- Review /pricing before any commercial conversion.
Limits to keep in view
SCIM group creation, broad identity-provider compatibility and automatic tenant creation are not implied by this guide. A planned account workflow is unavailable until its exact permissions and recovery boundaries are demonstrated.
- Use /security for the public authentication boundary.
- Contact support if the console does not offer the step described for your release.
Review the current Disclosures before relying on a capability.