Skip to main content

Linked Moves

Linked moves let you chain work tickets together so that one must complete before the next can start. This is useful for multi-step operations like "move container from gate to staging, then from staging to storage."

When auto-dispatch is enabled, the dispatch system understands the chains and works around them; see Linked Moves and Auto-Dispatch below.

How Chains Work​

A linked move creates a predecessor → successor relationship between two tickets:

  • The predecessor must be closed before the successor can be started
  • The successor is automatically unblocked when the predecessor closes

Chains can be up to 4 tickets long (e.g. A → B → C → D).

Blocking Behavior​

When a ticket has a predecessor that is not yet closed:

  • The ticket cannot be moved to in-progress — attempts to start it will be rejected
  • The ticket can still be moved to problem status if needed
  • On the workflow and work queue views, a red "Blocked" badge indicates the ticket is waiting on a predecessor

When the predecessor closes:

  • The successor is automatically unblocked (the "Blocked" badge clears in real time)
  • The successor is now eligible to be started (or auto-dispatched, if that feature is enabled)

A Dispatch user can link two tickets from the activity detail view. Open the ticket, find the Dependencies section, and pick the ticket that should follow it (or the ticket that must come before it).

Linking at Ticket Creation​

You can also establish the link at the time you create a ticket — open the Dependencies section in the create dialog and pick a predecessor (the ticket this one depends on) and/or a successor (the ticket this one blocks). Both fields are optional. Setting both inserts the new ticket into the middle of an existing chain.

This is useful when you already know the dependency up front and removes the need to create the ticket, then reopen it to add the link.

Chain Length

A chain cannot exceed 4 tickets. If linking two tickets would create a chain longer than 4, the link is rejected. Circular links (where the chain would loop back on itself) are also rejected.

Unlinking​

Removing a link from a mid-chain ticket automatically reconnects the neighbors. For example, if you unlink B from a chain A → B → C, the chain becomes A → C — the connection is preserved.

Deleting a Linked Ticket​

When you delete a ticket that is part of a chain:

  • The chain is automatically reconnected around the deleted ticket (same as unlinking)
  • If the deleted ticket was a predecessor, its successor becomes unblocked

Linked Moves and Auto-Dispatch​

If your organization has Auto-Dispatch enabled, the dispatch algorithm is aware of linked move chains:

  • Creating a ticket with a linked predecessor that is not yet closed: the ticket is not enqueued — it will be enqueued when the predecessor closes
  • Closing a ticket with a linked successor: the successor is checked for dispatch eligibility and enqueued if ready
  • Deleting a ticket with a linked successor: the successor is unblocked and enqueued if eligible

Chains effectively serialize the dispatch order — A is dispatched first, then B becomes eligible when A closes, then C when B closes, and so on.

Don't Worry

If your organization isn't taking advantage of the auto-dispatch feature, linked moves still enforce the blocking behavior — they just rely on manual assignment instead of automatic dispatch.