Why this feels wrong at first
Most systems only let you create a record once you know what it’s for. QRtub doesn’t work that way: a Link’s only real job is to exist at a stable address. Everything else — what it points to, which Item it belongs to, whether a Page is behind it — can happen whenever that part is actually ready, not when the Link was created. So seeing “Unallocated” on a batch of codes doesn’t mean setup is incomplete. It means the part that needed to happen first — printing, before a lead time ran out — has happened, and the rest is still ahead of you on purpose.What this actually enables
- Printing before you know the destination. Order and print a batch now, decide what each code opens once you know.
- Spares. A few extra codes in every batch that don’t belong to anything yet, ready the day something replaces a damaged tag or a new piece of equipment shows up.
- A shortener, and nothing more, for as long as you like. A Link can point straight at a URL for its entire life and never have an Item or a Page — see What a Link Is for why that’s a complete setup rather than a partial one.
What happens if someone scans one
An Unallocated Link resolves to a plain “not connected yet” page rather than an error. If it’s already installed somewhere the public can reach it, that’s what they’ll see until you connect it. If a batch is print-only and not yet applied to anything, this never comes up — nobody scans a code that’s still in a box. Someone signed in to the team that owns the Link sees something more useful: the same page, with the option to assign the code to an Item there and then from their phone. The person applying tags can connect them on the spot without going back to a desk.Related
- The Print-First Workflow — ordering and applying tags before the equipment exists
- Print Batches — tracking a production run, allocated or not
- Preparing Your Print Job — getting a batch of these actually made
- Deleting, Unassigning, and Releasing Links — how Links become unallocated again