Files
claudetools/.claude/memory/feedback_syncro_cascades_contact.md
Howard Enos 4f4491e7da sync: auto-sync from HOWARD-HOME at 2026-05-01 10:44:36
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-05-01 10:44:36
2026-05-01 10:44:39 -07:00

2.1 KiB

name, description, type
name description type
Syncro — never set contact on Cascades tickets 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. 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.