Skip to main content
This section is for root administrators only. Every action described here is irreversible without database backups. There is no “undo” button. Read each section carefully, understand the consequences, and always double-check the domain name before confirming.
Tenant Operations are platform-level actions that operate on an entire tenant’s data at scale. They are separate from normal tenant management (Tenants) because they delete or duplicate data wholesale rather than editing a single record. This page focuses on destructive-only operations. For everyday tenant creation, updates, and basic administration, see Tenants.
Tenant Operations panel showing Clear Location Sales, Wipe Tenant, and Clone Tenant actions with a confirmation field

​
Clear Location Sales

Deletes all tickets, workdays, e-invoices, and related ledger data (payments, transactions, charges) for a single location within a tenant. Use this to reset a location’s sales history without affecting other locations or the tenant’s configuration.

​
What Gets Deleted

  • Tickets (all sales orders for that location)
  • Workday records (shift/workday containers)
  • E-invoice documents (LHDN submissions, QR codes)
  • Ledger data tied to sales: payment records, transaction lines, charges, refunds, discounts

​
What Stays

  • Location configuration (name, address, settings)
  • Catalog (products, categories, pricing, taxes)
  • Employee records (names, roles, POS logins)
  • Other locations in the same tenant (completely unaffected)

​
Form Fields

​
Use Cases

  • Demo or test run: You ran a demo on the live location and want to clean up the test orders before handing over to the client.
  • Data entry error: An employee accidentally created tickets in the wrong location; clear them and re-enter in the correct location.
  • Re-opening after maintenance: A location closed for renovation; clear old tickets and start fresh on re-opening day.

​
Workflow

1

Go to Tenant Operations → Clear Location Sales

Select the tenant first, then the specific location to clear.
2

Review what will be deleted

The UI lists the location name, date range, and approximate row count for confirmation.
3

Type the domain name

Enter the tenant’s exact domain name (e.g., my-restaurant.duitpos.io). This is a critical safety check.
4

Confirm

Click the button. The deletion is immediate and cannot be undone.
This action is permanent. All deleted data is lost except from database backups taken before the deletion. The audit trail of deleted sales cannot be recovered. Once you click confirm, there is no way to reverse this operation.

​
Wipe Tenant (“Refresh Data”)

Truncates every table in a tenant’s database — deleting all data without exception — and then reseeds the tenant with default roles, permissions, and a single admin user. The tenant is then ready for fresh configuration from scratch, as if it were a brand-new signup.

​
What Gets Deleted

  • Everything: all tables, all rows
    • Products, categories, suppliers
    • Tickets, workdays, e-invoices
    • Employees and their login credentials
    • User accounts and roles
    • Settings, configurations, integrations
    • Device profiles, printer routing rules
    • Payments, transactions, ledger entries

​
What Happens After

The platform automatically reseeds the tenant with:
  • Default role structure (Admin, Manager, Cashier, Kitchen)
  • One default admin user (e-mail shown in confirmation dialog; temporary password generated)
  • Default tax configuration
  • Empty product catalog

​
Form Fields

​
Use Cases

  • Resetting a test/demo tenant: You’ve been testing features and want to clear all test data for the next demo.
  • Starting fresh: A business explicitly requested a full reset and wants to configure everything from zero.
  • Recovering from a large failed import: An automated data migration or bulk import went wrong and contaminated the entire tenant; wipe and start over.

​
Workflow

1

Go to Tenant Operations → Wipe Tenant

Select the tenant from the dropdown.
2

Review the warning

The UI reminds you that this deletes all data and requires the domain name to confirm.
3

Type the domain name

Enter the tenant’s exact domain name (e.g., my-restaurant.duitpos.io).
4

Submit

The wipe job is queued. The UI shows the job ID and returns immediately.
5

Monitor status

The actual truncation and reseeding happens in the background. You’ll see status notifications in the dashboard. Depending on tenant size, this may take a few minutes.
6

Log in with new credentials

Once complete, the tenant is ready. Log in with the default admin e-mail and temporary password provided in the wipe result.
After a wipe, the platform automatically creates a default admin user so someone can log back in and start configuration. The exact e-mail and temporary password are displayed in the wipe operation result.
This is the most destructive action on the platform. Wipe Tenant permanently deletes every row in the tenant’s database with zero exceptions and no recovery path (except database backups at the infrastructure level). Only use it on test/demo tenants or when a business has explicitly requested a full reset. Always verify the domain name one more time before confirming.

​
Clone Tenant

Creates a new tenant by copying the configuration (but not sales history or secrets) from an existing source tenant. The new tenant is provisioned on a separate PostgreSQL database server and is immediately ready to use.

​
What Gets Copied

  • Complete catalog configuration: products, categories, pricing, modifiers, recipe/ingredient structure
  • Menu structure: menu items, menu categories, seasonal menus, availability rules
  • Tax setup: tax groups, tax rates by jurisdiction
  • Payment types & processors: payment method configuration (Stripe, Share Commerce, etc.), processor settings
  • User & role structure: roles and their permissions, user accounts (see note on passwords below)
  • Order modes: dine-in, takeaway, delivery, online, kiosk — all settings
  • Printer routing rules: device profiles, ticket printer routing, label printer routing
  • Device profiles: POS terminal configurations, display settings, receipt templates
  • Employee records: staff names, positions, roles (but not passwords/PIN codes)

​
What Does NOT Get Copied

  • Sales history: no tickets, workdays, e-invoices, or ledger entries (payments, transactions, charges)
    • Rationale: The clone is meant to be a template. You don’t want test/demo sales history to appear in a new production tenant.
  • API keys and secrets: Stripe keys, webhook secrets, integration credentials
    • Rationale: Automatic copying of production secrets is a security hazard. Each tenant’s integrations must be set up explicitly.
  • Password/PIN reset data: Employee POS PIN codes and password hashes are never copied.
    • Rationale: Security—cloned users must reset their passwords on first login.
  • Source tenant’s domain name: The clone gets a brand-new domain name based on the name you provide.
    • Rationale: Each tenant must have a unique domain. The source remains unchanged.

​
Form Fields

​
Use Cases

  • Franchise onboarding: A new franchisee is signing up. Clone the master menu and configuration from an existing location to save weeks of manual setup.
  • Test configuration changes: Clone a working tenant, make risky configuration changes on the clone, verify it works, then apply the same changes to production (or delete the clone if something breaks).
  • Demo environment: Create a pristine copy of a production tenant as a demo/sandbox for stakeholders to explore without affecting real data.
  • Regional rollout: You have one restaurant’s configuration that works well. Clone it for each location in a multi-location rollout.

​
Workflow

1

Go to Tenant Operations → Clone Tenant

Select the source tenant whose configuration you want to copy.
2

Name the new tenant

Enter a display name for the new tenant (e.g., “Burger Palace - Downtown”). The domain is auto-generated (e.g., burger-palace-downtown.duitpos.io).
3

Choose a database server

Select which PostgreSQL server will host the cloned tenant’s database. This can be the same server as the source or a different one.
4

Confirm country code

The source tenant’s country is pre-filled. Change it if the new tenant is in a different region.
5

Submit

The clone job is queued. You see a job ID and “queued” status immediately.
6

Monitor progress

The actual copy happens in the background. Status notifications show progress. Small demo tenants clone in seconds; large catalogs may take 2–5 minutes.
7

Verify the new tenant

Once complete, the new tenant appears in the Tenants list. Log in with the source tenant’s admin credentials (credentials are copied for convenience during setup). Change the admin password immediately.
Safe configuration changes: Clone a tenant, test major changes (menu restructure, new tax logic, printer routing) on the clone, verify it works, then delete the clone if satisfied. The production tenant remains untouched. This is much safer than editing configuration directly on a live restaurant.
Cloned users must reset their credentials. Employee POS PIN codes and password hashes are never copied for security. Cloned users will need to reset their passwords on first login to the new tenant.

​
Decision Table: Which Operation Should I Use?

Use this matrix to pick the right operation:

​
Frequently Asked Questions

This is a deliberate safety check. Both actions are permanent and cannot be undone. Requiring the exact domain name forces you to pause and verify you’re operating on the correct tenant — especially important when you have multiple browser tabs open with different tenants. It prevents accidental clicks from destroying the wrong tenant’s data.
No. Both actions permanently delete data with no recovery mechanism in the dashboard itself. The only recovery path is a database backup taken before the action. If your infrastructure has automated backups (e.g., AWS RDS snapshots, PostgreSQL WAL backups), you can request a restore from your hosting/database admin. Otherwise, the data is gone forever.
Only if you have a database backup from before the deletion. Contact your hosting provider or database administrator to request a point-in-time restore. This requires infrastructure-level backups (outside the DuitPOS platform). See your backup retention policy to know what restore windows are available.
It depends on the size of the source tenant:
  • Small demo tenant (100 products, minimal settings): a few seconds
  • Medium restaurant (500–1000 products, standard config): 30 seconds to 1 minute
  • Large chain location (2000+ products, complex routing rules, many employees): 2–5 minutes
The job runs in the background. You do not need to keep the browser window open. Check the Tenants list a few minutes later to see the new tenant.
No. Clone Tenant is designed to duplicate configuration (catalog, settings, user structure) as a template, not historical sales data. If you want to include sales history, you must request a database backup restore or custom data migration — contact your platform team.
No. Secrets are never copied for security reasons. After cloning, you must:
  • Re-enter API keys for integrations (payment processors, e-invoice providers, etc.)
  • Re-configure webhook endpoints and secrets
  • Verify all external integrations point to the correct environment (test vs. production)
This is deliberate — automatic copying of production secrets to a clone would be a serious security risk.
Passwords and PIN codes are never copied. This is a security feature — you don’t want cloned employees to have the same credentials in two separate tenants (it would be impossible to know which tenant they’re logging into).After cloning, cloned employees must reset their password on first login to the new tenant. You can send them a password reset link, or they can self-service via “Forgot Password.”
You cannot rename a tenant’s domain name after creation. The domain is permanent and immutable. If you want to change a tenant’s domain, you would need to:
  1. Clone the tenant with the new desired name
  2. Manually migrate any remaining data if needed
  3. Delete the old tenant
This is not recommended because it’s error-prone. Plan domain names carefully when creating tenants.
Yes. When cloning, you can choose a different database server for the new tenant. This is useful if:
  • You’re migrating to a new infrastructure
  • You want to distribute tenants across geographically separated databases
  • You’re consolidating tenants onto a new server
The clone operation handles data transfer automatically.
Subscriptions and billing are separate from data. Cloning copies only configuration and catalog data, not subscription/license information. You must:
  • Assign a separate subscription to the cloned tenant in the billing system
  • Ensure the new tenant has the appropriate license/entitlements for its features
  • Update the country code if billing depends on it (VAT, tax setup, etc.)
Contact your billing administrator to set up the subscription for the cloned tenant.
Yes. Wipe Tenant, Clear Location Sales, and Clone Tenant operations are logged in the root admin audit trail with timestamps and the admin user who triggered them. However, the actual deleted data is not recoverable from the audit log — only the fact that the operation occurred.
  • Clear Location Sales: Deletes sales data (tickets, workdays, e-invoices) for one location only. Configuration, catalog, and other locations stay intact.
  • Wipe Tenant: Deletes all data in the entire tenant database (all locations, all configuration, everything) and reseeds defaults.
Use Clear Location Sales if only one branch needs cleaning. Use Wipe Tenant if you want to reset the entire business.

Tenants

Create, list, and manage tenant accounts

Database Servers

Provision and manage PostgreSQL servers for tenant hosting

Root Users

Manage platform admins who can perform these operations

Locations

Manage individual branches/locations within a tenant