Default field map
| HighLevel field | Consuelo field | Notes |
|---|---|---|
| firstName | firstName | stored as a string |
| lastName | lastName | stored as a string |
| used for dedupe when phone is not enough | ||
| phone | phone | normalized before comparison and storage |
| address1 | address | stored as a string |
| city | city | stored as a string |
| state | state | stored as a string |
| postalCode | zip | stored as a string |
| source | source | stored as a string |
| dnd | dncStatus | converted to a boolean |
Phone normalization
Phone values are normalized before they are compared or written into the CRM. That is what allows the sync flow to match records reliably even when HighLevel and Consuelo display the same number differently.Custom fields
If a HighLevel contact includes custom fields, Consuelo keeps those values under keys shaped like custom_field-id. That allows the integration layer to retain custom field data instead of dropping it during the map step.What to review before your first import
- make sure your CRM already has the destination fields you care about
- verify how do-not-contact values should behave in your workflow
- test a small import first if your HighLevel data has inconsistent phone formats
The current settings screen shows whether field mappings are available after connection. The mapping behavior itself is driven by the integration’s built-in mapper.