Bulk Operations
Bulk operations applies one owner, watcher, participant, or assignment-source change to a set of tickets you select from the queue.
Read this before you apply anything
Whether applying is all-or-nothing depends on which operation you ran. The two families behave differently, and it matters most exactly when a run goes wrong.
Owner, watcher and participant changes apply as one unit. The whole apply is one transaction: either every actionable ticket in your selection is changed and recorded, or none of them is. A failure part-way through leaves nothing changed. Tickets the preview reported as skipped or as no-ops are still normal results — being skipped is not the run failing.
Assignment-source operations do not. Project-linked role routing, current on-call, and department manager sourcing change your selected tickets one at a time, saving each as it goes. If such a run stops partway — because a ticket changed while you were working, because your access to it changed, or because of an error — the tickets it already reached keep their new state and the rest are untouched. Nothing is put back.
So, for an assignment-source run:
- If the run fails, or the result is unclear, open the tickets and look at them. The summary on screen does not tell you where the run stopped.
- There is no "retry the failed ones" button. Work out what went wrong, select only the tickets that still need changing, preview, and apply again. Do not re-apply the whole original selection — the ones that already worked would be processed a second time.
Do not carry the second family's caution over to the first. Re-applying an owner, watcher or participant change after a failed apply is safe, because the failed apply changed nothing.
One other thing happens to the whole run rather than to one ticket. If you have lost department Work access to any ticket you selected by the time you apply, the whole selection is refused and nothing at all is changed.
The test is Work access, not whether you can see the ticket. A ticket you can still open and read stops the run just the same if your access to it has dropped to View. Do not expect the problem ticket to have disappeared from the queue.
The message you get is deliberately vague: it does not say which ticket, or how many. Refresh the queue, build the selection again from what it now shows you, and do not try tickets one by one to find which one it was.
Before you start
- You need department Work access to every ticket you submit.
- You need department Admin access for each ticket you want actually changed. A ticket you can see but not administer appears as review-only and is not changed.
- Some sites are set up to ask you to confirm your identity again before a bulk change is applied. Be ready for that.
- Decide the operation and the target person before you start selecting.
Build a selection
- In Agent Queue, apply filters that narrow the queue to the intended tickets.
- Open Bulk operations.
- Look at Candidate tickets. Nothing is selected when the page opens, and opening the page changes nothing.
- Select tickets individually, or use Select displayed view after reading what is displayed.
- If the page reports the result as truncated, the candidate list holds only the first 250 tickets that match your filters and that you are allowed to see. It is not every matching ticket. Narrow the filters and run the rest as further batches.
Selecting a ticket gives you nothing you did not already have. Selecting, previewing, and saving filters never widen your access.
Choose an operation
Pick exactly one operation per run.
Assignment source
These pick an owner or watcher from a configured source rather than from a person you name.
- Department manager source
- Current on-call source
- Least-busy eligible owner
- Project-linked role routing
The preview shows, per ticket, the source user, the proposed owner or watcher change, your authority, and any reason the ticket would be skipped. A source can be unavailable or ineligible for some tickets and available for others.
Project-linked role routing uses each ticket's project link, the project's role staffing, and the mapping set that applies to the ticket's service. It evaluates only the Owner and Watcher rows of that set — a mapped Participant row is not applied, and a No action row does nothing. A ticket counts as ready only when the set produces an Owner who can take it. Which set of role mappings applies to a ticket — the ones set up for its service, or the department's fallback set — is explained in Assignment Rules.
A project that was deactivated after it was linked still routes. Deactivation does not clear existing ticket links. Reconcile or clear those links before running this operation.
Owner, watcher, and participant
| Family | Actions |
|---|---|
| Owner | Reassign owner, Clear owner |
| Watcher — the people copied on updates | Add watcher, Remove watcher |
| Participant | Add participant, Remove participant |
For an add or reassign action, use Find an internal actor and select the person. An owner target must have Work access in each ticket's department — tickets in departments where they do not are skipped. A watcher or participant target must be an active internal user.
This release has no bulk workflow, status, SLA, comment, or attachment operation.
Preview
- Confirm the selected tickets and the chosen operation.
- Select Preview outcomes.
- Read the selected, actionable, and review-only counts.
- Read every row: current owner, proposed target, your authority on that ticket, the outcome, and any skip reason.
- Fix the selection, source, target, filters, or access before applying.
For project-linked routing, check the mapping scope shown on each row. A Service scope means the service's own mapping set was used. A Department scope should appear only where the ticket's service has no mapping rows at all.
Preview changes nothing and reserves nothing. It is also not permission to apply later — the checks run again at apply time against whatever is true then.
Apply
- Re-read the preview and confirm the consequences.
- Select Apply changes once.
- If you are sent to a screen asking you to confirm your identity, do so. The page keeps your selection, returns you, and runs the preview again. Read that new preview; it may differ from the one you read before.
- Wait for the results. Do not submit again in parallel.
- Read the changed count and, per ticket, the outcome, the target, the resulting owner, the fields changed, and any skip reason.
- Refresh and confirm the actual ticket state before planning a follow-up run.
Each ticket ends as one of: applied, unchanged (it was already in the state you asked for), review-only (you do not have Admin on it), or skipped with a stated reason. A skipped ticket is not the same as the run failing — see the warning at the top of this page.
If it does not work
- The whole selection was refused with a generic message. You no longer have department Work access to at least one selected ticket. Check your access, not whether the ticket is still visible — it may well still be. Refresh, rebuild the selection from the current queue, and try again. The product will not tell you which ticket it was.
- Rows show as review-only. You have Work but not Admin on those tickets. Ask the department administrator, or run the operation only on the tickets you administer.
- Project-linked preview shows no proposed owner. Check the project link, the mapping set in use, the role staffing on the project, and whether the staffed person is active and has Work access. A department fallback row will not fill a gap in a service mapping set that has any active rows.
- Apply ended ambiguously. Read the current state of the tickets before doing anything else. Some may already carry the change. Do not run a second bulk operation to compensate without checking first.