Skip to main content
A Destination is where a scan ends up. It is a URL that QRtub either redirects to immediately or shows as a button on a Page — an inspection form, a maintenance system, a PDF manual, a phone number, a mobile app deep link. The QR code itself never contains the Destination. It contains a Link, and the Link resolves to a Destination at the moment of the scan. That indirection is the whole point: you can change where a code goes without reprinting anything.

​
Where Destinations are set

Destinations are set on the Item, on the Item’s Destination tab:
  • Default URL — the single Destination a Direct-Mode scan redirects to. This is the plain, unconditional URL.
  • Conditional routing rules — an ordered list that can pick a different URL per scan based on the Item’s data, the device, or the time.
If the Item’s Link opens a Page instead, each Destination is a button on that Page — an ActionLink, Button, or Link section with its own URL. One Item can carry as many of those as you need. Which of the two behaviors you get is the Direct Mode / Page Mode choice, covered in Direct Mode vs. Page Mode.

​
The resolution order for a scan

For a scan that redirects (rather than opening a Page), QRtub checks only that Item’s own destination data, in this order:
  1. Conditional routing rules, if the Item has any enabled. Rules are evaluated top to bottom and the first match wins — see Conditional Destinations & Rule Priority.
  2. The Item’s Default URL, with any {{bindings}} resolved.
  3. Nothing. If neither produces a usable URL, the visitor gets the “not ready yet” page below.
Two consequences catch people out: A URL whose bindings do not all resolve counts as no URL at all. If your Default URL is https://cmms.example.com/asset/{{item.equipmentID}} and this Item’s equipmentID is empty, QRtub does not send a half-built URL — it skips that URL and moves to the next step in the order. The same applies per rule. The Collection’s default destination pattern is not consulted at scan time. That pattern is stamped onto each Item when the Item is created and then belongs to the Item. Editing the pattern later changes nothing about Items that already exist. See Default Destination for New Items. Note that an Item carrying enabled conditional rules always routes, even when its Collection is set to Page Mode — the rules take precedence over showing a Page. If the rules then match nothing and there is no Default URL, the Page is shown after all.

​
Values go into a URL exactly as stored

Destinations can pull Item data straight into the URL with double-brace bindings, so one URL template serves every Item in a Collection:
Two limits worth knowing before you build one:
  • There is no automatic URL encoding. The stored value is inserted character for character. A field containing a space, an &, or a ? will break the link. Keep values that feed a URL simple, or use a field that holds an ID rather than a description.
Full syntax and the available namespaces are in Field Bindings & URL Templates. When a scan resolves to an Item that is explicitly set to Destination Link but has no usable Destination, QRtub shows a plain page headed “This access link isn’t ready yet”. It displays the Link’s own public URL and nothing else — never an internal Item, Collection, or team ID — plus an Open in QRtub button. Who sees what:
  • Anonymous visitors see the not-ready page. It tells them the code is assigned but has no destination yet, and that the owner may still be configuring it.
  • Signed-in members of the owning team are sent instead to the authenticated view for that Link, where the Destination can be set. Membership is checked on the server before anything is revealed.
An Item that was never explicitly set to Destination Link does not show this page — it falls through to its Page instead. So a blank-looking Page and a not-ready page are two different symptoms: the first means no Destination buttons resolved, the second means the Item is meant to redirect and has nowhere to send anyone.

​
Unsafe URLs are refused

QRtub blocks script-executing URL schemes — javascript:, data:, and vbscript: — wherever a Destination is used. Whitespace and control characters are stripped before the check, so tricks like java\tscript: are caught too. What you see if one is stored: on a Page, the button renders with a dead # link; on a direct scan, the request returns a 404 rather than executing anything. A fallback URL using one of these schemes is discarded the same way. Ordinary app schemes such as tel:, mailto:, and myapp:// are unaffected — those are app links and are handled deliberately.