> ## Documentation Index
> Fetch the complete documentation index at: https://help-empuls.xoxoday.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Delete your Empuls account
> Understand what permanently deleting your Empuls account destroys, who can start the request, the emailed confirmation code it requires, and why it cannot be undone.
Deleting your Empuls account is the most destructive action in the product. It is a different action from cancelling your subscription, it is confirmed with a code emailed to the admin who starts it, and the interface offers no undo control, no confirmation-window countdown, and no self-serve way to restore the account afterwards. Unredeemed reward points held by your employees are lost. If you are trying to stop being billed, cancel the subscription instead — see [Subscription and billing](/admin/finance/subscription-billing).
## What deletion actually does
Account deletion is a two-call flow on the billing screen, at the route `/home/billing-information/delete-empuls`:
| Step | What runs |
| ------------------------------- | ---------------------------------------------------------------------------------------------- |
| You request a confirmation code | `admin.mutation.get_otp_disable_company_query` — returns a `request_id` and triggers the email |
| You submit the code | `admin.mutation.disable_company_query` — receives the 6-digit code plus that `request_id` |
Both calls are server-authorised. The screen submits nothing else: there is no free-text reason, no scheduled date you choose, and no ticket raised on your behalf.
The account is *disabled* by this mutation (`disable_company_query`), and the confirmation screen's wording keys describe the outcome as a submitted request and a scheduled deactivation rather than an instant wipe. The exact timing is decided server-side and is not shown anywhere in the interface — do not assume you have a window in which to change your mind.
## Who can start it
Three things gate the request:
* **The payments permission.** The billing screen sits behind the ACL entry `menuName.billing_information`. In the access-control permission matrix, that permission can only be granted to general admins — the manager and user columns for it are locked and cannot be edited — so in practice this means a Super Admin, or an admin a Super Admin has explicitly given payments access. See [Access control](/admin/user-management/access-control).
* **The subscription state.** The entry point on the billing screen renders only while the account is in a cancellable billing state (internally, `billing_screen_status` of 1, 2 or 4). Once a subscription has already been cancelled (status 5), the billing screen shows a reactivate control instead and the delete entry point is not rendered.
* **Server authorisation on the mutation itself.** The delete route carries no client-side role check of its own — reaching the URL is not the same as being allowed to complete the flow. The final gate is on `admin.mutation.disable_company_query` in the backend, which is not visible from the web application source, so treat the permission list above as the client-side view only.
Accounts billed through Microsoft Teams reach the same screen from the Teams billing view, which carries its own entry point to `/home/billing-information/delete-empuls`.
## What is forfeited
The screen lists its consequences as a fixed set of bullets. Their wording comes from your tenant's translation table, so the text you see may differ, but the keys tell you what each one covers:
* The process is irreversible.
* Reward points are lost.
* Users lose access to the platform.
* Platform data becomes inaccessible.
* Unredeemed reward points are covered explicitly and separately.
* A figure computed from your redemption reserve.
In plain terms: every reward point your employees hold but have not spent goes away with the account. Points are not paid out, transferred, or converted to anything an employee keeps. Anyone with an unspent balance should redeem it before you start this flow — see [Redeem points](/employees/redemption/redeem-points).
## The reserve figure on the screen
The last bullet interpolates a number the screen computes itself, from two separate reads:
* Your redemption reserve balance, from `points.query.get_redemption_reserves_or_store_query` (the wallet's `companyBalance`).
* Your points conversion factor, from `admin.query.payment_query` (`company_payment_info[0].conversion_factor`).
It then displays `redemption_reserve / conversion_factor`.
Read that arithmetic carefully before you treat the number as money. Elsewhere in Empuls the conversion factor converts *points into currency* — the points administration screen values a points balance as `points x conversion_factor`, and displays the factor as an amount of currency per point. Dividing a currency reserve balance *by* that factor therefore yields the reserve expressed as **a number of reward points**, not a currency amount. Consistently with that, the screen formats the figure as a plain number with no currency symbol and no currency code beside it.
Do not read that figure as a guaranteed refund. What the sentence around it claims is in a tenant-supplied label this documentation cannot verify, the number itself is a points-equivalent of your unused reserve rather than a settlement amount, and nothing in the deletion flow initiates a payment. If money is owed back to you, settle it with [cs@xoxoday.com](mailto:cs@xoxoday.com) in writing **before** you delete, not after.
## How the flow runs
The delete entry point sits on the billing screen, in its own block below the subscription details. It navigates to `/home/billing-information/delete-empuls`, and the screen's back control returns to `/home/billing-information`.
A single checkbox acknowledges the terms.
Nothing can be requested until it is ticked, and it locks once a code has been issued.
The request control fires `get_otp_disable_company_query`. On success the screen stores the returned `request_id`, reveals the code field, and starts a 5-minute countdown.
The code arrives by email; the field is labelled as an emailed code.
The web application sends no recipient address with the request, so which mailbox receives it is decided server-side and cannot be confirmed from the interface. Check the mailbox of the admin performing the deletion first.
The field accepts digits only, is capped at 6 characters, and is masked as you type. Submission stays disabled until exactly 6 digits are present. An incorrect code returns an invalid-code error and you can try again.
The resend control is disabled for the full 5 minutes and only becomes available when the timer reaches zero. Each resend issues a fresh `request_id` and restarts the timer. The 5 minutes is the resend cooldown; how long a code stays valid is not stated anywhere in the interface.
Submitting fires `disable_company_query` with the code and the `request_id`.
On success a full-screen confirmation takes over the window. It names your tenant as `your-subdomain.xoxoday.com` and states that deactivation is scheduled and that an email confirmation follows.
This overlay has no close control. Its single button navigates the same tab to `https://www.empuls.io`, so it is a one-way exit from the admin interface — there is no route back to the billing screen from it.
## What you cannot get back
Stated plainly, because the interface does not state it for you:
* **There is no undo control.** No screen in the product reverses `disable_company_query`. The billing screen's reactivate control applies to a *cancelled subscription*, not to a deleted account.
* **There is no visible grace period.** The interface shows no countdown, no scheduled-deletion date, and no "restore before" deadline. Do not plan around one.
* **Unredeemed reward points are gone.** Not held, not refunded to employees, not transferred.
* **Platform history is inaccessible.** Recognition history, feed content, survey responses, budgets, and reports go with the account. If you need any of it, export it first — see [Raw data report](/admin/reports/raw-data-report).
* **Reserve funds are not settled by this flow.** Nothing in these two mutations moves money.
If any of that is a problem, stop and email [cs@xoxoday.com](mailto:cs@xoxoday.com) before you tick the acknowledgement.
## Before you delete
Run the exports you will want later — recognition, budget, redemption, and login history are all available as CSV from the [Raw data report](/admin/reports/raw-data-report).
Give people a redemption window and tell them the deadline. Once the account is gone, unredeemed balances are not recoverable and cannot be paid out.
Check your reserve balance on [Points administration](/admin/finance/points-administration) and your outstanding invoices on the billing screen, and settle both in writing with [cs@xoxoday.com](mailto:cs@xoxoday.com). The deletion flow does not settle anything.
If the goal is to stop paying, cancellation stops the subscription at the end of the paid period and can be reactivated afterwards. Deletion cannot. See [Subscription and billing](/admin/finance/subscription-billing).
## Deletion is not cancellation
| | Cancel subscription | Delete account |
| ---------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Mutation | `billing.mutation.cancel_subscription` | `admin.mutation.get_otp_disable_company_query` then `admin.mutation.disable_company_query` |
| Extra confirmation | None beyond the confirm dialog | 6-digit code emailed to the requester |
| Access after it takes effect | Continues to the end of the paid period, then employees lose access | The account is disabled |
| Reversible in the product | Yes — a reactivate control appears on the billing screen | No control exists |
| Reward points | Not destroyed by the cancellation itself | Unredeemed points are lost |
## Related
Cancel or reactivate a subscription, change plan, and manage invoices.
Check your redemption reserve balance and points conversion factor before you act.
Export transaction-level history while you still can.
See which admins hold the payments permission.