Introduction
Just pouring POS and EC transactions straight into the CRM won't do.
Deciding "which part of a transaction goes into which CRM property" — that mapping design is the heart of this whole sync.
This article explains how a single transaction is broken into three objects — Deal, Contact, and LineItem — and what properties each should carry. Design it carefully, and later analysis and campaigns get much easier.
Breaking one transaction into three
Why break it up
A single POS receipt or EC order actually packs several kinds of information: "the transaction itself," "the buyer," and "the line items of what was bought." Held as one monolith, it becomes painful later when you want to aggregate "by product."
One record per transaction, product names listed as text. No product-level analysis
Deal, Contact, and LineItem, related together. Freely cross product, customer, and amount
Since the CRM already has a structure of "attach line items to a transaction," aligning naturally with it ends up being the easiest form to work with.
How the three objects relate
The three parts relate with the Contact as the parent. It's a nested structure: Deals hang off a Contact, and LineItems hang off a Deal.
One customer matched by email and customer number
One purchase. Holds amount, purchase date, channel
A row per purchased product. SKU, quantity, unit price
With this structure, you can trace purchases from the customer's view, the Deal's view, or the product's view.
Deal properties and pipeline design
Holding amount, purchase date, and channel
The Deal carries the basic facts of that transaction: amount, purchase date, and an attribute distinguishing "store or EC." Channel especially becomes an axis for later cross-channel analysis, so always hold it as an independent property.
The key is holding an external transaction ID — it acts as the idempotency key that prevents registering the same transaction twice.
Thinking about pipeline and stage
A CRM Deal is originally meant to track deal progress (stage). But when you're loading "already-confirmed sales" like here, you treat it less as progress and more as a record of a completed transaction.
So prepare a dedicated pipeline for the sync, and load everything fixed to a "purchase complete" stage by default. Keeping it separate from your sales-opportunity pipeline makes both reports and operations clearer. If you want to handle returns or cancellations, add dedicated stages for them.
LineItem and matching design
How to build line items
A LineItem corresponds to one product row within a transaction. Give it product name, SKU, quantity, and unit price, and ideally link it to the CRM's product master (Product).
Anchor on SKU
Product names are prone to notation drift, so use SKU as the primary key for matching LineItems and linking to the product master. Treat the product name as display-only, and later aggregation won't wobble.
Holding quantity and unit price separately lets you use them directly for product-level analysis like "how many of this item sold cumulatively."
Matching keys for the Contact
The buyer is matched to an existing Contact using email as the primary key and membership number (customer number) as the secondary key. If neither matches, a new Contact is created.
This key design greatly affects sync accuracy. Rely on just one, and the same person splits apart due to email changes or separate store/EC registrations. Using multiple keys and matching in a set priority order was the practical landing point.
Conclusion
The essence of mapping transaction data is to break one transaction into Deal, Contact, and LineItem, giving each the right properties. Idempotency via the external transaction ID, SKU-anchored LineItems, and multi-key matching — design these three carefully and operations stay stable.
Next, see Owner map operation for assigning reps per store, and the Dry Run procedure for safe production rollout. Returning to the hub article helps you grasp the whole picture.