Login or MFA: the user cannot sign in, complete first login, receive or use a one-time code, or complete MFA.

Invite state: the invite is missing, expired, already accepted, sent to the wrong user, or tied to the wrong tenant.

Tenant or MSP context: the user can sign in but cannot see the expected tenant, customer, admin view, user view, URL, or branded workspace.

Role or permission: a feature, model, workflow, integration, group, user-management action, or admin setting is hidden or access denied.

SSO, SAML, or SCIM: access is controlled by an identity provider, domain setup, SCIM provisioning, default-role behavior, or enterprise login policy.

Deprovisioning or duplicate user: the request involves removing a user, preserving work, account mapping, or a user appearing in the wrong place.

Confirm the user is using the correct email address and the expected Hatz URL or tenant context.

Confirm whether the user should be in the MSP admin view, a tenant workspace, or a user view.

Ask an MSP admin or account owner to confirm the user's role, group, tenant membership, and feature access.

For invitation issues, confirm when the invite was sent, which email address received it, and which tenant it should grant access to.

For SSO or SCIM users, confirm whether the identity provider controls the user's access before changing anything in Hatz.

For access-denied states, capture the exact product surface, action, message, screenshot, and time.

MSP, workspace, tenant, or customer account.

Affected user email or role, only when needed for the access investigation.

Expected tenant, role, group, or product surface.

Actual state: login failure, missing invite, wrong tenant, access denied, hidden feature, SSO error, SCIM issue, or another symptom.

Timestamp and timezone.

Screenshot of the error, invite state, access-denied state, or user-management screen, with unnecessary personal data removed. Do not include passwords, MFA codes, tokens, SAML assertions, SCIM payloads, identity-provider secrets, or private keys.

Whether the user is controlled by SSO or SCIM.

Whether an MSP admin or account owner has confirmed the intended access.

Do not make broad SSO, SAML, SCIM, domain, or default-role changes while a rollout is active unless an MSP admin or authorized identity owner understands the lockout risk.

Keep at least one verified admin recovery path available before changing login enforcement or identity-provider settings.

If an SSO or SCIM change could affect many users, pause and create a support ticket before changing settings so an authorized identity owner can review the risk.

Hatz will not disable MFA, merge users, move accounts, delete users, transfer assets, change SSO or SCIM enforcement, or change roles from an unverified chat message alone.

An admin or multiple users are locked out.

SSO, SAML, or SCIM behavior may affect many users, default roles, domain access, or tenant provisioning.

A user appears in the wrong tenant, duplicate account, or unexpected membership state.

A deprovisioning request involves ownership transfer, preserving work, removing an admin, or legal/security policy questions.

A role, permission, entitlement, or hidden-feature issue is blocking production work and the expected access is confirmed by an MSP admin or account owner.