Field mapping

A field mapping is a claim about meaning: this value in one system is that value in another. PartnerMCP proposes every mapping with a confidence and a reason, and you review them before anything is built. The worked example on this page is Salesforce → Priority ERP, because it shows why matching on names is not enough.

Names are not meaning#

Ask a string matcher where Account.Name should go in Priority and it will pick CUSTOMERS.CUSTNAME. That is wrong. In Priority, CUSTNAME is the Customer Number — the record's key, at most 16 characters. The customer's name is CUSTDES.

Writing company names into a key breaks lookups, links and every report that groups by customer. PartnerMCP chooses a target from what the metadata says a field means, not from what the field is called.

Where the evidence comes from#

• Metadata. Types, lengths, keys and descriptions. Priority annotates every column with its title (Priority.OData.Description) and, from version 25.1, marks required columns (Priority.OData.Mandatory).
• Sandbox records. Real values show real formats — country names versus ISO codes, padded tax numbers, decimal conventions.
• Documentation. The vendor's object references and the system's own help text.
• You. Questions the data can't settle — which system owns pricing, how to recognise an existing customer — are asked, not guessed.

Confidence and review#

Each proposed mapping carries a confidence and a one-sentence reason. Clear mappings arrive pre-selected for your review; ambiguous ones arrive as questions; nothing is applied silently. Mappings live in the spec, so changing one later is a diff like any other change.

Salesforce → Priority, field by field#

Keys and identity#

Priority assigns or validates CUSTNAME, so the durable link is to store it on the Salesforce Account — in an External ID field such as Priority_Customer_No__c — and match on it in later runs. The 18-character Salesforce Account ID doesn't fit a 16-character key. If Priority must hold the Salesforce ID as well, it goes in a custom column carrying the customer's four-letter prefix, such as XXXX_SFACCID, and the API metadata is refreshed with ClearEntityMetadata.

Values you shouldn't write#

Some fields are outputs. ORDERS.TOTPRICE is the order's final price including tax, computed by Priority; writing it makes Priority back-calculate the discount and the tax. Opportunity.Amount, meanwhile, is a pre-tax sum of products. So PartnerMCP sends the lines, lets Priority price and tax them, reads back DISPRICE (the total before tax), VAT and TOTPRICE, and reconciles DISPRICE against Opportunity.Amount. A difference — a header discount, rounding, a price-list override — is flagged, never overwritten.

Transformations in the spec#

mappings:  - from: Account.Name    to: CUSTOMERS.CUSTDES    confidence: 0.98    reason: CUSTDES is the customer name; CUSTNAME is the customer number  - from: Account.BillingCountryCode    to: CUSTOMERS.COUNTRYNAME    transform: iso-country -> tenant-country-list  - from: Opportunity.Amount    to: null                      # not written — Priority computes totals    reconcile: ORDERS.DISPRICE

Transformations are explicit steps — lookups against a reference list, unit and decimal conversions, dates and time zones — so a reviewer can see exactly what happens to a value on its way across.