Binding Modes Explained
Every container in ContainerQ carries a Binding Mode. It’s the single most important field in the product, because it tells you what kind of guarantee you’re actually looking at — and it’s never something you set.
Where you’ll see it
Binding Mode shows up on the container record itself and on every line beneath it. It isn’t a manual toggle a user flips — it’s decided automatically, at pack time, by the item’s own Business Central item-tracking setup. Pack an item that Business Central tracks with package-specific tracking, and the container gets Package bind. Pack anything else, and it gets Positional bind. You never choose one over the other; the item’s own setup already answered that question before you touched a scanner.
Package bind
Package bind is triggered automatically when an item is tracked using Business Central’s package-specific item tracking. This is the strong case, and it’s worth stating plainly: for a Package-bind container, Business Central’s own posting engine is what refuses to let the container and its contents come apart. The bond isn’t something ContainerQ is watching from the outside and hoping holds — it’s enforced by the same platform kernel that enforces every other posting rule in Business Central. If an operation would break that bond, the platform itself is what stops it, the same way it would refuse a lot-tracked posting that’s missing its lot number.
Positional bind
Positional bind is triggered for everything else — any item that isn’t using package-specific tracking. Here, the container-to-contents relationship is ContainerQ’s own record, not something Business Central’s posting engine enforces directly. What ContainerQ does about that is continuously re-check its own record against the real ledger, and show you the result — currently confirmed, or in question — right on the container.
What that check does is re-read the ledger and compare it against what ContainerQ’s record claims the container holds. What it does not do is guarantee the two can never disagree in between checks. A Positional claim can be correct for a while and then quietly stop being correct — if something outside ContainerQ changes the physical stock, the app’s record won’t know until the next check runs and catches it up. That’s the honest shape of a re-checked claim rather than a platform-enforced one, and it’s exactly why the badge exists: so you’re never looking at a claim that presents itself as more certain than it is.
It’s worth being precise here, because it’s tempting to round “continuously re-checked” up to “continuously guaranteed.” They’re not the same sentence. The check is real, and it re-reads the actual ledger rather than trusting ContainerQ’s own tables — but a check is only as good as how recently it ran relative to whatever changed the stock. Treat Positional bind’s status as what ContainerQ most recently confirmed, not as a live, unbreakable promise the way Package bind’s platform enforcement is.
| Question | Package bind | Positional bind |
|---|---|---|
| What decides it | The item’s own package-specific tracking setup in Business Central | Automatic default for any item not using package-specific tracking |
| Who enforces the bond | Business Central’s own posting engine | ContainerQ’s own record, re-checked against the ledger |
| What the badge tells you | The platform itself refuses to let this come apart | Currently confirmed, or currently in question, as of the last check |
| Can it go stale between checks | No — the platform enforces it continuously, not on a schedule | Yes — a change outside ContainerQ can outrun the next re-check |
Why the mode is always visible
This is the design rule that makes the whole thing honest: Binding Mode is always shown, never collapsed into one generic “OK” badge that looks the same regardless of which guarantee is actually behind it. A container you’re looking at is either Package-bound — enforced by the platform — or Positional-bound — a claim the app re-checks and reports on. You always know which one, at a glance, on every container and every line. Nothing in ContainerQ hides a claim-only state behind the same visual language as a platform-enforced one.
That design choice is a direct answer to the fear every buyer in this category eventually has: that a container app’s own record will quietly stop matching the ERP’s ledger, and nobody will find out until a count comes up wrong. Collapsing both binding modes into one green checkmark would make that fear worse, not better — it would tell you everything is fine in exactly the cases where the honest answer is “probably, and here’s what ContainerQ last found.” Keeping the two marks distinct is what lets you decide, container by container, how much weight to put on what you’re looking at.
A worked example
Say a pallet is built from two items: one tracked with package-specific tracking, one that isn’t. Because Binding Mode is decided per item at pack time rather than once for the whole container, the lines built from each item can carry a different mode on the same pallet — one line Package-bound, the other Positional-bound. Reading that container’s overall state means reading the mode on each line, not one summary badge for the whole pallet, because the two lines are genuinely backed by two different kinds of guarantee. A container that’s mostly Package-bound with one Positional-bound line is not “mostly safe” — it’s exactly as safe as its weakest line, for whatever you’re doing with that specific line.
Why this isn’t the same as “verified compliant”
It’s worth heading off a natural but wrong inference. Package bind means Business Central’s own platform stands behind the bond — it does not mean every operation your organization has ever performed against that item has been independently audited, and it does not extend any guarantee to items that aren’t package-tracked in the first place. Positional bind’s re-check means ContainerQ compared its record against the ledger and found agreement as of that comparison — it does not mean the container has never drifted, only that it isn’t currently showing a known disagreement. Both statements are honest and useful. Neither is a substitute for understanding which one applies to the container you’re looking at.
The practical takeaway
If a process is compliance-critical or the stakes of a wrong answer are high, look at the Binding Mode before you trust the container’s contents. Package bind means the platform is standing behind it. Positional bind means ContainerQ is watching and will tell you what it last found — which is genuinely useful, but it is a different kind of promise. Deciding how to treat each mode is a business decision, not a technical one; ContainerQ’s job is only to make sure you’re never guessing which one you’re looking at.