RepairShopr Ticket Workflows

Working RepairShopr as the system of record — finding tickets and customers, the entity-typed CRUD shape, comment visibility control, and seeding Leif tasks from tickets.

How to actually work RepairShopr (RS) day to day — find the right record, update it without surprises, and connect it to Leif’s task layer. RS is the system of record for tickets, customers, and invoices, so the discipline here is: read before you write, and know which comment goes to the customer.

The tool signatures live on repairshopr; this page is the workflow around them.

The entity-typed shape

Every RS tool takes an entity_type string plus the operation. The same six verbs (get, create, update, delete, comment, search) cover everything; you change entity_type (ticket, customer, invoice, …) rather than learning a new tool per object.

Finding the right record

Two paths, depending on whether you have an ID.

You know the ID → fetch directly:

repairshopr_get(entity_type="ticket", id=12345)

You don’t → search, then fetch:

repairshopr_search(query="Acme Corp", search_type="all")
# narrow search_type once you know the entity, e.g. to customers

search_type defaults to all; narrowing it speeds things up once you know what you’re after. For listing rather than searching, repairshopr_get without an id returns records of that type (with optional filters).

The ticket lifecycle

A ticket moves through statuses as work proceeds. To advance one, update its status field:

repairshopr_update(entity_type="ticket", id=12345,
                   data={"status": "<next status>"})

The exact status vocabulary is whatever the RS instance is configured with — read a live ticket (or the RS settings) to see the valid values rather than assuming them. data carries only the fields you’re changing.

Comments: mind who sees them

repairshopr_comment is the one tool with visibility nuance, and it matters — the wrong flags email a customer something internal.

repairshopr_comment(ticket_id=12345, comment="...",
                    hidden=False, do_not_email=False)
Goalhiddendo_not_email
Normal customer-visible update (default)FalseFalse
Internal note, no customer emailTrueTrue
Visible to customer but don’t email themFalseTrue

From ticket to Leif task

When a ticket needs tracked follow-up in Leif, seed a task straight from it rather than retyping:

create_task_from_ticket(ticket="<ticket ref>")

This bridges the RS system of record into the task layer — the task carries the ticket context, and link_repairshopr can associate existing tasks back to RS records.

How RS feeds the rest of the system

RS is upstream of the order pipeline, so changes here ripple:

A deletion or status change that downstream reads from is not a local action — confirm before deleting anything the sync consumes.