Shipments

A shipment hands threads — including whole assemblies — to a team in another organization, together with the fields, files, and identifiers you choose to include. You keep your originals; the receiving team gets copies it owns.

Before you start

Role: Team admin
Module: Shipments

Shipments also need an active connection whose direction allows your team to send to the recipient.

Three tasks cover almost everything: compose and send, receive, and recover a shipment that failed. Status definitions and the full lifecycle are in The Shipments page, below the tasks.

Compose a shipment

Outcome: a shipment sent to a partner team, sitting at Awaiting response.

Start a draft. Click New shipment on the Shipments page, or select threads anywhere in DICE and use the batch bar’s Add to shipment, which can add to an existing unsent shipment or start a new one. Give it a Name and an optional Description — context the receiving team will see.
Choose the recipient. The picker lists connected teams. A team the connection doesn’t permit you to send to is disabled and says so. If you have no connections yet, set one up first.
Build the manifest. Use Add threads to search your team’s threads or scan an identifier. A thread can be in only one active shipment: already-shipped threads are hidden, and threads held by another active shipment are shown but not selectable, with a link to the shipment holding them.
Review what travels. Customize each item to pick exactly which Fields, Files, and Identifiers are included. For an assembly you can include or exclude individual parts and choose assets per part — excluding a part leaves out everything installed in it, and excluded parts stay with your team to be transferred separately. Changes save automatically.

Private fields, files, and identifiers are excluded automatically and can never be included, whatever you select here.
Optionally mark a primary thread — the headline item, shown with its own summary card. It stays in the manifest if you later Remove as primary.
Send. Click Send shipment.

Expected result: the status becomes Awaiting response — “Waiting for the receiving team to review and respond.”

Receive a shipment

Outcome: the sender’s threads copied into your team, or the shipment sent back or refused.

An inbound shipment that needs review offers Accept, Request changes, and Reject. Before deciding, read the preview — “What you will receive” — one row per thread the shipment would create. Expand a row to see the thread the way its page will look once you accept: its thumbnail, name, and description, then its Data, Files, and Identifiers, which become your team’s own data when you accept. Certificates marked Via provenance are shown through provenance after you accept and are not copied as your data. Open any file to preview it next to its Transaction Log, and use View provenance to explore where the thread came from.

Accept — the point of no return. The dialog warns that accepting starts processing immediately: copies of the included threads, fields, files, and identifiers are created in your team, and DUST identifiers are registered to your organization.
Request changes — returns the shipment to the sender for editing. A reason is required so the sender knows what to fix. The sender edits the manifest and uses Resend shipment.
Reject — nothing is copied to your team. The sender keeps their threads and can start a new shipment later. An optional note can be included.

After acceptance

Accepting starts Processing: copies are being created, and all items ship together. The page updates automatically and it is safe to leave — processing finishes on its own.

When it completes:

Receiving team — the copied threads are yours. Select received threads on the shipment page to organize them with Move to folder and Add to category. Each received thread’s Transaction Log opens with a Received via Shipment entry and continues into the sender’s disclosed history — the original bind, scans, and recorded entries with their original people and dates — so the item’s story is not cut at the hand-off. The thread header says who it was received from; it does not name the person who accepted the shipment as its creator.
Sending team — the shipment becomes your receipt: a record of what you shipped and when. Your source threads are marked shipped — the receiving organization now works from its own copy, and yours can never be shipped again. Your originals stay editable, but changes reach the recipient’s copies only through an explicit disclosure push — see Disclosures. The transfer itself is recorded permanently in the Fabric lineage of both sides’ threads.

If processing fails

Processing is all-or-nothing. If it fails, the shipment shows “Processing failed” and the last error: nothing was created on the receiving team, and the failure rolled back cleanly.

Either party’s Team admin can recover it — the sender and the recipient have the same two actions here:

Retry — runs processing again on the same accepted shipment.
Abandon — gives up on the accepted attempt and releases its threads so they can be shipped again. A reason is required and is recorded in the shipment’s history.

Only the sending team can then use Start new shipment, which creates a fresh draft from this shipment’s manifest so you can adjust and send again without rebuilding the item list. It is available on any stopped shipment — rejected, canceled, abandoned, or failed.

Cancel a draft

An unsent shipment can be canceled at any time. The dialog “Cancel this shipment?” confirms the stakes: the draft and its manifest are discarded, and your threads are not affected.

Cancel a sent shipment

Cancelling is not limited to drafts. A Team admin on the sending team can also withdraw a shipment that is:

Awaiting response — you sent it and the recipient hasn’t acted yet.
Changes requested — the recipient sent it back and you would rather withdraw it than revise it.

The same Cancel shipment action appears on the shipment’s page, with a confirmation that names the difference: the shipment will be stopped before the receiving team accepts it, and your threads are not affected. Cancelling releases the source threads, so they can be put in a new shipment.

Who can do what

Every action below also requires the Team admin role on the team named in the Who column.

Action	Available when the status is	Who can do it
Edit the manifest, Send / Resend	Draft, Changes requested	Sending team
Cancel	Draft, Awaiting response, Changes requested	Sending team
Accept, Request changes, Reject	Awaiting response	Receiving team
Retry	Processing failed	Either team
Abandon	Processing failed	Either team
Start new shipment (from this manifest)	Rejected, Canceled, Abandoned, Processing failed	Sending team

The Shipments page

The page has two tabs:

Outbound — shipments your team is sending, filterable by All, Drafts, In transit, and Completed.
Inbound — shipments other organizations send your team, filterable by All, Needs review, Processing, and Received.

The Shipments page on the Outbound tab, listing each shipment with its recipient team, status badge, and number of items in the manifest — Each row shows the other team, the shipment's status, and how many items are in its manifest. The Outbound and Inbound tabs each have their own status filters.

Every shipment carries a status: Draft, Awaiting response, Changes requested, Processing, Completed, Rejected, Canceled, Processing failed (retrying), or Abandoned. A stepper on the detail page tracks progress through Draft → Sent → Processing → Complete.

The life of a shipment. The receiving team can accept, reject, or request changes; a failed transfer can be retried or abandoned, and an unaccepted shipment can be canceled.

Read this lifecycle as text

Main path: Draft → send → Awaiting response → accept → Processing → automatic → Completed.
The receiving team requests changes: Awaiting response → Changes requested, then edit and resend returns it to Draft.
You cancel before a response: Draft or Awaiting response → Canceled. This ends the shipment.
The receiving team rejects it: Awaiting response → Rejected. This ends the shipment.
Transfer fails during processing: Processing → Processing failed (retrying). From there, retry returns it to Processing, or abandon ends it as Abandoned.

Messages

Each shipment has a Messages panel both parties can post to. Anyone at the other team can read what you post there. Responses — rejections, change requests, abandonments — also appear here with their notes.

ConnectionsThe team-to-team link a shipment travels over — direction controls who can send.

FabricWhere the transfer is recorded as permanent lineage on both sides.

DisclosuresPush later updates from your source threads to the receiving team.

AssembliesShip an assembly and its parts together, or detach parts first.

Download receipts

Choose Download receipt on a shipment to save a PDF with its current status, sender and recipient information visible to you, status messages, thread manifest, and permitted thread details and transaction logs. A pending shipment uses the offered copy and disclosure snapshots. Other states include thread records you can currently access. Recipient receipts do not expose concealed draft contents; sender receipts do not expose recipient-only records.

Private data is excluded by default. Where your Team owns accessible thread records, you may choose to include their private data; every page is then marked Proprietary with your organization’s name. Pending offered snapshots remain limited to the shipment’s existing disclosure rules. Dates use your browser’s time zone with UTC offsets.

The PDF includes a generation timestamp and a QR link to the shipment. It is an unsigned snapshot, and downloading it does not add a transaction log entry. See Download receipts for file and thread receipts.

Report a documentation issue