Short answer: A mortgage data-ownership map identifies the authoritative system or process for each important field or event, the business owner who can correct it, the systems that may use a copy, and the exception path when records disagree. The map should be small enough for a loan officer to use during a real handoff.
A shared value is not a shared source of truth. The same borrower name, loan milestone, or campaign status can appear in several systems. That does not answer which record is relied on when a value is missing, stale, or contradictory.
In this guide
Map field groups and events before individual fields
Start with the information that changes a person’s next action or a report, rather than trying to document every database field at once. The objective is to make real work reviewable: who can act, why they can act, and where a correction belongs.
| Field group or event |
Decision the team must make |
Evidence to retain |
| Contact and relationship identity |
Which system or accountable process resolves a name, contact detail, relationship owner, or duplicate conflict? |
The authoritative source, correction owner, and duplicate-resolution rule. |
| Lead source and attribution |
Which record establishes how a lead arrived and which reporting use is permitted? |
Source definition, intake owner, and the handling path for a missing or conflicting source. |
| Loan or application milestone |
Which system establishes the status a loan officer may use for a workflow or conversation? |
The source system or process, permitted downstream use, and a late-or-missing update path. |
| Tasks and relationship activity |
Where does the team record the next action, handoff, or completed communication? |
The accountable owner, activity history, and correction path. |
| Marketing audience or campaign status |
Which record determines whether a person belongs in a particular review or audience? |
Inclusion rule, review owner, stop condition, and the source behind the decision. |
Use five columns for every decision
For each field group or event, document five things: the source of truth, systems allowed to receive or use a copy, business owner, correction path, and downstream dependency. A downstream dependency is the action that can go wrong if the value is wrong: an assignment, a message review, a pipeline report, a borrower handoff, or a partner update.
This creates a practical distinction between data movement and data ownership. A system may receive a value without becoming authoritative for it. A useful map states what the copy is for and where a person goes when the copy no longer matches the authoritative record.
Five-record walkthrough
Test the map with five de-identified records or events. The goal is to expose an unresolved decision before a real handoff depends on it.
- New inquiry: Follow source context, first owner, and next action from intake to the working queue.
- Existing relationship: Check how a duplicate or relationship-owner conflict is resolved before a second workflow begins.
- Application or milestone update: Identify the approved source for the changed status and which downstream records may use it.
- Missing or delayed value: Remove one expected value and confirm who notices, corrects, and documents the exception.
- Reporting question: Trace one dashboard or report value back to its event definition and authoritative record.
Write an exception path that a person can use
Every map needs a human path for values that are blank, delayed, duplicated, or contradictory. Name the role that decides whether the source is wrong, the copy is late, or the field is not applicable. Record the reason for the correction and the next review. Repeated exceptions are a signal to revise the intake rule, field definition, or workflow rather than silently patching records one by one.
A data-ownership map is an operating artifact, not a promise that every system connection behaves the same way for every organization. It does not determine retention, security, privacy, consent, licensing, or legal requirements. Those requirements need the policies and qualified review that apply to the organization.
A sample field map with the unresolved items visible
Illustrative design worksheet: This table describes choices a mortgage team could make. It is not a BNTouch, Encompass, or other vendor’s sync specification. Replace each example with the current behavior verified by the people responsible for your systems.
| Field or event |
Example authority |
Correction and downstream check |
| Initial inquiry source |
Original intake event, reviewed by the lead-operations owner. |
Preserve the original source; document a correction without silently replacing acquisition history. |
| Application milestone |
The company’s designated loan record and authorized operations process. |
Resolve a conflict at the authoritative record, then verify each approved downstream use. |
| Relationship follow-up task |
The team’s designated relationship-work system. |
Have the task owner correct the commitment and check duplicate tasks. |
| Communication suppression |
The company’s approved preference and suppression process. |
Confirm how affected channels receive the decision before further outreach. |
| Customer outcome for reporting |
The defined customer-status record, approved by the reporting owner. |
Distinguish a demo, opportunity, and customer; reconcile the report to that definition. |
Separate people from loans in your map. A person may have several applications or relationships. Matching only on a name or email can attach a status to the wrong loan. Record which identifier represents the person, which identifies the application, and who resolves a mismatch. Do not assume the same identifier exists in every connected system.
Document direction, timing, and meaning separately
A field name does not tell you what moves or when. For each important mapping, ask the implementation owner to show the source field, destination field, permitted direction, triggering event, and transformation rule. Record whether the demonstrated value is a live update, an import, or a manually entered example.
Then inspect time. Keep the business event’s time separate from the time another system received it when those values are available. A late-arriving update may describe an earlier event. Ask what happens when updates arrive out of order and which timestamp the team uses to make a decision. Leave unverified behavior marked as a question instead of writing an assumed answer into the map.
Finally, define the meaning of blank values. An empty field might mean unknown, not applicable, not yet received, or a deliberate removal. Those cases require different treatment. Confirm whether a blank can overwrite an existing value and which role may authorize that correction.
Resolve a conflict without creating a second source of truth
Fictional scenario: A relationship record displays an older application milestone while the authorized operations record shows a newer one. A loan officer notices the mismatch before a planned follow-up. The first task is to verify the correct person and application, then identify the authoritative status. Editing whichever screen is closest can conceal the underlying problem.
The operations owner confirms the business status. The technical owner checks whether the downstream copy is delayed, mapped incorrectly, or linked to a different record. The loan officer follows the approved exception process while the mismatch remains unresolved. After a correction, the team checks both the displayed value and any task or communication that depended on it.
Close the issue only when the relevant receiving workflow has been checked. A successful transfer message alone does not prove that the correct value reached the correct application or that an outdated task stopped.
Assign support by the question being asked
- Business meaning: The operations or reporting owner defines what a field or status means.
- Mapping and transport: The responsible administrator or confirmed vendor contact investigates the demonstrated connection.
- Access and permitted use: The organization’s authorized security, privacy, or compliance owner reviews the requirement.
- Customer-facing work: The relationship owner decides the next permitted action using verified information.
Give the technical contact a de-identified record reference, event time, expected result, observed result, and affected workflow. Do not paste borrower documents or unnecessary personal details into a general support channel. Ask the contact how to share any additional evidence through an approved route.
For sign-off, retain the completed mapping worksheet, unresolved questions, and results from controlled normal and exception cases. Define which unresolved items block use and who can accept the remaining limitations. This gives a buyer a concrete way to compare implementations without treating a logo list as proof of field-level behavior.
Use this in a CRM, LOS, or POS evaluation
Bring one field group and one exception case to a BNTouch demo. Ask the team to show the current workflow for the source, permitted downstream use, accountable correction owner, and exception path. Confirm the actual configuration before relying on a cross-system workflow in production.
For the broader buyer checklist, use the mortgage CRM integration checklist. For an Encompass-specific review, use the BNTouch and Encompass integration page as a starting point, then request the current field-level workflow for the environment being evaluated.
This data-ownership map supports the mortgage CRM integration overview by defining the review questions a team should answer before it relies on a cross-system workflow in its own environment. Read the mortgage CRM integration overview for the related owner-page context.
Sources and further reading
