Howard Enos
b6eb59e8ed
- Grabb & Durando: investigated and resolved Svetlana Larionova's Leap-to-M365 calendar OAuth consent issue (Graph-side report + session log). Syncro #32245. - Dataforth: lobby phone (ext 201) was offline due to D1-Server-Room port 1 being on the wrong VLAN; reconfigured to VLAN 100, phone re-provisioned and registered. Session log + PROJECT_STATE update. Syncro #32246. - Instrumental Music Center: Station 2 receipt printer reconnect + VPN install on Manda's machine. Syncro #32247. - Memory: generalized the Syncro blank-contact rule (was Cascades-only) and added the labor-type rule (never use "Prepaid project labor") per Winter's 2026-05-04 corrections. - Gitignored `.claude/tmp/` so per-session helper scripts don't sneak in. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.4 KiB
name, description, type
| name | description | type |
|---|---|---|
| Syncro — leave contact blank by default on tickets and billing | When creating Syncro tickets or billing them out, leave the contact field blank ("Not Assigned") in most cases. Blank contact lets Syncro use the company-level defaults for notifications and email routing. Setting a specific contact can route to a secondary email and bypass the customer's intended distribution. | feedback |
Rule: When creating or billing Syncro tickets, leave contact_id / contact_name / contact_email blank ("Not Assigned") by default for any customer. Only set a contact when there's an explicit, deliberate reason to (e.g., user explicitly says "set the contact to X").
Why: Winter clarified on 2026-05-04: blank contact lets Syncro apply the company-level email defaults for the account — those defaults route notifications to the right people. Setting a specific contact overrides that and may push notifications to a secondary email address belonging to that contact, bypassing the customer's intended distribution. This was originally flagged for Cascades of Tucson (where Meredith was being incorrectly auto-selected), but Winter generalized it: the rule applies to most customers.
How to apply:
- Creating a ticket (POST
/tickets): Omitcontact_idfrom the body entirely. Do not pull contacts viaGET /customers/{id}and pick one — let Syncro use the company defaults. - Editing a ticket (PUT
/tickets/{id}): Send only the fields you're changing (status,priority, etc.). Never includecontact_id,contact_name, orcontact_emailin the body, even matching the existing value. PUT can re-apply the record; safest is to never reference contact in any write payload. - Billing / invoices: Same rule on the invoice creation side. If
contact_idshows up in any payload, drop it. - When to set a contact anyway: Only if the user explicitly directs you to ("set Mike as the contact on this one") OR there's a documented per-customer instruction that overrides the default. Default is always blank.
- Verify after any write:
GET /tickets/{id}and confirm.ticket.contact_idisnull. If you find it set, blank it explicitly:PUT /tickets/{id}with{"contact_id": null}.
Generalizes from: the prior Cascades-specific guidance (originally feedback_syncro_cascades_contact.md). Winter's 2026-05-04 message broadened the scope from "Cascades only" to "most customers."