Adding and editing customers

Quick reference

• New customer: /customers/new — or the New customer button on the customer hub header, or the + New affordance inside repair / bespoke / sale forms when the customer doesn't exist yet (and the new-customer form returns you back to the in-flight job with the customer pre-selected on save).
• Edit existing: /customers/[id]/edit — or the Edit Profile button on the customer detail page (visible to operators with the edit_customer permission; hidden for staff without it, where the server action also blocks the update).
• The same form serves both modes — five cards: Personal details, Address, Jewellery preferences, Important dates, Tags. Every field is optional except the implicit name requirement (the row needs SOMETHING to render as).
• Email is unique per tenant. Saving a new customer with an email that already exists rejects the save and surfaces the existing row with a View existing customer link.
• Every save logs an entry in the audit log. The audit history for a single customer lives at /customers/[id]/history — every field-by-field change with the user who made it and the timestamp.
• Notes have moved off the customer form into the polymorphic notes timeline on the detail page's Notes tab. The form no longer has a notes textarea; the legacy plaintext column was migrated to the new timeline.

Walkthrough

1. Open the form

For a brand-new customer, click New customer on the /customers hub header, or navigate directly to /customers/new. To edit, open the customer's detail page and click Edit Profile at the top right — the same form renders, pre-filled with current values.

2. Fill personal details

First name, last name, email, mobile, landline phone. Email and phone are the workflow handles — repair-ready notifications, marketing campaigns, 1:1 emails, layby reminders all key off these. Mobile is the preferred number for any messaging surface (channel is configurable per tenant — automatic reminders dispatch via whichever notification channel your tenant has wired up); landline is the fallback for in-store calls.

Email is the only field that triggers a uniqueness check on save. Mobile and phone can be shared (couples who buy jointly, business accounts sharing a switchboard) — the system doesn't treat shared numbers as duplicates.

3. Fill address

Street, suburb, state, postcode, country. State is a dropdown limited to Australian states (NSW / VIC / QLD / WA / SA / TAS / ACT / NT) — for international customers, leave state blank and put the international subdivision (county, prefecture, region) in the street line if needed. Country defaults to Australia; the dropdown covers Australia / New Zealand / United Kingdom / United States / Canada — for anywhere else, the field isn't restrictive (overridable via the underlying schema if your tenant needs an extended list).

Address fields write encrypted into the pii_enc bundle on save; the plaintext columns are nulled. The detail page and the CSV export decrypt on read — staff see the values normally, the underlying row carries the encrypted bundle. (See the overview page for the threat-model rationale.)

4. Fill jewellery preferences

Ring size is a dropdown across the standard A–Z+ half-size ladder used in Australia / UK; preferred metal is a five-way dropdown (Yellow Gold / White Gold / Rose Gold / Platinum / Silver). Both surface on the detail page's hero card as pill chips, so staff helping the customer in-store see the preferences immediately without opening the edit form.

Wrist size, gold preference (e.g. “18ct” or “22ct” — separate from the colour-of-gold metal field), and allergies are also stored on the customer record and surface on the detail page hero card. The allergies field renders with a red warning chip on the detail page when populated — visible to every staff member who opens the customer, so a life-relevant constraint (e.g. nickel allergy) is impossible to miss when discussing a new piece.

5. Fill important dates

Birthday and anniversary are date pickers. Both are optional, both feed /reminders for the upcoming-this-month surface, and both are eligible triggers for the corresponding marketing automations. (Automation execution is partial today — see Anniversary, birthday, and reminders for the full picture of what fires automatically and what surfaces manually.)

Spouse name and spouse birthday — captured for the significant-other context that drives gift-purchase conversations. These also feed the upcoming-events surface on /reminders. The form keeps these together with the customer's own dates because the workflow that uses them (the “your wife's birthday is in two weeks, here are three pieces in her preferred metal” conversation) treats them as one unit.

6. Apply tags

Four canonical tags — VIP, Wholesale, Trade, Regular — live as chip buttons. Click a chip to toggle the tag. Beneath the chips is a custom-tags input that accepts a comma-separated list of free-form tags — Corporate, Bridal, Collector, an event name, a sales-rep name, whatever your tenant needs to segment by.

The VIP chip is special: selecting it ALSO writes is_vip = true to the customer row alongside adding the string to the tags array. This keeps the KPI strip, the list filter, and the segments page able to count VIP customers without scanning JSONB. The other three canonical tags and any custom tag live only in the tags array.

7. Save and resolve duplicates

Click Create Customer (new) or Save Changes (edit) at the bottom of the form. The form runs server-side validation (Zod schema) and submits via a server action.

On a new-customer save, if the email matches an existing customer in the same tenant, the save fails with an inline error message and a View existing customer → link that opens the existing record. The form preserves all the values the operator typed — nothing is lost on the rejection — so you can pivot the workflow into the existing record without re-typing. (The form lifts every field to React state for exactly this reason — older versions used uncontrolled defaults and dropped the typed data when the server returned a validation error.)

On a successful new-customer save, the form redirects to the detail page at /customers/[id] — unless the form was opened from inside another form (e.g. clicking + New from a repair intake), in which case it redirects back to that form with the new customer pre-selected. On edit, the form redirects back to the detail page.

8. Read the audit log

Every save — new or edit — writes a row to audit_logs with the action, the user who made it, the timestamp, and the full before/after diff. The per-customer audit history page lives at /customers/[id]/history — every recorded change on this customer, most recent first, with each field rendered as a structured diff. Useful for “who changed this customer's phone number?” and similarly for any disputed edit. (This is the audit-log surface; the customer's transactional history — purchases, repairs, bespoke — lives on the detail-page tabs walked through in Customer history.)

9. Archive

The Archive button on the customer detail page (top right, beside Edit Profile) soft-deletes the row. The customer drops off the active list, the KPI counts update, the search no longer surfaces them in the regular flow. The underlying record stays in the database — invoices, repairs, sales, and every other linked record keep their customer reference intact, so historical reports still resolve the customer name. Archive is owner / manager-only; the affordance is hidden for staff.

Opening an archived customer's detail URL renders a read-only archived interstitial with the archived-on date and a back-to-list link, instead of the full detail page. There's no in-app restore today — if you need an archived row restored, ask support and we'll un-archive it server-side.

Common questions

Troubleshooting