Map columns, resolve duplicates and commit batches
Only valid staged rows are eligible for commit.
Before you start
Only valid staged rows are eligible for commit. Review mapping and duplicate reasons before creating any native records.
Follow these steps
- In Column mapping, choose the source column for each supported target field.
- Choose Save mapping & revalidate.
- Inspect Normalised data and Validation / duplicate reason for every exception.
- Correct source data or mapping; do not change a real identity merely to evade a duplicate flag.
- Choose Commit validated rows and review the confirmation describing up to 200 rows.
- Reopen the batch, verify native targets and repeat only for remaining valid rows.
Check it worked
Committed rows retain their target IDs and remain immutable. Duplicate, invalid or failed rows need a specific review decision.
If something does not look right
Duplicate checks use exact implemented keys and cannot identify every real-world duplicate. They include property description; contact email/company; tenancy property/tenant/reference or start; compliance property/type/certificate; and maintenance property/subject/date.
Questions and answers
Can I remap committed rows?
Committed rows are retained rather than rewritten by revalidation.
Why is a numeric property reference resolving unexpectedly?
A positive all-digit reference is interpreted as the native property ID, not a display code. Use a verified unique nonnumeric code or the exact native ID.
What if two properties have the same name/code?
Ambiguous references fail closed. Correct the reference through the supported property workflow rather than relying on the first match.