Workflow Actions

A ticket changes status only by performing a workflow action the workbench currently offers. This page covers finding the eligible actions, filling in what a transition asks for, and reading what changed afterwards.

There is no control that sets a status directly. If an action is not offered, that is the answer, not an obstacle to work around.

Before you start

• You need department Work access to the ticket.
• Refresh the workbench if someone else may have changed the ticket since you opened it.
• Have ready whatever the transition asks for: prompt answers, a file, or a completed approval.

Read the eligible actions

1. Open the ticket and find Available actions. These are the transitions you can perform right now, given the ticket's current status and your access.
2. Select the intended action. The workbench shows the consequence: Move this ticket to target status.
3. Read Workflow actions waiting on required information. These transitions exist for the current status but are not ready. Each one names what is missing.
4. Use Workflow overview to see the map of statuses and transitions. It is read-only and does not move the ticket.

Available actions and Workflow actions waiting on required information are the names of the two groups, not headings printed on the screen. Look for the list of actions you can run now, and the separate list of actions that name something missing. A screen reader announces both names.

Where a workflow configures more than one route to the same target status, the list resolves which one applies before deciding whether to offer it — a route written for your exact current status wins over a broader any-source one. So an action shown as available is the one that would actually run, rather than a second route that would be refused on the way through.

Complete the prompts

A transition can ask for information before it will run. Each prompt has a type set in the workflow configuration.

1. Fill in every prompt marked with *. These are required.
2. Follow the type shown. There are eight: short text, long text, resolution code, resolution summary, evidence reference, rich text, a date, or an attachment.
3. For a file prompt, upload the file through the action itself and confirm it is staged for this transition.
4. Re-read your answers before submitting. Prompt answers are stored with the status-change history and are visible to anyone who can read that history.

Satisfy an approval gate

Some transitions are gated. The action stays unavailable until a matching approval is recorded, or until you complete a re-verification control the action renders.

1. If the action shows an approval gate, open the approval request from the blocked action so it is bound to that exact transition.
2. Wait for every named approver to approve.
3. Return to the ticket and re-read Available actions.

An ad hoc approval does not satisfy a gate, and approving does not itself move the ticket. The full rules for how the product picks which approval satisfies a gate are in Approvals.

Perform the action

1. Check the action label, target status, prompt answers, file, and gate state.
2. Submit once.
3. Wait for the result. Do not submit again in parallel.
4. Confirm the new status and the new entry in the ticket's history.
5. Re-read the owner and the SLA, because a transition can change either.

Immediately before it changes anything, BareBones Ticketing checks the whole action again: the ticket's status right now, your access right now, whether the ticket has changed since you opened the page, your prompt answers, the file you attached, and the approval gate. If anything has moved on since the page loaded, the action is refused and the status does not change. An old page left open cannot push through a change based on what was true earlier.

That re-check holds the ticket while it runs, so two people acting on the same ticket at the same moment do not both succeed. One transition goes through; the other is refused because the ticket is no longer in the status its action was chosen for. The same is true of a requester acting from the portal at the same moment as an agent. Re-read the ticket rather than assuming a refusal means your own action was wrong.

What a transition can change

A transition changes the status. Depending on how it is configured, it can also do any of the following. None of them happen unless configured.

Owner routing after a transition

Owner routing runs only when the status actually changed and only when the ticket has no owner. A fixed owner named on the transition wins over any assignment source. Assign to actor suppresses both: it makes the person who ran the transition the owner. That is whoever performed the action — you, if you performed it — not the person who raised the ticket. An assignment source preserves an existing owner rather than replacing it, and also preserves an owner it cannot resolve unambiguously.

Routing can be skipped and leave the ticket unowned even though the status change succeeded. Read the ticket history and the assignment result before assuming the transition failed.

For the Project-linked source and the department-fallback rule that decides which mapping set applies, see Assignment Rules. Two points matter at transition time: routing uses only the Owner row of the selected mapping set and does not add mapped watchers or participants, and a project that was made inactive after it was linked is still consumed by routing. Relink or clear the association before relying on a project-linked transition.

This is deliberately narrower than the Agent Queue's bulk project-linked operation, which applies both the Owner and the Watcher rows. So a mapping that names a Watcher is honoured when you run it as a bulk operation but is silently ignored at transition time. If a Watcher on the mapping matters, apply it through the bulk operation — a transition will not add it. See Bulk Operations.

What happens to the SLA

SLA timing is measured from the ticket's creation time. How the time is counted depends on the target: a target set to 24/7 wall-clock counts weekends and public holidays as elapsed time, while a target set to Business hours calendar counts only the working time in the calendar bound to it. First response and resolution are set independently, so one ticket can use both.

Your administrator configures this. If you need to know which applies, ask which time mode the department's SLA policy uses. See Service-level agreements.

A status can be configured to pause SLA timing. While the ticket sits in such a status, the time remaining shown on screen stops counting down, and the paused time is counted in your favour consistently — for the time displayed, for the Warning, and for the breach alike. A ticket is not pushed into breach by time it spent paused.

How that credit is applied depends on the target's time mode. On a 24/7 wall-clock target the paused time is subtracted when the target is assessed. On a business-hours target the assessment holds at the moment the pause began, and the due date itself is extended when the ticket resumes.

Resuming is not something you configure. Any transition into a status that does not pause timing resumes the clock.

Resolving or closing a ticket does stop the resolution clock. The product records when the ticket was resolved, marks the resolution target met, and leaves it alone from then on. The ticket shows On Track against that target.

Reaching a resolved or closed status also retires the first-response target. A first response that was never posted is not turned into a breach once the ticket is finished — the clock stops rather than running on toward breach on closed work. A first-response breach that was already recorded before the ticket closed stays recorded: closing does not clear it, and the ticket keeps showing Breached.

Retirement follows the status the ticket is in now, not the fact that it was once resolved. Reopen a ticket that never got a first response and the target goes back under monitoring, and can warn and breach again. So a ticket cannot be parked out of its first-response target by closing and reopening it.

The workbench shows one of four indicators:

The queue's row signal names the same four states in its own words — On track, Due, Breached, and No SLA — see The Agent Queue.

The page can also show the due date, the time remaining, and whether the first-response or resolution checkpoint is the active one. A target that has already been met is not treated as the next active target.

The warning threshold is set per target on the SLA policy, not fixed product-wide. It defaults to 25 percent, and first response and resolution can carry different values. If you need to know the figure for a given ticket, ask which policy its department uses.

These are internal workflow timers. They are not a commitment by the vendor to respond or resolve within the displayed time.

If it does not work

• The action you want is not listed. Check Workflow actions waiting on required information first. If it is not there either, the transition is not configured from the current status, or your access does not permit it. Ask the person who owns the workflow configuration.
• Submission was refused as stale. Someone changed the ticket after you loaded the page. Refresh, re-read the eligible actions, and choose again. Do not resubmit the old attempt.
• A prompt or file was rejected. Correct only the field or file named, then re-read the whole action before submitting again.
• The gate is not satisfied. Stop. Do not pick a different transition as a way around it.
• Every change is refused because of the product licence. Nobody can save changes until that is fixed. Tell your system administrator.
• The status changed but the owner did not. Routing was skipped. Check the ticket history and the assignment result for the reason, then set the owner by hand if needed. See Ownership and Participants.
• The SLA figures look wrong. Record the current status, whether it pauses timing, the due time, and the current time. Check which time mode the target uses before recalculating by hand: a business-hours target will not match a wall-clock calculation. Paused time is excluded from the displayed remaining time, the warning, and the breach alike, so a paused ticket should not tip into breach on time spent paused.

Related pages

• Work a Ticket
• Ownership and Participants
• Bulk Operations
• Approvals
• Assignment Rules