How to map CRM and aggregator fields

The software can move a value from one column to another. It cannot decide whether `Loan Type`, `Product Type`, `Purpose` and `Scenario` mean the same thing in your brokerage.

Make that decision before building the automation.

Export a safe sample or an empty CSV template from the aggregator or lodgement platform. The header row gives you the language and structure used by the application authority.

Common concepts may include first name and surname, email and phone, applicant role, loan purpose, occupancy or investment purpose, requested amount, credit-decision or application status, settlement date, lender, referral source, and file or application identifiers.

Do not assume the headers are identical across aggregators, versions or export types. Inspect the file, and retain its export date and source.

Then export or catalogue the CRM fields. HighLevel’s published import flow maps CSV columns to existing standard or custom fields, and requires non-standard destination fields to exist before the import is completed.

The aggregator can contain fields the CRM does not need. Classify every source column.

This prevents the CRM from becoming a copy of an application database it was never designed to replace.

The fastest way to create bad data is to put a deal field on the contact.

Contact fields

These follow the person:

• legal or preferred name;
• phone and email;
• preferred contact method;
• contact consent and suppression;
• date of birth, only where the approved CRM boundary permits it;
• relationship or referral history; and
• stable external person IDs.

Opportunity fields

These follow one scenario or deal:

• loan purpose;
• requested amount;
• occupancy;
• property or security context;
• opportunity source;
• pipeline stage;
• assigned broker;
• application ID;
• settlement date; and
• referral partner for that deal.

One person can refinance today and buy an investment property later. If both scenarios write into one contact-level `Loan Purpose` field, the second deal rewrites the history of the first.

Application authority fields

Some detailed application, compliance and lender fields should stay in the aggregator or approved lodgement system. Store the external application ID and link, rather than duplicating every field.

The dictionary is the agreement between systems, staff and automation.

Add description, sensitivity, source timestamp, owner and retirement status where useful. The visible label should be simple enough for staff; the internal key should be stable enough for workflows and integrations.

The source fields below are illustrative. They are not actual fields from a named aggregator.

Dropdowns and status fields need a translation table.

Store the raw source value where audit and troubleshooting require it, while presenting the simpler approved label to staff.

Every mapping needs a direction: aggregator to CRM, CRM to aggregator, a one-time migration, a read-only reference, or a human-approved sync.

Then define the event: contact created, form submitted, application created, application submitted, stage changed, settlement confirmed, or scheduled reconciliation.

Avoid uncontrolled two-way sync. If both systems can write the same field without precedence, the last technical update may defeat the correct business value.

Create a custom field only when:

• the business concept is real and defined;
• no standard field already carries it;
• the correct object is known;
• the type and allowed values are stable;
• a team member or workflow will use it; and
• its authority and retirement path are documented.

HighLevel distinguishes contact and opportunity custom fields. Its published guidance notes that a field created under one object cannot simply be switched to the other later.

Use folders such as Contact Preferences, Referral and Source, Scenario Summary, Property and Purpose, Application Reference, and Settlement and Review. Do not create folders that duplicate every form name — forms are sources, fields are business concepts.

If an abbreviation such as `AOL` or `MIRS` is retained, define it in the field description and the team knowledge base.

Build a small test pack containing:

• one applicant;
• two applicants;
• one contact with two opportunities;
• self-employed and PAYG scenarios;
• blank optional fields;
• an unknown dropdown code;
• Australian and international phone formats;
• a name with an apostrophe or hyphen;
• an invalid date;
• a zero value versus a blank;
• a duplicate email with a different phone; and
• long notes.

Then test:

1. import into a safe environment;
2. inspect every mapped field;
3. confirm contact and opportunity records link correctly;
4. export the records again;
5. compare the result with the source;
6. run the workflows that depend on the fields;
7. confirm no sensitive field leaked into an email or message; and
8. document every exception.

HighLevel’s current contact import process matches existing contacts in the order contact ID, email, then phone by default, subject to account settings. That deduplication behaviour must be tested against the brokerage’s own duplicate rules.

Use these columns, and review the sheet before changing a form, pipeline or workflow. Automations consume the data model; they should not invent it.

• source system, export version, field key, description, type and allowed values;
• destination system, object, field key and type;
• transformation or value map;
• direction;
• trigger or timing;
• authority and owner;
• blank or null rule;
• duplicate rule;
• sensitivity;
• test case; and
• status.

One concept. One name. One owner.

Export the real headers, simplify the business vocabulary, preserve the source meaning, and make every transformation visible.

The cleaner the map, the less software knowledge the broker needs to operate the business.