Finlay.worksBareBones Ticketing manual

Ownership and Participants

A ticket names people in three internal roles — owner, watcher, and participant — and can be linked to other tickets by a named relationship. This page covers setting each of those. All of it happens in the ticket workbench.

Before you start

  • You need department Work access to the ticket.
  • To set an owner, the person you name must already have department Work access. Naming someone as owner does not give them that access.
  • To add a watcher or participant, the person must be an active internal user.
  • To link another ticket, you need department View access to that ticket.

The three internal roles

Role What it means What the person gets
Owner The one person accountable for the ticket. A ticket has one owner or none. Nothing new. The person must already have Work access in the department.
Watcher Labelled Watcher. A copied collaborator — the product describes watchers as the people copied on updates to the ticket. This one ticket becomes visible to them in the Requester portal.
Participant An internal collaborator working the ticket alongside the owner. This one ticket becomes visible to them in the Requester portal.

A watcher or participant link gives that named person sight of that one ticket and nothing else. It does not give them department membership, department View, Work, or Admin access, ownership, the Agent queue, workflow authority, project access, or any other ticket.

These roles are separate from project staffing. Someone staffed in a project role does not become this ticket's owner, watcher, or participant until a routing action applies that outcome or you add the role here by hand. See Projects.

External people are not added here. See External Participants.

Assign an owner

  1. In Internal actors, choose the Owner role.
  2. Search for the person and select them. The search returns at most 10 candidates.
  3. Check the label Assign owner and the name shown.
  4. Submit once.
  5. Confirm the person now appears as the single owner.

Assigning a new owner deactivates the previous owner link. Selecting the person who is already the owner does nothing — it is not a second assignment and does not create a duplicate.

Selecting the search box before you type anything lists up to 10 eligible people. Typing narrows it. It is a short list of candidates, not a full staff directory: you cannot page through everyone. The product checks the person again when you submit, so someone who stopped being eligible after you searched is refused at that point.

Clear the owner

  1. Find the Owner role tag for that person on the ticket.
  2. Use the remove control on that tag.
  3. Confirm the ticket now shows no owner.

Clearing the owner leaves the ticket unassigned. It does not remove watchers or participants.

The workbench has no separate clear-owner control. Removing the Owner role tag is the way to do it on one ticket. To clear the owner on several tickets at once, use Clear owner in Bulk Operations.

Add a watcher or participant

  1. In Internal actors, choose Watcher or Participant first, before choosing a person.
  2. Search for an active internal user and read the candidate label shown.
  3. Confirm Add watcher or Add participant.
  4. Submit once.
  5. Confirm the role tag appears on the ticket.

Adding a link that is already active for that person in that role does nothing. If the person previously held the role and it was removed, adding it again reactivates the same link.

Remove a watcher or participant

  1. Find the role tag for that person on the ticket.
  2. Use the remove control on that exact tag.
  3. Confirm that only the role you selected was removed.

Removing a watcher link does not remove a participant link for the same person, and the reverse is also true.

A relationship records how two tickets relate. It never grants access to either ticket.

  1. In the relationships section, choose the direction that describes this ticket's relationship to the other one.
  2. Type at least three characters of the other ticket's reference or title.
  3. Pick from the suggestions. The page requests up to six matches, and only tickets you can already see are returned.
  4. Select the target ticket.
  5. Confirm the relationship type and create it once.
  6. Check that both tickets now show the pair of directions.

Available directions, and the direction recorded on the other ticket:

Direction on this ticket Direction on the other ticket
Parent of Child of
Sub-task Part of
Blocks Blocked by
Depends on Required by
Related work Related work
Duplicates Duplicated by
Causes Caused by

Two things are refused. A ticket cannot be linked to itself. A second active relationship of the same type between the same two tickets is refused rather than added alongside the first. Different types can coexist: the same two tickets can carry both Blocks and Duplicates at once. Related work is the exception — it is also refused if the same pair already carries Related work in the other direction.

If a ticket is not visible to you, it does not appear in suggestions and no title, reference, placeholder, or count of hidden matches is shown in its place.

Clear a relationship

  1. Check the ticket, the target, and the direction shown.
  2. Use the clear control once.
  3. Confirm the relationship no longer appears on either ticket.

Clearing needs Work access to the current ticket and View access to both tickets. If the other ticket is no longer visible to you, clearing is refused.

If it does not work

  • The person you want as owner is not offered. They do not have department Work access. Ask the department administrator to review it. Do not add them as a watcher or participant instead — those roles do not carry accountability or department access.
  • You submitted and the result is unclear. Refresh the ticket and read the current owner, role tags, and relationships before submitting anything else.
  • A ticket you expect does not appear in relationship search. You do not have View access to it. Do not widen the search to work out whether it exists.
  • You expected an email. A role change may queue a notification depending on configuration. The role change itself is not proof that a message was sent or received.