When something changed and nobody did it
Why the system did that, on one ticket
A ticket came in and a tech was already on it. Nobody picked them, and nobody claimed it off a queue. This guide follows that one assignment all the way back on a single record: the setting an admin chose on the client, the rule that setting drives, the change the rule made, the line in the ticket's own history that names what acted, and the assistant reading that same line back in one sentence.
What you will have
- A client whose tickets land on one named tech, with nobody sorting a queue to make it happen.
- The rule behind that setting, open on screen, with its trigger, its condition and its action.
- A ticket whose history names the setting that assigned it, in words, beside the change it made.
- A way to answer "why did this happen" on any record without asking the person who was on shift, either by reading the record or by asking the assistant in plain words.
Why it works this way
The setting is not a flag in a config table that only one piece of code reads. Every behaviour that acts on its own has a row in the same list, whether a setting drives it or you wrote it yourself, so there is one place to look instead of several.
The rule holds the trigger, not the answer. It says a ticket was created; the tech's name is read from the client at the moment the ticket lands. That is why a thousand clients with a dedicated tech do not mean a thousand rules to maintain.
The history row is named by what acted, not by who was signed in. When a setting made the change, the row carries the setting's name instead of a person's, so nobody has to work out whether a human or the platform moved the record.
The assistant is the last rung, not a separate story. She answers by quoting the reason the record already carries, so she names the setting the history row names and nothing more. This is worth testing on whatever you run today. Take one value on one record that nobody typed, and ask the record what set it. Either the answer is on the record, or it lives in somebody's memory.
Steps
Open the client, click Edit, then Settings, and find Default Ticket Assignee.
This is the setting the rest of the guide follows. Its own note on screen says what it does: every new ticket for this client, whether emailed in, created from the admin UI, or submitted by the client portal, is locked to this person ahead of every other assignment mechanism. Right now it reads "None (use board notification rules)", so nothing is set and new tickets go through ordinary dispatch.
Open the client, click Edit, then Settings, and find Default Ticket Assignee. Pick the tech, then click Save Changes.
The field now names one person. Save Changes sits at the top of the form, not at the bottom of the page. Reload the page afterwards and the field still names them, which is the only proof worth having that a save landed.
Pick the tech, then click Save Changes. Open Automations, then Library, and look in the SYSTEM group.
A rule called "Dedicated tech assignment" is sitting there, tagged Setting, triggered by Ticket Created, and Live. Nobody wrote it by hand. The rows above and below it are the same shape: auto-close, reactivate on client reply, recurring tickets, each one tagged Setting because a setting somewhere drives it. The tag is a link to the page that controls the rule.
Open Automations, then Library, and look in the SYSTEM group. Click the rule and read the line under its name.
It says: "Generated from Clients and controlled there. Edited there, not here." Clients is a link. The setting and the rule are not two records somebody has to keep in step; the setting is the control, and this page is the read-only view of what it produced.
Click the rule and read the line under its name. Read the rule itself.
WHEN a ticket is created. IF the new ticket has a client. THEN assign the client's dedicated tech. The rule names the trigger and nothing else, because the tech's name is read from the client at the moment a ticket lands rather than copied in here.
Read the rule itself. Read Governance on the same page.
Mode is Auto, so the rule acts rather than watches. Enabled is Enabled. Scope is All clients, because one rule covers every client instead of one rule for each. Event is Ticket Created, which is the only thing this rule needs to know.
Read Governance on the same page. Create a ticket for that client the ordinary way.
Contact, subject, priority, board, description. Read the form again before you click Create Ticket. Nothing on it asks who should work the ticket.
Create a ticket for that client the ordinary way. The ticket opens with a tech already on it.
Assigned To reads the person named on the client in step 2. Nobody chose them on this screen and nobody claimed the ticket off a queue. Reload the page and it still reads the same.
The ticket opens with a tech already on it. The thread says it out loud.
A line above the first message reads "Ticket assigned to jordan.reyes" with the time. That is what the tech sees without opening anything else.
The thread says it out loud. Open History in the right column of the ticket.
The newest row is named by what acted, not by who was signed in. It reads "Dedicated tech (Client default assignee)", with a system tag and the time. That is the setting from step 1, quoted on the record, minutes after it was saved.
Open History in the right column of the ticket. Click that row.
It opens the change itself: Assigned To, jordan.reyes. The reason and the change are one entry, so nobody has to line up two logs to see why a value is what it is.
Click that row. Go back to the rule and read Recent Decisions.
The newest row is the one you just caused: Ticket Created, Acted, minutes ago. The ticket says which setting acted on it. The rule says that it acted. One event, from both ends.
Go back to the rule and read Recent Decisions. Ask Elise the same question in plain words, on the ticket itself.
Open Ask Elise about this ticket and type: Why was this ticket assigned to jordan.reyes? The answer names the same thing the history row does: "The ticket was assigned to jordan.reyes via the "Dedicated tech (Client default assignee)" setting on the Summit Legal Group client record." Under it she gives the two supporting facts: "The system fired the assignment 102ms after ticket creation - no human picked a tech, no dispatch engine was involved", and "The TICKET_DEDICATED_TECH_ASSIGNED audit row cites that setting as the exact cause". Then she says where to change it: Summit Legal Group, Edit, the Default Ticket Assignee field. She is reading the reason the record already carries, the same one step 10 put on screen, rather than working it out from the order things happened. Ask it a different way and the answer names the same setting.
Ask Elise the same question in plain words, on the ticket itself.
The pages behind each click
Other ways to do this
Start from the rule instead of the record
Open Automations, then Library, pick an area in the left rail, and click any row tagged Setting. The line under the rule's name links to the page that controls it.
Change it back from the client
Open the client, click Edit, then Settings, and set Default Ticket Assignee back to "None (use board notification rules)". The field's own note says that leaving it unassigned lets the pod waterfall pick the tech instead. The rule itself is shared by every client and stays where it is; with the field empty it simply has nothing to do for that client.
If it did not work
- The ticket came in unassigned: check that the ticket's client is the client you set the field on, and that the field still names a person after a reload.
- The ticket already had a tech on it: the rule only fills an empty assignee, so a ticket that arrives with one is left alone.
- You cannot see History on the ticket: it is a collapsed panel in the right column, under Attachments. Click History to open it.
- The row names a person instead of a setting: then a person made that change, which is exactly what the row is telling you.
Questions this page answers
What does Default Ticket Assignee do?
It is on Edit > Settings for the client. Pick a tech there. Every new ticket for that client then locks to that tech right away. It skips the normal pod pick, but the ticket is still scheduled and tracked like any other. Picking a tech also keeps one shared automation rule current. It is called "Dedicated tech assignment", and you can read it under Automations. It is tagged Setting, with a note that it is generated from Clients and controlled there. When the rule fires, the ticket's own history shows a row for "Dedicated tech (Client default assignee)". Clear the field to stop the lock on that client's future tickets. The rule itself is shared by every client and stays in place. It just has nothing to do once the field is empty.
Was this helpful?