--- title: "Do not remove an account" description: "Understand when account removal can appear and why the action remains blocked until its destructive result can be verified safely." canonical: https://docs.ordering.co/docs/products/business-app/account/account-removal/ --- # Do not remove an account > **Account removal is blocked** > > Do not select **Remove account**, accept **Account alert**, or retry an earlier removal attempt. Account removal is destructive, and this guide does not establish the result, complete data consequences, or a recovery path. The **Profile** screen can show **Remove account** for the signed-in account. Its visibility is not proof that removal is available or safe for a 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.co Support to verify the account state first. ## Availability states | What you observe | What the state may indicate | Safe action | | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | **Remove account** is visible but disabled | The app prevents the signed-in account at its technical administrator level from removing itself | Leave the control unchanged. Ask the project administrator or Ordering.co Support about the intended account-management path. | | **Remove account** is visible and enabled | The signed-in account is not at the technical level for which the app disables self-removal | Do not select it. Enabled does not prove authorization, account ownership, configuration, or a recoverable outcome. | | **Account alert** is already open | The confirmation was opened, but no removal request is established 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 removal outcome is not established | Preserve only the minimum visible error text and escalate. Do not retry. | Technical levels are implementation gates, not role names or guarantees that a person is authorized to remove an account. ## Consequences of accepting the alert Accepting **Account alert** can send a destructive account-removal request. The app can then clear local data and return 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. - This guide does not establish whether every other session is revoked immediately. - This guide does not establish complete deletion, retention, recovery, or cascade behavior for related business, order, message, review, payment, or audit data. - The service can change some account identifiers, mark the account as deleted, record an audit event, and 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.co 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 you need removal This guide does not provide account-removal steps. Before any removal, confirm with the project administrator or Ordering.co Support: - the account's authorization and protection restrictions; - the expected account, session, and related-data consequences; and - how an unclear or failed request will be handled without retrying. ## Variations and limits - The app 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. - Installed app and service behavior can differ from this guide; do not rely on it for version-specific availability or consequences. - 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](https://docs.ordering.co/docs/products/business-app/account/profile/) - [Understand technical access levels and business scope](https://docs.ordering.co/docs/products/business-app/start/roles-business-scope/) - [Recognize loading, connection, and error states](https://docs.ordering.co/docs/products/business-app/app-behavior/loading-connection-errors/)