Archive, restore, and merge accounts safely

Current implementation boundary: These actions are not interchangeable. Staff Archive changes account status. Restore changes status back but does not reconstruct deleted payment methods, changed login identity, or changed schedule rows. Merge Accounts rewrites selected record ownership and has no customer-facing undo. The Online Client Delete My Account action performs additional changes and is not the same as staff archive.

Warning: A wrong survivor, source ID, or family relationship can move charges, payments, saved payment methods, purchases, enrollments, waivers, and communication history to the wrong person. Never use a live account as a practice record. Never reverse a questionable merge by merging in the opposite direction.

#Choose the correct action

#Where the controls appear

For a primary family or account record:

1. Open Families or Students.
2. Open the correct primary account.
3. Open Action.
4. Depending on account state and the signed-in staff member's permissions, the menu can show Merge Accounts, Archive, or Restore.

An active account shows Archive; an archived account shows an Archived badge and can show Restore. Archive asks, Archive this account and its children? Restore currently posts immediately without a second confirmation. Both actions reload the account after the request.

The action menu checks the current staff group's route permissions. The reviewed permission map relates these controls to Member > Merge Accounts, Member > Archive, and Member > Restore. A broad Member permission can also allow the related member routes.

Authorization caution: The reviewed tenant routes require an authenticated staff session, but the merge, archive, and restore routes do not currently include the normal route-permission middleware. The page hides controls according to permissions, but that UI check is not a complete server-side authorization boundary. Limit admin access to trusted staff, do not distribute direct action URLs, and have an owner review group permissions before using these tools.

#Before any archive, restore, or merge

#Confirm identity and authority

1. Confirm the request came from an authorized account owner or from the studio's documented operations process.
2. Verify the people using more than a matching name. Compare the account IDs, family relationships, non-sensitive contact details, registration history, and a known studio interaction.
3. Confirm whether the records represent:
   • the same household entered twice;
   • two people who share a name;
   • one adult with a legitimate separate student or staff record;
   • a historical account that must remain separate;
   • a child attached to the wrong parent; or
   • an Online Client login problem that does not require a merge.
4. Assign one staff member to make the change and a second person to review the inventory when finance, signed agreements, or saved payment methods are involved.
5. Record the reason, approver, date, survivor ID, source ID, and expected result outside the account's editable notes.

Never base a merge on a matching first and last name alone.

#Use the Duplicate Accounts report as a lead, not proof

Open Reports > Duplicate Accounts, then select Refresh. The current report:

• compares primary accounts only when the family-parent field is available;
• groups exact first-and-last-name matches after trimming spaces;
• includes active and archived account IDs;
• labels each result Active or Archived; and
• links to account pages when the staff role can open them.

It does not compare email, phone, address, students, login identity, balances, or dates of birth. It can miss duplicates with different spellings and can flag unrelated people who share a name.

#Create a dry-run inventory

There is no preview or dry-run button on the merge page. Build the inventory before opening the form. Use record IDs and counts rather than copying sensitive values into an ordinary ticket or spreadsheet.

For a merge, take a recoverable tenant database backup through the studio's approved backup process and confirm who can restore it. A downloaded report is not a database backup.

#Prepare a safe change window

• Ask the client not to sign in, register, check out, or edit the profile during the change.
• Pause staff edits to both accounts.
• Do not run tuition, scheduled payments, membership renewals, bulk messaging, or enrollment imports against the affected accounts during the window.
• Finish or explicitly abandon open Shopping Carts.
• Check the payment processor separately for unsettled or uncertain transactions.
• If any payment result is uncertain, stop before merging.

#Archive an account from the staff area

Use staff archive when the family should become inactive but its records should remain available for authorized historical review.

#Archive procedure

1. Open the primary account and confirm its account ID.
2. Review Family Members and Classes, Purchases, Ledger, Scheduled Payments, Cards and ACH, Waivers, Files, Messages, and Gift Cards as applicable.
3. Resolve future operational work. Archive does not itself cancel scheduled payments, charges, purchases, classes, or renewal chains.
4. Confirm whether the studio is configured to remove saved payment tokens when an account is archived. If this is uncertain, stop and ask product support before continuing.
5. Open Action > Archive.
6. Read the confirmation that the account and its children will be archived.
7. Select OK only once.
8. Wait for the page to reload. Do not repeat the action if the browser is slow.

#What staff archive changes

Current DSM Next source performs one database transaction that sets the selected account's status to inactive and also sets every direct child whose parent ID equals that account ID to inactive.

It does not reassign, cancel, or delete the family's:

• classes, enrollments, attendance, or schedule rows;
• purchases, orders, charges, payments, allocations, gift cards, or balances;
• scheduled charges, scheduled payments, holds, or recurring instructions;
• signed waivers, agreements, files, photos, messages, calls, categories, polls, or notes; or
• username, email, or password.

New Online Client sign-in requires an active account, so an archived account will not pass the ordinary new-login lookup. However, the reviewed staff archive path does not clear the client's existing session or scoped session cookie, and the client-session middleware does not recheck account status on every request. Treat session invalidation as unresolved: have the client sign out before the change and escalate if immediate access termination is required.

#Saved payment method cleanup

The archive controller checks a server environment value named DELETE_TOKEN_ON_ACCOUNT_ARCHIVE. When enabled, it deletes token rows owned by the selected account ID. It does not target token rows owned by child IDs. The inspected path does not call a payment-gateway deletion adapter.

Token cleanup errors are caught and logged while the account archive can still commit successfully. Therefore, an archived badge does not prove token cleanup occurred, and a missing token cannot be restored by selecting Restore.

Important: The reviewed controller reads the server environment value directly. It does not read the tenant's visible Payment Systems setting through the normal settings service in this path. Verify the effective deployment configuration rather than assuming the displayed setting controls the action.

#Confirm archive worked

1. Confirm the primary account shows the Archived badge and Restore action.
2. Inspect each direct family member and confirm its intended state.
3. Search the active and archived people lists.
4. Confirm no class, purchase, ledger, scheduled-payment, or agreement row was unexpectedly removed.
5. Check Cards and ACH and the processor according to the studio's token-retention policy.
6. Check future scheduled payments, charges, renewals, and messages separately. Stop or revise them through their own approved procedures.
7. Record the result and exceptions in the studio's change record.

#Restore a staff-archived account

Restore is a status operation, not a general undo.

#Before restoring

1. Confirm why the account was archived.
2. Review whether another active account now uses the same username or email.
3. Check whether related people were deliberately archived independently.
4. Review saved methods, scheduled payments, memberships, categories, enrollments, and future schedules before making the family active.
5. Determine whether the account was archived by staff or changed through Online Client Delete My Account. If it was deleted by the client, use the separate recovery review below.

#Restore procedure

1. Open the archived primary account.
2. Verify its ID and the intended state of every direct child.
3. Open Action > Restore.
4. Because there is no second confirmation in the current action, select it only when the review is complete.
5. Wait for the page to reload.
6. Confirm the Archived badge is gone.

Current restore sets the selected account to active and also activates every direct child under it. It does not preserve a child's independently archived state. Record those intended exceptions before restoring, then review every child afterward.

#What restore does not undo

Restore does not:

• recreate a saved card or ACH token deleted during archive;
• restore processor-side customer or payment-method state;
• restore a username or email changed by Online Client account deletion;
• return a member-schedule row from status 6 to its earlier status;
• rebuild purchases, categories, files, or other records that were manually changed while the account was archived;
• reverse a merge; or
• synchronize an external mailing list in the inspected path.

After restore, verify a new sign-in in a private browser window only after resolving duplicate identity values. Do not request, expose, or record the client's password.

#Understand Online Client account deletion

The signed-in client's Edit Account > Delete My Account control is not the staff archive action.

Current source performs these changes inside a database transaction:

1. sets the primary account and its direct children to inactive;
2. adds a _DELETED_ timestamp suffix to the primary account's existing username and primary email;
3. changes only the primary account's member-schedule rows with status 0 to status 6;
4. clears the current client session and expires the scoped client cookie; and
5. redirects to the Online Client home page.

It does not hard-delete the account, family, ledger, purchases, files, waivers, messages, or payment tokens. The schedule update is limited to rows owned by the primary account ID; it does not perform the same update for each child.

The schedule-status step is best-effort in the reviewed controller: a table or column error is caught and logged while the other account-deletion changes can still commit. Reconcile the actual schedules instead of treating the success message as proof that every row changed.

Warning: Staff Restore after this action only reactivates account statuses. It does not remove the _DELETED_ suffix or restore schedule states. Do not promise a one-select recovery. Inventory the login identity and affected schedules, obtain authorization, and use an approved recovery process with product support.

The Online Client can also archive an individual related student when the studio permits related-student management. That path sets the selected related person's status inactive. If the studio requires at least one active student, it blocks removal of the last qualifying student. It does not merge or erase that person's historical records.

#Merge duplicate accounts

#Understand the direction

The account open in the browser is the destination or survivor. The numeric ID entered in Account to merge (ID) is the source. Data moves from the entered source ID toward the open account ID.

Use this sentence before submitting:

Keep account [survivor ID] and move approved records from account [source ID] into it.

If that sentence is wrong, select Cancel.

#Choose the survivor

Prefer the account whose identity and history should remain the permanent client-facing record. Consider:

• the valid Online Client username and email;
• the correct family structure;
• current classes and schedules;
• signed agreements and records that must remain attributable;
• the processor customer context and preferred saved method;
• active membership/category dates;
• accurate registration and referral history; and
• the account ID used by current integrations.

The software does not score these factors or suggest a survivor. A lower account ID is not automatically the correct choice, even though the Duplicate Accounts report labels the minimum ID as its primary ID.

The merge service confirms that both IDs exist, but it does not require either record to be active, require both to be primary accounts, require them to share a family, or reject a staff/client role mismatch. The ordinary Action menu reduces some accidental combinations; the server-side merge logic does not make those combinations safe. Stop if the survivor/source types do not match the approved plan.

#Review the merge controls

Open the survivor account, then select Action > Merge Accounts. The page asks for the source ID and shows these controls:

Current checkbox limitation: The controller treats an omitted value for each of the five default-selected merge groups as true. An ordinary unchecked HTML checkbox is omitted from the request. Therefore, clearing Merge message and call history, Merge categories, Merge signed waivers, Merge classes/enrollments, or Merge financial info may still leave that group enabled. Do not use the current form when a selective merge depends on one of those groups remaining untouched. Escalate for a reviewed data plan instead.

#Safest supported procedure

1. Complete and approve the dry-run inventory.
2. Confirm a recoverable tenant backup exists.
3. Close payment, tuition, renewal, messaging, and enrollment activity for the affected accounts.
4. Open the survivor account and read its ID from the account page.
5. Select Action > Merge Accounts.
6. Enter the source account ID. The form does not search by name and does not show a source preview.
7. Confirm the direction sentence aloud or with the second reviewer.
8. For a primary source, decide whether all direct children should move.
9. Do not proceed with a child-source merge as routine cleanup. Its behavior moves several student-owned histories into the destination while leaving the child record itself in place unless separately reparented or archived.
10. Leave the five default-selected data groups selected unless product support has provided a verified alternative workflow. Clearing them is not a reliable exclusion in the reviewed build.
11. Select Archive the merged account after completion only when the source should become inactive. If moving a primary source's children is cleared, do not combine this with source archive until the active children under that archived parent have an approved disposition.
12. Select Merge Accounts once.
13. Wait for the success or error result. Do not refresh, use Back and submit again, or begin a reverse merge.
14. Start the post-merge reconciliation before reopening either account to routine work.

#What a primary-account merge moves

The following table describes the reviewed service when the entered source has no parent account.

The implementation uses simple ownership updates. It does not create a combined copy of each row or keep a customer-facing merge journal.

#What a child-account merge moves

When the entered source has a parent ID, the service uses a different branch:

• Move child account can reparent the source child under the destination account.
• Message and call history can be reassigned from the source child to the destination ID.
• Signed waivers and signatures can be reassigned to the destination ID.
• Class enrollment, schedule, assigned-purchase, and routine rows can be reassigned to the destination ID.
• Only the student reference on supported charges and purchases is changed for the financial group. Account-owned payments, scheduled payments, tokens, orders, and similar primary-account rows are not moved by this child branch.
• Categories are not moved by the child branch.
• The child's profile fields are not copied into the destination.
• The source child record remains unless it is separately reparented and/or archived.

This means a child can remain as a person record while its selected enrollment, waiver, and history rows are reassigned to the destination. Use a controlled support-assisted correction rather than treating this as an ordinary family transfer.

#Data not covered by the reviewed merge service

The following areas are not explicitly migrated by the current service and require separate review:

• files whose stored path or filename is associated with the source member ID;
• profile photos and external Drive folder identifiers;
• pending account agreements and member-agreement rows outside signed-waiver tables;
• gift-card buyer/recipient ownership and gift-card payment records;
• vouchers;
• polls, question answers, prerequisites, measurements, and push subscriptions;
• general note-table rows, scheduled messages, alerts, and support tickets;
• custom profile fields, confirmation state, staff/instructor/payroll relationships, and login-group details;
• external mailing, payment-processor, storage, or integration records; and
• a durable current merge audit record.

Some related records can continue to work because their unchanged IDs still point to a moved charge, payment, message, or purchase. That is not proof that every dependent table or external system was reconciled.

#Transaction, conflict, and repeat behavior

The current merge service begins a transaction on the tenant database and rolls it back when a database update throws an exception. This reduces the risk of a half-committed series of successful SQL updates after an explicit database error.

It does not make the workflow fully atomic across external systems, because no external processor, file store, mailing system, or gateway operation is included in that transaction. It also silently skips a requested relationship when the expected table or ownership column is not found. A skipped table does not make the merge return an error.

There is no preflight duplicate check for destination categories, enrollments, signatures, or tokens. A unique-key conflict can cause the database transaction to fail. Conversely, schemas without a unique constraint can accept duplicate rows that require later reconciliation.

The action is not guaranteed idempotent:

• there is no idempotency key or merge-run record;
• the source row remains and can be submitted again;
• a second run can encounter a different database state;
• previously missing tables or columns could make a later run move additional data; and
• a browser timeout does not prove whether the first request committed.

If the result is uncertain, do not submit again. Preserve both account IDs, the time, the displayed response, and the pre-merge inventory, then ask support to inspect the database transaction result.

#Reconcile after a merge

Keep the maintenance window closed until every applicable check is complete.

#Identity and family

1. Confirm the survivor ID and active state.
2. Confirm the source is active or archived exactly as approved.
3. Compare the survivor's name, contact fields, username, primary email, and confirmation state with the approved identity plan.
4. Confirm every related person's ID, parent ID, active state, and relationship.
5. Search both active and archived lists.
6. Refresh Reports > Duplicate Accounts. Remember that a renamed or still-active source can affect the result.

If the survivor email was blank, the merge can copy the source email while leaving the same email on the source. Username and password are never copied by the merge service. If the source remains active, two active rows can therefore still share a login value, and the login lookup is not a merge conflict resolver. Archive the approved source only after confirming its unsupported records and access consequences.

#Classes, schedules, and purchases

1. Compare enrollment and member-schedule row counts with the inventory.
2. Check active, waiting, eligible, cancelled, completed, and historical states separately.
3. Confirm attendance and routine relationships remain attached to the intended student.
4. Confirm assigned purchases still connect to the correct schedule and student.
5. Review every purchase's owner, assigned student, status, remaining units, activation, expiration, and auto-renew linkage.
6. Check for duplicate enrollments or entitlements before the next class, tuition run, or renewal.

#Finance and payment methods

1. Reconcile the survivor's charge total, payment total, allocations, balance, credit, and unapplied amount to the pre-merge combined inventory.
2. Open representative moved charges and payments by ID and confirm their allocations still agree.
3. Review purchases and orders separately from the ledger.
4. Review every future scheduled charge, scheduled payment, hold, recurring row, and renewal chain.
5. Inspect Cards and ACH using masked details only. Resolve duplicate/default/autopay selection under the studio's payment policy.
6. Compare the processor's customer and transaction records without initiating a charge, refund, or token change.
7. Do not rely only on cached account totals; the merge service does not explicitly recalculate cached balance or lessons-remaining fields.

#Agreements, files, communication, and categories

1. Confirm signed waivers and signature evidence appear under the intended person.
2. Check pending agreements and emailed requests separately.
3. Open the source account's Files and photo locations; these are not moved by the merge service.
4. Compare message and call-history counts, then check any scheduled message or delivery issue separately.
5. Review every moved category's status and date range, plus discounts and access that depend on it.
6. Check gift cards, vouchers, polls, answers, prerequisites, measurements, notes, custom fields, referrals, and external integrations individually.
7. Store the completed inventory, approver, result, exceptions, and support reference in the studio's protected operations record. Do not depend on the account note as the only audit trail.

#Troubleshooting

#The action is missing

Confirm you opened a primary account, not only a related-student detail. Review the staff group's Member permissions and whether the account is active or archived. Archive and Restore are state-dependent. Do not work around a missing control with a copied URL.

#Merge says one account was not selected

Confirm the source ID is a positive numeric ID and both account records still exist in the current studio. The form does not search by name. Do not substitute a similar account ID.

#Merge rejects the same account

The survivor and source IDs must differ. Return to the inventory; do not create a new duplicate just to continue.

#Merge returned an error

Record the complete on-screen error without personal or payment data. A missing account, missing member table/ID column, ownership conflict, unique-key conflict, or another database error can stop the operation. The reviewed service rolls back on a thrown database error, but verify both accounts and every inventory count before assuming nothing changed.

#Merge reported success, but a record stayed on the source

Check the supported-data tables above. Files, pending agreements, gift cards, polls, prerequisites, measurements, custom fields, notes-table rows, and several integrations are outside the service. A requested table or ownership column can also be silently skipped when unavailable. Do not rerun the merge just for one unsupported record.

#I cleared a merge option, but those rows moved

This matches the current default-true checkbox limitation. Stop reconciliation, preserve the before/after inventory, and contact support. Do not merge the records back in the opposite direction.

#The source is still active

Archive the merged account after completion is cleared by default. First reconcile unsupported records, family members, login identity, files, and external systems. Then use the approved source-archive plan. Do not rerun the merge merely to change its status.

#The source was archived but its children are still active

The merge's Archive the merged account option archives only the source row. If Move children was cleared, its children can remain active under the archived source. Stop and review each relationship; do not use blanket restore/archive actions until the intended family structure is documented.

#Restoring the family activated a child that should stay archived

Current primary restore activates every direct child. Review and archive the specific child again only after confirming that its independent inactive state is intentional and that no future workflow will be disrupted.

#The restored client cannot sign in

Determine whether the account was changed by Online Client Delete My Account. Staff restore does not remove the _DELETED_ suffix from username/email and does not restore an earlier password or confirmation state. Resolve duplicate identity, then use an approved credential-recovery process.

#The account is archived, but the client still has access

The current staff archive does not invalidate an existing Online Client session. Ask the client to sign out and escalate when immediate revocation is required. Do not assume a password change or archived badge invalidated an already issued session unless that behavior has been verified for the deployed build.

#A saved payment method disappeared or did not disappear

Review the effective server archive-token configuration, the token owner ID, the local Cards and ACH list, and the processor. Token cleanup can be enabled for the selected account, can skip child-owned tokens, and can fail while archive still succeeds. Restore does not recreate a deleted token.

#Account totals or lessons remaining look wrong

Reconcile underlying charge, payment, allocation, purchase, schedule, and usage rows by ID. The merge does not explicitly recalculate cached balance or remaining-lesson fields. Stop future tuition, payment, or renewal work until support confirms the source of the displayed total.

#Files are still under the archived source

This is expected from the reviewed file-storage and merge paths. File ownership is associated with the source member ID in the stored path or filename, and merge does not rename it. Use an approved file-transfer procedure; do not download and re-upload sensitive documents merely to make the tab look complete.

#Related articles

• Record calls and manage client follow-up
• Configure, collect, and reconcile Referral Sources
• Families and students
• Add a family or student
• Edit account and family details
• Manage class routines
• Roles and permissions
• Account ledger
• Scheduled payments and scheduled charges
• Cards and ACH
• Review purchases
• Pages, agreements, waivers, and contracts
• Client follow-up and retention reports
• Manage your account and family