How to decide which system owns each field

Most businesses keep customer, product, order and invoice data in more than one place. Sales works in a CRM. Finance works in an ERP or an accounting system. An online store may hold its own copy of customers and orders.

Agree field ownership and matching identifiers before anyone builds the integration. Then choose how to build it. Once it runs, reconcile the data to check that the systems agree.

Understand what owning a field means

The owning system is where a field is created and changed. Other systems receive a copy and treat it as read-only.

Ownership is set for each field. One system can own a customer's billing address while another owns the account manager. A single customer record can therefore take some fields from each system.

Each owning system also needs a team behind it. If finance owns the credit limit, finance corrects it when it is wrong.

List the fields both systems share

Start with the records that exist in both systems. For most businesses these are customers, contacts, products, orders and invoices.

1. Export the field list for each record type from each system. Use the system's settings or field definitions, and avoid exporting customer records.
2. Put the field lists side by side in one spreadsheet.
3. Mark each field that appears in both systems, even when the names differ.
4. Ask each team which of these fields they read, which they change and which they ignore.

Fields that one team ignores are candidates to leave out of the sync. Fewer synced fields mean fewer conflicts and less personal data moving between systems.

Assign one owner to each field

For each shared field, choose the system where the change happens in real work. Ask who would notice first if the value were wrong.

Example (illustrative): a wholesale business runs a CRM for sales and an ERP for finance and stock.

In this example, the ERP owns fields with a legal or financial effect. The CRM owns sales activity and relationship data. Your split may differ, but each row needs exactly one owner.

Some fields have no clear owner because both teams change them. Phone numbers and delivery contacts are common examples. Pick one owner anyway, and give the other team a way to request changes.

Decide when ownership moves

Some fields change owner as a record moves through a process. A quote that becomes an order is the common case.

While a quote is open, the CRM usually owns its lines, prices and discount. Sales can still change them.

When the customer accepts the quote, the integration creates a sales order in the ERP. From then on, the ERP owns the order lines, prices and status. A later change goes through the ERP's own process, such as an amendment or a credit.

• Name the event that moves ownership, such as "quote marked accepted" or "sales order created".
• Stop the CRM sending changes to those fields after that event.
• Decide what happens if someone edits an accepted quote in the CRM. Either block the edit or flag it for review.

Choose the identifier that links each record

A matching key is the value the integration uses to find the same record in both systems. Choose an identifier that never changes and is unique within the relevant system and entity. Store the mapping between systems.

The usual method is an external ID. When the integration creates a record in the second system, it stores the first system's ID in a dedicated field. Every later update matches on that ID.

Check the scope of each identifier. Values that look unique can repeat or change.

• SKUs can be reused for a new product or renamed when a range changes. If yours can, match on the system's internal item ID and sync the SKU as a field.
• Invoice numbers are often unique only within one legal entity or numbering series. If you run several entities, the key needs the entity as well as the number.
• Deal IDs do not identify orders on their own. One deal can create several orders, such as staged deliveries. Match on the ERP order ID and keep the deal ID as a reference.

Avoid matching on names or email addresses. Two companies can share a trading name, and people change email addresses when they change roles.

For existing records, run a one-off match before the first sync. Review uncertain matches by hand, then write the external ID into each record. Keep any export used for the match in a restricted location, and delete it when the match is done.

Set the sync direction for each field

Once each field has an owner, the direction follows from it. Data flows from the owner to the copy.

A record can still sync in both directions. A customer record can send the account manager one way and the billing address the other. Each field moves in one direction only.

If a field must stay editable in both systems, write a conflict rule. Common rules are "last change wins" or "the owning system wins". The second is easier to explain and to audit.

Sync only the fields each team needs

Every synced field is another copy of personal or commercial data. Keep the list short.

• Leave out fields no one in the receiving team uses.
• Keep sensitive data, such as bank details or tax file numbers, in the owning system only.
• Check that the receiving system's user permissions suit the data you send to it.
• Record why each synced field is needed, so a later review can remove it.

Check the result against your privacy policy and any obligations under the Australian Privacy Principles or other law that applies to you.

Agree the table with every team

Review the draft table with sales, finance and operations together. Resolve any field with two claimed owners in that meeting. Include finance, because it often owns the fields with legal effect.

Then separate the work of keeping the table current from the authority to change it.

Route sync alerts to a queue that a named person works. A shared inbox with no owner tends to leave each failure to someone else. The guide to choosing an integration approach covers which alerts and logs to ask for.

Give each process run one owner

Some processes run across several systems as one orchestrated sequence. For example, an accepted quote can create the ERP customer, the sales order and the first invoice. The run then waits for payment before the service starts.

The orchestration owns the status of the process, meaning which step each run has reached. Each field still belongs to its owning system. The orchestration changes fields through those systems, and your ownership table still applies. If the CRM shows a run's status, treat it as a read-only copy.

Name two people for each orchestrated process:

• A business owner, who approves changes to the steps, waits and timeouts.
• A run handler, with a named backup, who deals with runs that stop or time out.

The guide to choosing an integration approach explains when a process needs orchestration.