Guide
Customer Records and Access
Use customer search, imports, purchases, serials, devices, and access actions without conflating them.
Start with the customer context
Customer records are developer-scoped. Search/filter by the supported fields and date range, then review purchases, owned products, serials, activation devices, and verification state. Marketing permission is a separate property, not implied by the record existing.
SoundSync
Actions have different effects
| Action | Meaning |
|---|---|
| Edit customer | Correct supported profile fields in your workspace |
| Resend verification | Send the supported ownership/account verification message |
| CSV import/export | Move permitted developer-scoped records using the supplied format |
| Deactivate a device | Release that activation, not the customer's entire purchase |
| Hide/show portal order | Change supported customer-portal presentation, not necessarily entitlement |
| Remove access | A deliberate access operation on the selected purchase item; not a refund |
| Invoice PDF | View the relevant authorized order invoice |
| Delete customer | A separate sensitive action; review linked records and retention obligations first |
Take care with ownership changes
A serial assigned to another customer cannot be claimed merely by knowing its text. Follow owner proof, verification, and the supported account path. Correcting an email address is not permission to transfer all product ownership.
For refund, dispute, or account-closure requests, follow the policy and support procedure. Never publish raw customer tables, last names, email addresses, serials, or tokens in public screenshots.
Support activity and deliberate grants
Permissioned customer tools also expose activity, plugin-connection events, and internal notes. Supported recovery actions can resend library/activation mail or reset activations. These are not a replacement for customer identity verification.
Manual product grants and suspend/restore/revoke operations require the relevant entitlement permissions and product scope. A grant of access is not authorization to start recurring billing. Keep the action, reason, and customer communication explicit.
Purchase refunds and documents
The Purchases table supports order references, filters, item detail, authorized invoice PDFs, exports, and permissioned refund previews. Refund an eligible full order or whole selected products within the initial 14-day window; do not substitute Remove Access for a payment refund. Review cumulative refunded items, payment state, original tax/fee amounts, and any recipient allocations.
A pending or needs-review refund is not complete. Use its operation reference and the current purchase state for support. Billing and finance summaries can lag the provider event until reconciliation; do not send the same refund again merely because one table has not refreshed.
Customer activation resets, when enabled
Developers can allow customer self-service resets for supported serial and entitlement licenses, with a configured cooldown. Only the signed-in owner of the license can request a reset. The confirmation clears the affected device activations and sessions together while preserving the license and product ownership.
A reset is not a refund, a new serial, or unlimited extra devices. Customers must reload the current state and wait for the next eligible reset when a cooldown applies.
Correct the identity without rewriting history
First and last names can be updated or cleared independently. Supported email changes synchronize account/contact records and queued marketing, with billing-provider synchronization retried where needed. They do not rewrite issued invoices or already sent messages, and they do not undo opt-outs.
A normal customer edit is not proof of email verification. Use the verification resend action for the current identity. Last Login reports actual recorded sign-in activity, not the last time a developer edited the customer.