How can we help you?

Trial Handoff Reset (Staff Only)

One action that gives a trial site a clean start before the customer takes over. Conversations and contacts that staff created while setting up the trial are tagged as setup demo data automatically, and the reset removes them together with the sample data and resets the usage counters, so reports start from zero. Nothing is hidden: it is deleted, with an export kept for rollback.

What it does

  • While a site is an unpaid trial, new staff-made test conversations (Velaro staff address or an admin test chat) are tagged as demo data when they are created.
  • The reset also tags staff setup conversations and contacts that already exist, so past test chats can be removed.
  • It then runs the existing demo-data clear (messages, tickets, contacts, call attribution, experience impact, enterprise reports) and the setup clear: usage counters, daily visitor stats, agent activity and status logs, visitor sessions, contact health, RCS usage, and survey submissions with their answers.
  • Only the staff reset does the setup clear. The customer's own "clear sample data" button only removes sample data and never touches setup chats, logs or counters.
  • Optional: reseed the existing sample data afterward.

Safety rules

  • Only unpaid trial sites. Paid or converted sites are refused unless the allow-non-trial option is set. Reviewer, internal, marketplace-billed and protected sites are always refused, even with that option.
  • Super admin only: the same sign-in rule applies to the REST action, the CLI, the staff MCP tool and the Moshky tools.
  • Dry run first: get_trial_reset or propose_trial_reset returns counts of what would be tagged and deleted. Nothing changes.
  • Applying needs update_trial_reset with confirmed=true after the counts were shown and approved.
  • Every deleted row is exported to private storage inside the same transaction as the delete, so the export holds exactly the deleted rows (sample seed rows such as demo schedules and deployments are regenerable and not included). The audit row is written against the target site.
  • Use this instead of the hide tools for trial sites; hiding is only for sites that already belong to a customer.

How to run it

1. propose_trial_reset with site_id and env. Show the counts.

2. After approval, update_trial_reset with the same inputs and confirmed=true (add reseed=true for sample data).

CLI: velaro trial-reset <siteId> --env staging (dry run), add --confirm to apply, --reseed, --allow-non-trial. Staff MCP tool: trial_reset.

How it works and where things are saved

  • Trial detection: a site counts as a trial in setup only while IsTrial is on and TrialExpiresAt is in the future. Staff-made chats are tagged only in that window. Converting to paid never hides or deletes rows; clearing is always an explicit action.
  • The reset is the same clear as the trial "clear sample data" button and the SuperAdmin demo-data clear, so they share one code path. Only the reset route exports first.
  • Export location: private blob container trial-reset-exports, blob name site-
  • Easy entry points: velaro trial-reset <siteId> (dry run, add --confirm to apply, --reseed to reseed) and the SuperAdmin site page action "Clear trial setup data (handoff)", which shows counts first and then asks for confirmation.

Rolling back

Download the export blob, then run velaro trial-reset-restore <file.jsonl.gz> --out restore.sql. It writes a T-SQL script that re-inserts every exported row in one transaction (IDENTITY_INSERT handled). Run it against the messaging database of the same environment.

Share: Email

Was this article helpful?