Logistics and distribution

Multi-client WMS data: preparing records without exposing other clients

By SourceX Editorial · Updated October 9, 2026

Short answer

Preparing multi-client WMS data means isolating each permitted client's records by client or owner ID, then handling the objects clients share, such as waves, locations, labor tasks and dock appointments. Mask shared fields, scan free text and run leakage tests before release. A client whose agreement does not allow use stays out entirely.

Key takeaways

Filter at the source by client or owner ID, not after export, so excluded clients never enter the working set.
Shared objects such as waves, locations, labor tasks and appointments carry other clients' data and need their own treatment.
Free-text notes and attachments are the most common source of cross-client leakage.
Automated leakage checks plus a documented human review should sign off every release.

Why multi-client WMS exports leak other clients' data#

Multi-client WMS exports leak because a shared warehouse runs on shared objects: one wave can pick orders for several clients, one location can hold inventory from more than one owner, and one labor log covers a whole shift. Filtering the order table by client ID leaves those shared objects untouched.

Leakage also hides in less obvious places: a receiving note that mentions another client's late trailer, a cycle count adjustment report that lists every owner in an aisle, or a billing export keyed by facility. An IT director preparing records has to treat the database as a web of joins, not a set of client folders.

Map which WMS records are client-scoped and which are shared#

WMS records fall into client-scoped tables, which carry a client or owner ID on every row, and shared tables, which describe the facility, labor or equipment. The map below is a starting point; field names differ between WMS products such as Manhattan, Blue Yonder, Körber, Deposco and Extensiv, so confirm against your own schema.

Map which WMS records are client-scoped and which are shared
Record	Scoping	Leakage risk	Usual treatment
Item master and SKUs	Client-scoped	Low once filtered	Filter by client ID; tokenize SKUs if required
Orders, shipments and ASNs	Client-scoped	Consignee and carrier details	Filter, then mask consignee fields
Inventory and lot records	Client-scoped by owner	Shared locations reveal neighbors	Filter by owner; generalize location codes
Waves, batches and pick tasks	Shared	Mixed-client waves	Keep only task lines for permitted clients; drop wave totals
Labor and productivity logs	Shared	Employee identity and other clients' work	Pseudonymize user IDs; keep only permitted task lines
Dock appointments and yard records	Shared	Other clients' carriers and trailers	Keep rows linked to permitted orders; drop the rest
Billing and rate tables	Client-scoped but commercially sensitive	Rates agreed with each client	Usually excluded
Notes, exceptions and attachments	Mixed	Free text naming any client	Scan, review, then redact or exclude

01Your work records
02Personal details removed
03You approve the release
04Licensed to AI developers

How it works with SourceX: Your work records → Personal details removed → You approve the release → Licensed to AI developers.Illustrative

Step-by-step: preparing one client's WMS records#

Preparing one client's WMS records follows a fixed order, and each step depends on the one before. Jumping straight to masking, before scope is settled and filtering happens at the source, is how excluded clients end up in the working set.

Confirm scope: list the clients whose agreements permit use, the date range and the record families in scope, and get counsel's sign-off.
Filter at the source: query by client or owner ID inside the WMS database or a read-only replica, so excluded clients never leave the system.
Resolve shared objects: rebuild waves, tasks and appointments from the permitted client's order lines rather than exporting shared tables whole.
Mask shared fields: replace user IDs, consignee names, carrier account numbers and facility identifiers with consistent tokens.
Scan free text: run notes, exception comments and attachments through automated detection, then route every hit to a person.
Test for leakage: run the checks described below and record the results.
Document the release: log the queries, masking rules, test results and who approved.

Masking options for shared fields range from consistent tokens to outright removal, and the right choice depends on whether the field carries analytical meaning. A location code matters for travel-path and slotting analysis; a carrier account number rarely matters at all.

These techniques have shared names in provenance vocabularies. The Data and Trust Alliance's Data Provenance Standards list masking, pseudonymization, redaction and tokenization among recognized privacy-enhancing tools, which helps a 3PL describe exactly what was applied in terms a buyer's reviewers already use.

Masking options for fields clients share
Technique	Good for	Watch out for
Consistent tokens	User IDs, consignees and SKUs that must still join across files	Keep the key table inside your own environment
Generalization	Location codes reduced to zone or aisle type; timestamps reduced to a coarser period	Too coarse and the records lose their meaning
Suppression	Rate fields, account numbers, other clients' names	Dropping a join key can orphan related records
Redaction in text	Notes, emails and exception comments	Automated detection misses names that only insiders recognize

How to verify there is no cross-client leakage#

Verifying there is no cross-client leakage takes automated checks and a person reading samples, because tools find patterns and people find context. Open-source detection tools help, but their makers are candid about the limits: Presidio's documentation states that its automated detection offers no guarantee of finding all sensitive information and that additional protections should be used.

Key check: every row's client or owner ID matches a permitted client.
String search: search the release for each excluded client's name, codes, SKU prefixes and common abbreviations.
Join check: no task, wave or appointment row links to an order outside the set.
Count reconciliation: order and line counts match a report run independently from the WMS.
Sample review: someone who knows the building reads a sample of notes and attachments.

Illustrative: a 3PL prepares two clients' records from a shared building#

Illustrative: a fictional 3PL runs a shared building for several consumer goods and industrial clients on one WMS instance. Two clients' agreements allow de-identified operational use; the others do not. The IT director wants to prepare returns and exception records for the two permitted clients only.

The team queries a read-only replica by owner ID, rebuilds pick tasks from the permitted order lines and tokenizes user IDs and consignees. The first string search finds an excluded client's name in receiving notes, typed by a supervisor who handled both accounts on the same dock. The team adds every excluded client's names and codes to the redaction list, reruns the scan and has the building manager read a sample before approval. Billing tables are left out entirely.

Where the prepared data should live#

Prepared WMS data should stay in the 3PL's own environment until release, with token key tables stored separately from the release files. A WMS history does not need to move onto a third party's servers to be licensed.

Common delivery options include a secured bucket in the 3PL's own cloud account with time-limited access for the buyer, or encrypted drives for very large histories. Whichever route is used, access logs and a record of exactly what was delivered belong with the release documentation. Rerun the leakage checks after any change to the masking rules, because a fix to one field can reintroduce a join that an earlier test had cleared.

How SourceX approaches multi-client WMS records#

SourceX approaches multi-client WMS records with client exclusion built into scope from the start, inside the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The fit check uses metadata only, such as the WMS product, how clients are coded and which agreements permit use, before any query is written.

The SourceX Evidence Packet then records provenance, licensing rights, permitted use, the privacy record, including masking rules and leakage tests, and release authorization. Large datasets stay in the 3PL's own storage or ship on encrypted drives; SourceX does not host multi-terabyte data.

Frequently asked questions

Do excluded clients need to be told their data was filtered out?

Often no notice is needed for data that is never used, though counsel should confirm against each agreement, and some 3PLs explain to every client how records are handled as a matter of trust. If a client asks, a plain description of the filtering and the leakage tests is usually the most reassuring answer.

Can building-level metrics include excluded clients?

Only if counsel agrees the aggregate does not reveal client information and the agreements allow it. Building-level throughput or labor totals can expose a client's volume when only a few clients share a building, so many teams limit aggregates to permitted clients.

What if some WMS tables have no client ID?

Rebuild the link through a related record, such as the order line behind a pick task or the receipt behind a putaway. Rows that cannot be tied to a permitted client are dropped. Document the join logic so a reviewer can check it.

Is a full database export ever acceptable?

Rarely. A full export moves every client's records into a working environment, which widens exposure even if the files are filtered later. Filtering inside the WMS or a read-only replica is safer and easier to audit.

Who should sign off on a release?

Typically the IT director for the technical checks, counsel for scope, and an operations leader who knows the building for the sample review. The company's authorized signer then approves the release itself.

Sources

The Data Provenance Standards' Privacy Enhancing Tools code list includes data anonymization, encryption, masking, minimization, redaction, differential privacy, federated learning, homomorphic encryption, k-anonymity, l-diversity, pseudonymization, secure multi-party computation, t-closeness and tokenization. Source
Presidio's documentation warns that because it uses automated detection mechanisms, there is no guarantee that it will find all sensitive information, and additional systems and protections should be employed. Source

Related resources

See if your company qualifies

A short company assessment. No data uploads are needed.

Assess your company's data readiness Talk to SourceX