Field Mapping Notes

Overview

Field Mapping Notes are where the branch and Implementation document, entity by entity and field by field, whether the data exists in the source system and how it should be interpreted. This is Phase 2 of the process — it begins as soon as source data access is established and continues as a living reference alongside ingestion.

The notes inform the transformation logic the ingestion team writes. Unavailable fields are flagged early so Implementation can plan a workaround or accept the gap before it becomes a blocker.

Open it at Setup → Field Mapping Notes.

Who does this

Field mapping is a collaboration. The branch knows the source system and where each field lives; Implementation explains what each C3 entity and field is for. Engineering (App & Schema) facilitates. How much can be done by Engineering alone depends on how well-known the source schema is — new or complex systems need more branch involvement.

Availability states

Assess each field's availability as one of:

• Available — the data exists and can be mapped, directly or with a simple transformation.
• Quasi-Available — the data exists but needs transformation, cleanup, or enrichment, or is incomplete.
• Not Available — the data does not exist in the source system.
• Unknown — availability has not been determined yet (the default for a new assessment).

Working through the entities

Walk the entities one at a time and, for each field:

1. Set its availability state.
2. Add mapping requirements notes — where the data lives in the source system, any transformation needed, and the business rules that apply.

Use the filters and search to focus on a single entity, a status, or a specific field. A stacked bar visualization shows completion across entities so you can see how much of the assessment remains. You can export to CSV for offline review with stakeholders.

The full list of entities and fields you're assessing against is browsable in the Entity Explorer — schema, field requirements, and validation rules per entity.

Writing useful notes

Be specific enough that someone without the conversation can act on the note.

Good:
- "Source: CUST_NAME. Concatenate FIRST_NAME + ' ' + LAST_NAME."
- "Source: UNIT_SIZE (varchar). Strip commas and ' sq ft', cast to integer. ~5% NULL — needs cleanup."
- "Not in the source system. Collect via post-migration survey; use the manager email as interim contact."

Less useful:
- "From the customer table."
- "Needs work."
- "TBD."

Record the decision and the reasoning, not just the source column — including why a particular mapping or workaround was chosen.

Working the assessment down

• Resolve Unknown statuses first — they hide risk.
• Address Not Available fields early, while there's still time to plan a workaround.
• Prioritize the entities that matter most (associations, units, accounts) and their required fields.
• Keep the notes current as you learn more about the source system.

Completion

The phase is complete when every entity has been assessed and mapping ambiguities are either resolved or documented with a decision. The notes then stand as the reference that drives transformation logic during ingestion and feed the Field Mapped state in the migration lifecycle.

Related

• Required Data — what data a successful onboarding needs.
• Entity Model — how entities relate and load.
• Entity Explorer — the live per-entity field catalog.