---
name: Syncro — never set contact on Cascades tickets
description: When creating or editing Syncro tickets for Cascades of Tucson, do NOT set the contact field. Leave it blank. Syncro defaults blank-contact tickets to the correct distribution emails; setting a specific contact (e.g. Meredith) overrides that and breaks notifications.
type: feedback
---

When creating or editing Syncro tickets for **Cascades of Tucson** (customer_id 20149445), the `contact_id` / `contact_name` / `contact_email` fields MUST be left blank/untouched.

**Why:** Cascades has a default email distribution behavior on tickets with no contact set — Syncro routes ticket notifications to the correct group of email accounts when contact is null. If contact is set to a specific person (Meredith Kuhn has been the recurring incorrect default), notifications go to that one person only and the rest of the distribution is bypassed. This breaks the customer's expected ticket-notification flow.

**How to apply:**

- **Creating a Cascades ticket:** Omit `contact_id` from the POST body entirely. Do not pull contacts via `GET /customers/{id}` and pick one. Let Syncro handle it.
- **Editing a Cascades ticket via PUT:** Send only the fields you actually want to change (`status`, `priority`, etc.). Never include `contact_id`, `contact_name`, or `contact_email` in the body — even with a value matching the existing one. Some PUT semantics re-apply the whole record; the safest pattern is to never reference the contact field at all in PUT payloads.
- **Verifying after any write:** `GET /tickets/{id}` and confirm `.ticket.contact_id` is `null`. If you find it set, blank it explicitly: `PUT /tickets/{id}` with `{"contact_id": null}`.

**Open question:** This may apply to other customers too — Howard called it out specifically for Cascades. If a similar complaint surfaces about another customer, generalize the rule. For now, it is a Cascades-specific guard.

**Verified clean on 2026-05-01:** ticket #32214 contact_id was null after billing session (PUT bodies only included `status`). The risk is real on the next ticket-edit workflow if defaults aren't held.
