Assignment Rules

A ticket has at most one owner. Several configured sources can supply that owner, at different moments. This page lists every source, says when each one runs, and defines the department fallback rule that selects a project-role mapping set.

This page owns the department fallback rule. Other pages link here rather than restate it.

Before you start

• You need SystemAdmin access and step-up verification.
• Every person any source can select must be an active internal user with current Work or stronger access to the ticket's department. A user without that access is never selected, however the source is configured.
• Configuring a source changes nothing about tickets that already exist.

Where each source is configured

There is no single assignment administration page. Each source lives in the workspace that owns it.

The old Assignment Administration page is retired. It is not on Admin Settings and it changes nothing; reaching its route directly shows only a notice telling you to use the live workspaces above.

Set a fixed owner on a service

1. Open the service in Services.
2. Set Fixed owner for new tickets (optional) to one active person with Work or stronger access in the service's department.
3. Save once.
4. Create one test ticket for that service and confirm the owner.

The service fixed owner runs last at ticket creation. It fills the owner only if nothing earlier has set one. If the configured person is inactive or no longer eligible, no owner is set from this source and ticket creation continues.

Set a fixed owner on a transition

1. Open the workflow in Workflow Administration and open the move.
2. Choose Fixed owner routing (optional) and select an eligible person, or leave it empty.
3. Select Save workflow changes.

If a move has both a fixed owner and a contextual source configured, the fixed owner is used.

Assign to actor

Assign to actor is a follow-up step on a move, not an owner source. It makes the owner the person who ran the transition — not the person who raised the ticket. When a move has Assign to actor, the automatic owner routing on that move does not run.

Route an owner from a field value

A Select (Dropdown) intake field can carry an owner on each option. When the requester picks that option, the option's person is proposed as owner at ticket creation. Configure it with the field. See Custom fields and tags.

Project-role mappings

A project-role mapping turns a role on a project into an outcome on a ticket. Using one requires a chain of separate records, all of which must be present:

1. A service the ticket is raised against.
2. A project, and the ticket has one active association to it.
3. A project role named on that project.
4. A mapping — owned by a service or by a department — that gives that role key an outcome.
5. Project staffing that puts an eligible person in that role on that project.
6. A trigger that evaluates all of the above.

If any link is missing or ambiguous, the mapping produces no assignment and the work continues without one.

Create a mapping

1. Open Project Role Mappings and complete step-up verification.

2. Choose Add service mapping or Add department fallback.

3. Choose Create new and enter a role key and display name, or Apply existing to reuse an active definition.

4. Choose exactly one outcome:

   • Owner — the person in the role becomes the owner candidate.
   • Watcher — the person is added as a watcher.
   • Participant — the person is added as a participant.
   • No action — the row deliberately produces no outcome.

5. Select the services, or the departments, the row applies to.

6. Review the summary and save once.

Editing a row keeps its owner target. Clearing a row stops it affecting later routing. It does not remove project staffing and does not undo assignments already made.

Mapping definitions and project staffing are separate. Changing a mapping does not restaff projects. Changing who holds a role on a project does not edit a mapping.

The department fallback rule

When a trigger needs a mapping set, it selects one set — never a mixture.

If the ticket's service has at least one active mapping row, that service's rows are the set. Department rows are used only when the ticket has no service, or when its service has zero active rows.

The rule is all-or-nothing. One active service row is enough to make the service set complete and suppress every department row — including a row whose outcome is Watcher and a row whose outcome is No action.

Department fallback does not:

• fill an Owner outcome missing from a service set;
• replace a service role that is unstaffed or whose holder is ineligible;
• add Watchers or Participants a service set omits;
• resolve a project role that is staffed ambiguously; or
• override a service row whose outcome is No action.

If a service set is incomplete, you have two choices: complete the service set, or clear every active service row so the department set is selected. Leaving one placeholder row active while expecting department rows to supply the rest does not work.

A mapping row grants nobody access. It does not give project visibility, department access, Agent authority, or SystemAdmin. Customer Portal identities can never be staffed into a project role or selected by a mapping.

When each trigger runs

Saving configuration, staffing a project role, linking an existing ticket to a project, viewing a queue, or previewing a bulk operation assigns nobody.

Assignment at ticket creation

A project association must exist before project-linked routing can run. It comes from one of:

• the optional project reference on Quick Ticket;
• a Project reference intake field on the service; or
• the internal project configured on the service for Customer Portal tickets, which BareBones Ticketing reads from saved configuration and never from the browser. See Customer Portal.

Ticket creation then stores the association, evaluates select-field owner rules, evaluates the selected mapping set, and finally evaluates the service fixed owner. The fixed owner fills the ticket only if it is still unowned.

If the same person is resolved more than once as a supporting actor, they are added as a Participant rather than a Watcher. The final owner is not also added as a supporting actor.

The three create-time sources run in a fixed order: select-field owner first, then the project-linked mapping set, then the service fixed owner. They differ in how they treat a ticket that already has an owner. The select-field pass and the service fixed-owner pass both stand down and record that the ticket was already owned. The project-linked pass does not check: it assigns its owner over whatever came before. A project-linked Owner row therefore always wins over a select-option owner on the same ticket.

Two known inconsistencies remain at ticket creation.

The routing summary can name a source that did not supply the owner. Where a select-option owner and a project-linked Owner row both resolve, the summary written to the ticket's routing evidence names the select-field entry, while the actual owner is the project-linked one. The owner is correct and predictable; the recorded source is not. Read the ticket's owner field and full history rather than the routing summary.

A failed Owner row stops the rest of the pass. If the mapping set's Owner row cannot resolve — the role is missing, unstaffed, staffed twice, inactive, or ineligible — the project-linked pass stops before applying otherwise valid Watcher and Participant rows. Do not rely on supporting actors being added when the mapped Owner fails.

Assignment during a transition

Configure the source on the move. See Workflows and statuses.

The available sources are:

• Fixed owner routing (optional) — one named eligible person.
• Project-linked — resolve the selected mapping set's Owner role against the ticket's project.
• Least busy — the one least-loaded eligible candidate.
• Department manager — the current manager of record.
• Current on-call — the one active coverage window.

When the transition is actually performed, BareBones Ticketing:

1. keeps an existing owner and refuses to act if the ticket somehow has more than one;
2. skips routing entirely if the move has an Assign to actor follow-up step, and makes the person who ran the transition the owner;
3. uses the fixed transition owner if one is configured;
4. otherwise selects the mapping set by the department fallback rule and reads its Owner row only — mapped Watcher and Participant rows are not applied during a transition;
5. requires exactly one active project association and one unambiguously staffed role; and
6. assigns the person only if they are active and Work-eligible.

Listing or explaining the available transitions assigns nobody. Only performing one does.

If any of these are missing — the project association, the Owner row, the staffing, the person's eligibility — no owner is assigned, the reason is written to the ticket history, and the transition itself still completes. A skipped owner does not block a status change.

Deactivating a project does not clear the ticket associations pointing at it, and transition routing may still use them. Before deactivating a project, list its ticket associations and clear or move each one.

Apply project-linked routing to existing tickets

1. Open Agent Queue and narrow the filters to the tickets you want.
2. Select Bulk operations.
3. Under Candidate tickets, select the tickets. Select displayed view selects only the tickets currently shown. One operation carries at most 250 tickets.
4. Under Assignment source operations, choose Project-linked role routing.
5. Select Preview outcomes. For each ticket, review the current owner, the proposed owner or watcher, the outcome, and any skip reason.
6. Fix the missing project links, staffing, mappings, or eligibility that the preview shows, then preview again. Preview changes nothing.
7. Complete step-up verification if prompted, reread the refreshed preview, and select Apply changes once.
8. Review every changed, unchanged, and skipped result.

Apply re-reads current state and authorization and processes tickets one at a time. It is not a single all-or-nothing operation — if it stops partway, earlier tickets are already changed. Check current ticket state before retrying.

The 250 limit is enforced on the candidate list itself: the operation loads at most the first 250 authorized tickets for the scope, and the page tells you when that window is limited. A larger filter match is not silently processed — tickets beyond the loaded window are never selected and never changed. Narrow the filter until the candidates are the tickets you mean, or run it in batches, and count the results against the number of tickets you meant to change.

This operation applies the Owner and Watcher outcomes only. Participant and No action rows remain valid definitions for the other triggers, but this operation does not act on them. It can assign an owner only to a ticket that has none.

If it does not work

• Nothing was assigned and no error appeared. That is the normal result when a source cannot resolve. Read the ticket history for the recorded reason.
• A department row you expected was ignored. The service has at least one active row. See the department fallback rule.
• A candidate was skipped. Check that they are active and hold Work or stronger access in the ticket's department. Do not use a mapping to work around missing access; grant the access through the normal process or pick someone else.
• A project role resolves to two people. Correct the project staffing. The mapping cannot choose between them.
• On-call routing was skipped. The coverage window has expired or is invalid. Correct the window before evaluating again.
• The owner is not who you expected on a newly created ticket. If both a select-option owner and a project-linked Owner row could apply, the project-linked one is the owner. The routing summary may still name the select-field entry; read the owner field itself.

Related pages

• Services and the Service Catalog
• Custom fields and tags
• Workflows and statuses
• Customer Portal
• Glossary
• Limits and scope