41 lines
2.9 KiB
Markdown
41 lines
2.9 KiB
Markdown
---
|
|
name: Syncro — confirm appointment owner explicitly when creating tickets with appointments
|
|
description: When creating Syncro tickets that include an appointment, always ask "who is the appointment owner?" before posting. Don't auto-default to the ticket's assigned tech, and distinguish owner from additional attendees.
|
|
type: feedback
|
|
---
|
|
|
|
**Rule:** When creating a Syncro ticket that includes an appointment (Onsite, Remote, Phone Call, etc.), explicitly **ask the user who the appointment owner is** in the preview phase. Do not assume the appointment owner equals the ticket's assigned tech, and do not silently add other techs as attendees.
|
|
|
|
**Why:** The appointment owner is the person whose calendar the appointment lands on as the primary entry — they are the one accountable for being there. Additional `user_ids` in the appointment payload only add the entry to other techs' calendars as secondary/visible items, which clutters their schedule and creates ambiguity about who is actually on the hook for the visit. Howard caught this on 2026-05-08 after a ticket creation where I added the assigned tech to `user_ids` without confirming whether they should be the owner versus an attendee.
|
|
|
|
**How to apply:**
|
|
|
|
In the ticket creation preview (Step 3 of the ticket creation workflow), present the appointment block with the OWNER as a separate, explicit field — not buried as an inferred default. Example preview format:
|
|
|
|
```
|
|
APPOINTMENT
|
|
-----------
|
|
Type: Onsite
|
|
Owner: <ASK USER — who's calendar should this be on?>
|
|
Additional attendees: (optional, leave blank unless explicitly added)
|
|
Start: <start_at>
|
|
End: <end_at>
|
|
Location: <blank or override>
|
|
```
|
|
|
|
In the API payload, the appointment owner is the FIRST or PRIMARY entry in `user_ids`. Confirm:
|
|
|
|
- The owner is the person actually attending the appointment (or the lead tech if multiple).
|
|
- If the user wants ONLY the owner with no co-attendees, `user_ids` should contain ONE id only.
|
|
- If the user wants additional attendees (e.g., "Mike will join remote, Howard onsite"), add them only after explicit confirmation in the preview.
|
|
|
|
**What NOT to do:**
|
|
|
|
- Do NOT auto-add the ticket's `user_id` (assigned tech) as the appointment owner without asking.
|
|
- Do NOT add additional attendees to `user_ids` without explicit user direction.
|
|
- Do NOT treat appointment owner as a passive inheritance from the ticket — surface it as an active confirmation field in the preview.
|
|
|
|
**Trigger context:**
|
|
|
|
Howard created the Kittle Design ticket (#32263) on 2026-05-08 for an 11:30 AM onsite to set up Joshua. I auto-added Howard's `user_id` to the appointment's `user_ids` array without confirming whether Howard was the owner or just an attendee. Howard flagged: "when setting up an appointment confirm the appointment owner — don't just add additional attendees." Save as a rule for syncro ticket creation.
|