When Buttons can't complete a route, it doesn't just say no: it tells you exactly what's in the way and gives you a button to fix it. This page covers what to do when a route can't find a path, why a route request gets rejected before it even runs, and how to read a routing report after execution.
For interpreting live vs. requested state and lock indicators, see
Understand route status first: this page covers what's beyond that.
Before you begin#
When a route can't find a path#
If a staged route needs to travel through shared infrastructure (a tieline between routing domains, for example) and every path is already claimed by other active routes, the staged mapping shows a red No path found indicator instead of a route.
- Select Find Route Request to replace next to the indicator.
- The Route Requests Using Wires dialog lists every route request currently holding a wire your route needs, each shown as its source and destination.
- Select Select All or individual requests, then select Release Selected to free them up.
If the dialog instead reports no route requests found, the block isn't caused by anything currently routed: it's a structural limit, such as no wire existing at all between the domains involved. Releasing routes won't help; the routing topology itself needs to change.
Why a route request was rejected#
Some routes are rejected before Buttons even attempts to execute them. A routing report or execution error will name one of these reasons:
- Protected port: the port is marked to prevent accidental routing.
- Visibility: the port is hidden and isn't available to route to or from.
- Locked destination: the destination has a lock in place. See Understand route status for reading and clearing locks.
- Superseded by a later request: a newer request for the same destination arrived before this one finished, so this one was dropped in its favor.
- No stored path to re-execute: a retained Route Request was asked to re-execute, but the path it originally used is no longer valid.
- Project required: an administrator has turned on Require project for tielines, and this route needs a Project selected before it can be taken. See Group and release routes with Projects.
- Free tier: the route touches a source or destination group outside what the free tier allows. Routing interfaces already grey out the unavailable groups; this is the same restriction rejecting a route that reached the server anyway.
Read the routing report#
A routing report opens after taking a route, and shows its title as Routing with a status badge: In Progress, a count of requests Completed, or a count Failed. Its icon reflects the outcome: a green check for a clean success, an amber warning for a partial success, or a red warning for a complete failure.
Routing spans more than one domain: a single route can involve Connection, NMOS, and Workflow actions together, and each is reported separately. A partial failure means some of these succeeded while others didn't; the report's per-domain sections show exactly which.
Expand the report's sections as needed:
- Execution Errors and Virtual Mapping Errors: fatal problems, shown expanded by default when present.
- Route Execution Errors: every per-request failure, including the rejection reasons above.
- Persisted Routing Requests: the retained Route Requests the execution created or updated, including their full path through any Relations, even when part of that path failed.
- Connection Route Actions, NMOS Route Actions, Workflow Route Actions: the actual per-domain results, each marked success or failure individually.
- No Path Available: requests that couldn't find any path at all.
- Warnings: problems that didn't stop the route from completing.
Select Copy Full Report to get the complete technical detail for a support request. Reports are only available for 10 minutes after execution: copy or act on one before it expires.
Check a retained request's health in Requests#
Routing → Requests lists every retained Route Request, each with a status dot. A red dot means the request is broken: hover it to see which part failed.
The breakdown covers each intermediate hop (Via 1, Via 2, and so on) across three checks:
- Whether the segment's source port is still available.
- Whether the segment's destination port is still available.
- Whether the segment is actually routed to the source the request expects: this is the check most likely to fail, since it can go wrong even when both ports themselves are healthy, for example if the segment's real hop was never actually executed.
The same list identifies each request's mapping and where it came from:
- Source and Destination show the request's endpoints.
- Initiator shows who or what created the request: a signed-in user, or the Position, Workflow, Cue List, or Surface that triggered it, alongside the entry point Buttons received it through (for example Web UI, Salvo, or Matching Preset). More than one badge can appear together, such as a user's name next to the Position they were operating.
- Project shows the production the request is assigned to, if any. Open the context menu and select Assign to project... to move it: see Group and release routes with Projects for the full workflow.
- Path expands to the request's complete route through any intermediate hops, the same chain the health breakdown above checks.
Select a request to Reroute, Release, or Delete it directly from this list, rather than tracking down every affected Relation or Project individually.
If you get stuck#
What you see | What to try |
|---|
A staged route shows No path found. | Select Find Route Request to replace to see what's holding the wires you need, or confirm a path exists at all between these domains. |
The Route Requests Using Wires dialog shows no requests. | The block is structural, not caused by an active route: releasing routes won't help. |
A route failed with Locked destination. | |
Some of a route's actions succeeded and others failed. | Open the routing report and check each domain's section individually rather than assuming the whole route failed. |
Where to go next#
