wiki/memory: Syncro contact rule is global, not Cascades-specific
Update cascades-tucson.md Syncro billing pattern to note the blank-contact rule applies to all customers. Update feedback_syncro_cascades_contact.md to be incident-detail only (Meredith Kuhn default), pointing to the global rule in feedback_syncro_blank_contact.md. Update MEMORY.md index entry. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -1,19 +1,13 @@
|
||||
---
|
||||
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.
|
||||
name: Syncro — Cascades contact incident detail (Meredith Kuhn)
|
||||
description: Incident context for why the blank-contact rule matters at Cascades — Meredith Kuhn is the recurring wrong default that Syncro pre-selects. See feedback_syncro_blank_contact.md for the global rule.
|
||||
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.
|
||||
At Cascades of Tucson (customer_id 20149445), Syncro repeatedly pre-selects **Meredith Kuhn** (Assistant Manager, ASSISTMAN-PC) as the ticket contact default. She is the wrong contact — setting her overrides the customer's distribution emails and routes notifications only to her.
|
||||
|
||||
**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.
|
||||
**Why it keeps happening:** Syncro's contact picker defaults to the first-alphabetical or most-recently-used contact. Howard surfaced this pattern; Mike confirmed the global rule on 2026-05-24 (do not set contact on ANY ticket unless explicitly requested).
|
||||
|
||||
**How to apply:**
|
||||
**Global rule:** See [[feedback_syncro_blank_contact]] — blank contact is the default for all customers, not just Cascades.
|
||||
|
||||
- **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.
|
||||
**Cascades-specific guard:** Even if you're tempted to assign a contact for routing purposes, Meredith Kuhn is specifically wrong. The correct routing happens automatically when contact is null.
|
||||
|
||||
Reference in New Issue
Block a user