Finlay.worksBareBones Ticketing manual

Configure

Workflows And Statuses

How to define statuses, build a department workflow, and configure each allowed transition with its rules, prompts, and follow-up steps.

RC2 approved for evaluation Status: release-candidate Audience: System Administrator Source: c4b4d41

Workflows And Statuses

A status is a state a ticket can be in. A workflow is the set of moves allowed between statuses. This page covers defining statuses, building a workflow, and configuring each move.

Statuses are defined once for the whole installation. Workflows belong to departments.

Before you start

  • You need SystemAdmin access and step-up verification.
  • Draw the lifecycle before you open the product. Name every state and every move between states.
  • Decide which states are finished states and which are waiting states.
  • The owning department must be enabled.

Define a status

  1. Open Status Definitions. The list shows every status, whether it is active, whether it is terminal, and whether it pauses service-level agreement (SLA) timing.
  2. Select Add status.
  3. Enter a Status key, a Display name, the category, and the sort order.
  4. Select Terminal status only if a ticket in this state is finished.
  5. Select Pauses SLA timer only if SLA timing should stop while a ticket waits in this state. See Service-level agreements.
  6. Select Create status once. The status appears in the list.
  7. Place it in the order you want.

Creating a status does not make it reachable. A ticket can only enter a status that a workflow move targets.

Deactivating a status is refused while live tickets sit in it. The product counts tickets holding the status whose category is not Closed and which are not terminal, and refuses with "Cannot deactivate status definition because N live ticket(s) currently use it." Move those tickets to another status first.

Renaming a status key is guarded on the same principle, for tickets that rely on the built-in fallback workflow. The Terminal status and Pauses SLA timer flags are not guarded — you can change those with live tickets in the status.

Build a workflow

  1. Open Workflow Administration and choose the owning department.
  2. Select Add workflow.
  3. Enter the name and the description operators will see.
  4. Select Create workflow. The new workflow is inactive and is not the department default.
  5. Reopen the saved workflow and add its moves, following Configure a move below.
  6. Review the whole set of moves. Confirm there is a path from the ticket's opening status to every state you intend to reach.
  7. Select Use this workflow for new tickets when it should apply to new work.
  8. Select Make this the department default only if it should be the department's fallback workflow.
  9. Select Save workflow changes.

Activating a workflow affects tickets created afterwards. It does not move tickets that already exist, and it does not rewrite their status history.

Creating, updating, and deleting a workflow are each refused if the result would strand a live ticket — that is, leave a ticket in a status with no outbound move available to it. The message names the count and the status key, for example "Cannot update workflow because 3 live ticket(s) currently in status 'PENDING' would have no outbound workflow move." Give the affected status an outbound move, or move those tickets first, then retry.

Which workflow a ticket gets

BareBones Ticketing chooses in this order and stops at the first match:

  1. The active workflow set as the service's Default workflow.
  2. The active department default workflow.
  3. The built-in fallback workflow.

Set the service default on the service. See Services and the Service Catalog.

Configure a move

Each move is one allowed transition. Workflow Administration is department-scoped — choose the department first, then open one workflow from its roster. The workflow workspace shows its moves as a review-first list: each move summarises its ROUTING (the owner-routing foundation, e.g. Project-linked owner source or Heuristic department-manager source, or none), REQUIREMENTS, APPROVAL, INFORMATION (the prompts collected), and FOLLOW-UP, so you can read what every move does before changing one. Use Add move to create one, Move earlier / Move later to reorder, Review workflow details to edit the workflow's own name and description, and Save workflow changes to commit — saving shapes future ticket moves in the department, not the current ticket roster.

  1. Choose the From status, or select Allow from any current status.
  2. Choose a different active To status.
  3. Enter the label an Agent will see on the button.
  4. Set owner routing, or leave both controls empty so the move does not assign anyone. The editor offers two separate controls: Fixed owner routing (optional), which pins one named eligible person, and Contextual owner source (foundation only), which picks a rule — Project-linked owner, Heuristic: Least busy, Heuristic: Department manager, or Heuristic: Current on-call. See Assignment rules for what each source does and when it runs.
  5. Choose No transition approval gate, Operational approval gate, or Regulated approval gate. If you choose a gate, enter a stable purpose label.
  6. Decide separately whether the move requires regulated re-verification. A stricter workflow-wide setting is not relaxed by a move-level setting.
  7. Add any prompts, requirements, and follow-up steps described below.
  8. Set the order of the moves and save once.
  9. Open a test ticket in the From status and confirm the move appears and completes.

If an exact-source move and an any-source move both reach the same target status, the exact-source move is used.

Ask for information during a move

A prompt is a question the Agent answers as part of the move.

  1. On the move, select Add prompt.
  2. Choose the answer format: short text, long text, resolution code, resolution summary, evidence reference, rich text, date, or an existing attachment on the same ticket.
  3. Enter a stable key, the label, the sort order, and the help text.
  4. Set whether the answer is required.
  5. Save.

A required prompt blocks the move until it is answered. An attachment prompt links an attachment that is already on the ticket and is still active and not redacted. It does not let the Agent upload or download anything new.

Require conditions before a move

A requirement is checked before the status changes. If it is not met, the move is refused and nothing changes.

Use only the supplied requirement templates:

  • minimum access level
  • ticket age threshold
  • owner assignment state
  • specific service
  • service category
  • custom-field check
  • child action items complete

Run a follow-up step after a move

A follow-up step runs after the status change is committed, in the order configured.

Use only the supplied steps:

  • assign to actor
  • notify watchers
  • update SLA
  • update the active parent ticket

Requirements and follow-up steps are chosen from these lists. There is no scripting. Do not put JSON, code, or instructions into a label or help text expecting them to run.

Approval gates

A configured gate blocks the move until a matching approval request exists and every assignment on it is approved.

  • The gate matches on the exact gate purpose. An approval request raised for something else does not satisfy it.
  • If the most recent exact-matching request is pending, rejected, or otherwise unresolved, the move is blocked.
  • A newer request that does not match does not displace an older one that does.
  • An ordinary ad-hoc approval on the ticket does not satisfy a gate.

When the move succeeds, the ticket history records which approval request and policy satisfied the gate. It does not copy the approval note.

A regulated gate controls the approver's decision. A regulated transition rule separately requires the person making the transition to acknowledge the meaning of their signature and to reverify their identity. Configuring one does not cover the other.

Configuring approval gates and re-verification is a product control. It is not evidence of completed regulatory compliance or validation.

If it does not work

  • The move does not appear on the ticket. Check that the workflow is active, that it is the one the ticket resolved to, and that a move exists from the ticket's current status.
  • The move is refused with no change. A requirement was not met, a required prompt was unanswered, or an approval gate is unsatisfied.
  • The move works but no owner was assigned. Owner routing was skipped. The transition still completes. Check the ticket history for the recorded reason. See Assignment rules.
  • An any-source move fires when you did not expect it. Add the exact-source move you want and test both paths.