Do not remove an account

:::warning Account removal is blocked Do not select Remove account, accept Account alert, or retry an earlier removal attempt. Account removal is destructive, and the available evidence does not establish a safely verifiable deployed result, complete data consequences, or recovery path. :::

The Profile screen can show Remove account for the signed-in account. Source evidence explains why the control can be enabled or disabled, but its visibility is not proof that removal is currently available or safe for a deployed project.

Before you start

• Do not use this article as an account-removal procedure.
• Do not test the control with a real account, project, business, session, or device.
• Do not open the confirmation alert to inspect the flow.
• If an earlier attempt may have occurred, do not sign in and try again. Ask the project administrator or Ordering support to verify the account state first.

Availability states

What you observe	Source-intended meaning	Safe action
Remove account is visible but disabled	The signed-in account is at the technical administrator level that the current client prevents from removing itself	Leave the control unchanged. Ask the project administrator or Ordering support about the intended account-management path.
Remove account is visible and enabled	The signed-in account is not at that client-disabled technical level	Do not select it. Enabled does not prove deployed authorization, account ownership, configuration, or a recoverable outcome.
Account alert is already open	The confirmation boundary was opened, but no removal request is proven unless it was accepted	Close the alert without accepting it and escalate if removal is still needed.
The app returns to sign-in after an earlier confirmation	The current device cleared its local authenticated state	Treat the server result as unknown. Do not retry or infer that the account or its other sessions were removed.
A removed, protected, permission, connection, or unexpected error is reported	The service did not provide a safely verified removal result through this guidance	Preserve only the minimum visible error text and escalate. Do not retry.

Technical levels are implementation gates, not commercial role names, plan entitlements, or guarantees that a person is authorized to remove an account.

Consequences of accepting the alert

Current source intends an accepted Account alert to send a destructive account-removal request. The client then clears local app data and returns the current device to a signed-out state without waiting for the service response.

This creates an important boundary:

• Returning to sign-in does not prove that the service removed the account.
• Remaining signed in elsewhere does not prove that removal failed.
• The source does not establish whether every other session is revoked immediately.
• The source does not establish complete deletion, retention, recovery, or cascade behavior for related business, order, message, review, payment, or audit data.
• The service source changes some account identifiers, marks the account as deleted, records an audit event, and can run additional configured actions. Those effects are not a promise that every related record is erased.

Treat the action as irreversible even when its visible result is ambiguous. There is no documented undo or safe retry path.

Verify or escalate without acting

1. Stay outside Account alert, or close it without accepting.
2. Record whether Remove account is absent, disabled, enabled, or followed by an earlier sign-in screen or error. Do not include credentials, tokens, or unnecessary account data.
3. Contact the administrator responsible for the project or Ordering support through your approved process.
4. Ask them to verify the account, session, and data state before any further sign-in or removal attempt.

If you were signed out after an earlier confirmation, report that the local sign-out happened before the removal result could be verified. Do not present the sign-in screen as proof of deletion.

When removal guidance can return

Operational account-removal guidance remains unavailable until an authorized synthetic destructive test proves the complete contract on a fresh disposable fixture. That proof must include the installed app and deployed API versions, exact ownership and protection gates, one allowed removal request, success and failure observations, current-device and other-session consequences, retained and removed data, configured follow-on effects, timeout behavior, and a verified no-retry escalation path.

After that evidence exists, an independent security review must revalidate the public wording before any removal steps are published. Real accounts and reused fixtures are not acceptable substitutes.

Variations and limits

• The current client disables self-removal for its technical administrator level. The service also applies authenticated actor, self-versus-other-account, protected-account, configuration, and usage-limit gates.
• Client visibility and service authorization are separate. A visible enabled control does not prove that the server will accept the request.
• The installed Business App build and deployed API have not been correlated to the documented source pins.
• A confirmation, signed-out screen, error, changed profile, or later sign-in result is not complete account, session, or data-state proof.
• This article does not describe internal endpoints, numeric levels, account identifiers, server actions, or a workaround through another product.

Related articles

• Review and update your profile
• Understand technical access levels and business scope
• Recognize loading, connection, and error states

:::note Visual status Visual guidance is deferred. Reopen trigger: authorized synthetic capture program with accepted exact asset allowlist and independent visual QA :::