Tickets

A ticket (crm_tickets) is Landscapt's general-purpose customer-service record — a note, call, or event tied to a client that needs to be tracked, assigned, and resolved. Every ticket has a sequential ticket_number, a status, a priority, an optional category, and an optional client and assignee.

Tickets are shown as three different lists in the app — Tickets, Calls, and Events — but they're all the same underlying table and component (TicketsList), just filtered by type (note / call / event).

These are literal string enums, not free text — the UI only ever writes one of these.

The detail sheet's status flow indicator only shows three visual steps — Open, In Progress, Closed — because on_hold maps to the same step index as open. Under the hood it's still a distinct, filterable status.

Category is a free-form org-configured list (crm_list_options under key ticket_categories), not a hard-coded enum. If your org hasn't configured any, the New Ticket dialog and edit form fall back to a default set: Uncategorized, Estimate, Billing, Change Service, Complaint, Other.

Three ways a ticket comes into existence:

1. Staff, manually — the Add Ticket (or Add Call / Add Event, depending on which list you're on) button opens NewTicketDialog, letting staff set type, client, category, subject, body, status, priority, assignee, and due date directly.
2. A public form submission, automatically — every submission on a crm_forms form creates a ticket, no matter what else the form does or how it handles the matched/created client. The ticket always starts as status: "open", priority: "normal", type: "note", with category set to the form's own name and the body built from the submitter's name/email/phone/message plus every raw field on the form.
3. A Communication Automation Event action — the Ticket action step lets an automation sequence create a ticket with a configurable title, description, priority (Low/Normal/High/Urgent), and assignee whenever it runs.

Bulk creation is also available via CSV import (Actions menu → Import), which requires only a Subject column.

A ticket can be assigned to exactly one user at a time, via assigned_to (a display-name string) and assigned_to_id (a real crm_employees.id, resolved from the assignee-picker's selected employee). Both are set together whenever the UI's Assigned To dropdown is used — in the New Ticket dialog, the edit form, or the list's bulk Reassign action (select one or more rows → Actions → Reassign).

1. A visitor submits a contact form on your public site. submitFormResponse() matches or creates a client, then unconditionally inserts a crm_tickets row: open, normal priority, type note, category = the form's name, body = name/email/phone/ message plus every raw field.
2. notifyStaffOfNewTicket() runs immediately — it notifies the org's configured New Ticket recipients (no assignee yet, so no one else is added).
3. Because the ticket has a client, ticket_created fires for any Communication Automation sequence watching that trigger (optionally filtered to this form's category), and for any Zapier "New Ticket" trigger.
4. A manager opens the ticket from the Tickets list, clicks Reassign (or edits the ticket directly) and assigns it to a rep. This sets both assigned_to and assigned_to_id, and fires a ticket_assigned notification to that rep alone.
5. The rep works the ticket — adds comments (Comments & History tab, backed by CommentsSection), which notify the assignee if someone else comments, and sets status to Pending while they investigate.
6. The rep resolves it and clicks Close Ticket (useCloseTicket). This sets status: "closed" and closed_at, then fires ticket_closed for both internal automations and Zapier.
7. If the client later replies and staff change the status away from Closed, useUpdateTicket detects the prior status was closed and fires ticket_reopened.

Clicking any ticket row opens TicketDetailSheet, with five tabs:

• Details — status flow buttons, the client/category/assignee/dates meta grid, body text, and a Linked Records picker that can attach the ticket to an Estimate, Invoice, or Job belonging to the same client.
• Comments & History — threaded comments via the shared CommentsSection (recordType="ticket").
• Files — attachments via the shared AttachmentsSection.
• Contributors — additional staff CC'd on the ticket as participants, distinct from the single assignee. Managed by use-ticket-contributors.ts.
• Audit Trail — the shared AuditTrailTab change history.

The header also has a PDF button that opens a print-formatted view in a new window — all ticket fields are HTML-escaped before being written into that window, since subject/body/names can originate from an unsanitized public form submission.

client_id is nullable — a ticket doesn't strictly require a client — but whenever one is set at creation, useCreateTicket also inserts a matching client_activity row (activity_type: "ticket") so the ticket shows up on that client's unified Activity Timeline alongside notes, calls, invoices, and estimates.

A ticket created from a public form submission doesn't go through useCreateTicket — it's a direct server-side insert in submit-form-response.ts — but it logs the same shape of client_activity row (activity_type: "ticket", linked via ref_id/ref_table), so it shows up and deep-links on the timeline exactly like a manually-created ticket does.

A ticket can also carry an SMS-consent warning: if a form submission checked SMS consent but captured no phone number, sms_consent_pending_phone is set true and the detail sheet shows a dismissible amber banner until a phone number is collected and the warning is cleared.

When a crew spots work a property needs, they send it in from the crew app and it arrives here as an ordinary ticket with the category Upsell — so it inherits assignment, due dates, priority, comments, automations and the audit trail without being a separate thing to check.

The crew's side of this — where the Suggest work button lives and what they see — is in the Crew App guide. Each one carries the crew's note, who spotted it, the date, the property, and the service they suggested. Any photo they took is on the Files tab, which is usually enough to price the work without a trip out to look. The ticket is linked back to the job the crew was on.

To take one forward, click Create estimate on the ticket. That makes a draft estimate for the client, puts the suggested service on it at your catalog rate, links the two together and opens the estimate ready to price — so there's nothing to retype and nothing to remember to link afterwards. The button needs the Add Estimate permission, the same one every other way of creating an estimate requires, and it disappears once the ticket has been converted.

Re-quoting is still fine. You can link additional estimates by hand from Linked Records — useful if you quoted the work before the suggestion came in, or the client asked for a revised price. The reports read the most recent estimate linked to the ticket.

That link is what turns the suggestion into a number you can report on: the estimate carries the real sales pipeline (Sent → Accepted → Won/Lost), so a crew's suggestion reaching Won is measurable, while the ticket's own open/closed only ever means whether the office has dealt with it.

Two reports in the Report Center read this: Field Upsells lists every suggestion with its outcome, and Upsell Conversion by Crew Member totals what each person submitted against the revenue it won. Both are under the Service section, and each has its own permission so you can decide who sees them.

Communication Automations can trigger on four ticket events:

The same events are exposed to Zapier as instant triggers — New Ticket and Ticket Closed — and Zapier can also create tickets via the Create Ticket action (requires Client + Subject; accepts Body, Priority, Category, Type, and Due Date). See the Zapier guide for the full trigger/action reference.

Three notification preferences exist per user, each with separate email and in-app toggles: