Pack, Move, Split, Merge and Nest

These are the actions that build and change a container. Five of them you can do today. Two are on the roadmap — this page is clear about which is which.

Together, these actions cover the lifecycle of a container: build it up (Pack), relocate it (Move), tear it back down (Unpack), reorganize how containers relate to each other (Nest/Unnest), and — eventually — reshape what’s on a single container without dissolving it entirely (Split, Merge). Knowing which of these you can reach for today, versus which describe where the product is headed, matters more here than almost anywhere else in the manual, so each section below states it plainly.

Action	Available today?
Pack	Yes
Move	Yes
Unpack	Yes
Nest / Unnest	Yes
Split	No — designed, not yet shipped
Merge	No — designed, not yet shipped

Pack

Pack adds scanned stock to a container. You scan the item — and, where the item calls for it, its lot, serial, or package identity — and it’s added to the container’s manifest. This is usually the first thing that happens to a new container, and it’s what establishes the container’s Binding Mode in the first place: what you pack determines whether the container ends up Package-bound or Positional-bound (see binding modes explained). Packing is also incremental — a container isn’t a one-shot declaration, it’s a running manifest, and you can keep packing additional stock onto the same container across multiple scans as it fills up, across different receiving events if your workflow calls for it.

Move

Move relocates a container, and everything nested inside it, from one location to another in a single action. You don’t move each item separately, or each nested container separately — you scan the top-level container once, and its entire contents, at every nesting level, travel with it to the new location.

Move always posts a real transaction, regardless of Binding Mode. Physically relocating stock always requires a real post to keep Business Central’s ledger accurate — Positional bind doesn’t change that. The Binding Mode governs how the container’s own claim about its contents is verified, not whether a move itself gets recorded. In other words, a Positional-bound container isn’t moved “unofficially” while ContainerQ catches up later; the move itself is a real, immediate posting either way.

Unpack

Unpack dissolves a container. The physical stock itself is untouched — nothing moves, nothing changes about where it sits or how it’s tracked — only the container’s own claim on that stock disappears. After an unpack, the items go back to being tracked the way Business Central tracks any stock that isn’t sitting inside a license plate. This is the action to reach for when a container’s identity has served its purpose — stock has been staged for a process that doesn’t need a license plate any further — rather than when you actually want the contents to end up somewhere else, which is what Move is for.

Nest & Unnest

Nest makes one container a child of another — a tote nested inside a pallet, for instance — so a single scan of the parent carries everything nested beneath it. Unnest removes that relationship, freeing the child container to stand on its own again, without touching its own contents. Both are available today, and both work regardless of how many levels deep the structure goes: a tote in a pallet, a pallet in a shipping container, and so on. See nesting and multi-level containers explained for the underlying concept and why it’s harder to build correctly than it looks.

Split & Merge

ContainerQ is designed to support splitting a container’s contents onto another container, and merging two containers into one. As of the most recent internal review, these two are not yet reachable in the shipped product — they describe the direction the feature is headed, not something you can do today.

Until they land, the practical workaround for a split-shaped need is usually an Unpack followed by a fresh Pack onto a new container. For a merge-shaped need, it’s Nest, which achieves a similar operational outcome — one scan for a combined load — without collapsing the two containers’ own identities into one. Neither workaround is a hidden feature; they’re just the two shipped actions above, applied to a problem the product doesn’t yet have a dedicated action for.

What this looks like day to day

A typical container’s life under the actions available today runs: Pack at receiving, establishing the manifest and the Binding Mode → Move to a staging bin or storage location → optionally Nest onto a larger container as the load consolidates → Move again as it works through the warehouse → Unpack at the point where the container’s job is done, if the workflow calls for dissolving it rather than shipping it intact. Every one of those steps is confirmed by an independent second read of the ledger before it’s reported complete — the mechanism behind the Binding Mode badge described on the previous page, not a separate check bolted onto each individual action.

Available today vs. planned

Pack, Move, Unpack, and Nest/Unnest are shipped and usable now. Split and Merge are intended future capability. If you’re evaluating ContainerQ for a workflow that depends on splitting or merging containers, treat that as not yet available rather than assuming it works because it’s a common operation in this category. The FAQ states the current boundary plainly if you want the short version.