What the page does
Customers (/customers) is the management surface for the customers your team communicates with. FixControl is not a CRM — this page exists so governed customer communication has a real recipient to land on, with an auditable trail.
- The list shows every customer with a status facet (Active / Archived / All), text search, and the number of contacts per customer.
- The detail page lets you rename a customer, archive and reactivate them, and manage contacts. The governed communication trail for the customer — each message with its status — is shown on the same page.
Contacts
A contact's e-mail address is the primary identifier. Addresses are normalised and unique per tenant, so the same address can never belong to two contacts. Editing a contact overwrites its fields deliberately (this is the human management surface); archiving a contact removes them from recipient resolution.
Changing a contact's e-mail address has one important side effect: any pending communication approval that was requested for the old address is automatically invalidated. See below.
Governed customer communication
Every outbound customer e-mail or reply drafted in FixControl is staged as a communication approval before anything leaves the building. AI-drafted free text always requires a human decision; a narrow auto-send path exists only for pre-approved templates when an admin has explicitly raised the autonomy setting — it is off by default.
The guarantees on that approval:
- Four-eyes — the person who requested the send can never approve their own message. A second person decides.
- Frozen content — the approval is bound to a hash over the exact recipient, subject, and body at request time. Editing the message afterwards, or changing the contact's e-mail address, invalidates the pending approval; the content has to be re-staged and re-approved. An approval always covers exactly what the approver saw.
- One decision point — approving happens in the Approvals UI or on the Slack approval card (which requires an elevated, linked Slack identity). Both land on the same decision chokepoint; there is no second path.
- Honest sending — an approved message is sent through the configured mail provider (Settings → email: SMTP or Resend). Without a configured provider the send fails with status
failedand a visible reason — never a fake "sent".
Every step — draft, policy evaluation, approval request, decision, send or failure — is audited.
Creating customers
Customers can be created from three places, all through the same underlying flow:
- The UI —
/customers→ create, then add contacts on the detail page. - Slack — the
/fixcontrol customer createslash command (name, optional contact and e-mail). - Chat — when you ask chat to send an answer to a customer address that is not known yet, the customer and contact are created as part of staging the reply for approval. Asking Slack or Teams to link a customer to a ticket ("link customer info@acme.com to FIX-12") does the same after your confirm click: if the customer does not exist yet it is created together with the contact and linked to the issue. This works on issues without a tracker link too.
Duplicate control applies everywhere: a customer with the same normalised name, or a contact with the same e-mail address, is reported as a duplicate — never silently merged. When linking from chat, an existing customer name means the new contact is attached to that existing customer.
FAQ
Can I approve a message from the customer detail page? No. Deciding deliberately lives in the Approvals UI and the Slack approval card only — the customer page shows the trail, not the decision buttons.
What happens when I archive a customer? The record and its history stay; the customer drops out of the active list. Reactivate any time from the detail page.