Mortgage origination is one of the most operationally demanding workflows a bank runs. Each application touches a dozen systems, a half-dozen roles, and a defined regulatory timeline. The loan officer who manages the relationship competes with the operations team that processes the paperwork, the underwriter who decides risk, and the closing team that books the loan. The customer experience holds up or breaks down on how well these handoffs are choreographed.
Financial Services Cloud (FSC) ships a mortgage-specific data model that orchestrates this workflow. The model is opinionated. The integration design is where the real engineering happens.
The data model
FSC's mortgage origination uses five primary objects:
- Lead. The initial prospect record, sourced from marketing campaigns, branch walk-ins, or partner referrals.
- Opportunity. The converted Lead, with the loan amount, the property, and the indicative terms.
- Loan Application. The formal application record once the customer has consented to a hard credit pull and committed to the application.
- Document Checklist. The list of supporting documents the application requires (income proofs, identity documents, property valuations, insurance evidence).
- Disbursement. The future-state record that captures the funding once the loan closes.
Each object carries the standard FSC fields plus mortgage-specific fields: property type, property value, loan-to-value ratio, debt-to-income ratio, interest rate, term, amortisation schedule.
The lead-to-application transition
The first quality gate in mortgage origination is the Lead-to-Opportunity conversion. Marketing-sourced Leads typically convert at low single-digit percentages. Branch and referral Leads convert higher. The conversion criteria need to be clear, or loan officers waste hours on Leads that were never going to qualify.
A standard Lead qualification checklist:
- Verify the customer is a real prospect (real contact details, real property).
- Estimate the loan-to-value ratio from a self-reported property value and loan-amount.
- Estimate the debt-to-income ratio from self-reported income and existing debt.
- Score the Lead based on these estimates.
- Convert Leads above a threshold to Opportunity. Hold Leads below the threshold for nurture.
The qualification logic lives in a Flow or in an Apex class that runs at Lead creation. The output sets a Lead Score field and routes the Lead to either an Opportunity-conversion queue or a nurture-campaign queue.
Pre-qualification calculations
Once a Lead becomes an Opportunity, the customer expects a pre-qualification answer. Two calculations dominate:
Loan-to-Value (LTV). Loan amount divided by property value, expressed as a percentage. Most banks have an upper limit (often 80% for primary residences, lower for investment properties). A formula field on the Opportunity object computes LTV from the loan-amount and property-value fields.
Debt-to-Income (DTI). Total monthly debt obligations divided by monthly gross income. Banks have product-specific DTI thresholds (often 43% for conventional mortgages, higher for government-backed products). A formula field computes the candidate's DTI from the income fields and the existing-debt fields.
Both ratios drive an automated pre-qualification status: Qualified, Conditionally Qualified, Not Qualified. The status appears on the loan officer's screen immediately after the Opportunity is created with sufficient data.
The pre-qualification is not the underwriting decision. It is a directional answer that filters obviously-no Opportunities from obviously-yes ones. The actual underwriting comes after the Loan Application is submitted and the supporting documents are collected and verified.
The Loan Application object
Once the customer commits, the Opportunity converts to a Loan Application. The Loan Application carries:
- The legal application data the bank's regulator requires.
- The customer's signed consent for the hard credit pull, the income verification, and the property valuation.
- A status field that tracks the application through its lifecycle: Application Received, Documents in Collection, Underwriting in Progress, Approved, Approved with Conditions, Declined, Withdrawn, Closed.
- The link to the Document Checklist.
The status field is the operational heart of the workflow. Each status corresponds to one or more team queues: Documents in Collection is the operations queue; Underwriting in Progress is the underwriter queue; Approved with Conditions is the back-to-customer queue. Status changes drive notifications to the appropriate team and to the customer.
Document collection
Document collection is where most mortgage applications stall. A typical mortgage requires 15 to 25 documents: pay slips, bank statements, tax returns, property documents, identification, insurance. The customer has to gather them. The operations team has to verify them. The underwriter has to evaluate them.
FSC ships a Document Checklist object that supports this workflow. Each Loan Application links to a checklist of expected documents. Each document carries a status: Requested, Received, Verified, Rejected. The checklist appears on the loan officer's screen as a real-time progress view.
Three patterns make document collection work better:
Customer self-service portal. The customer uploads documents to a portal that ties directly to the Document Checklist. Status updates flow back to the customer automatically. The bank's operations team picks up the uploads from a verification queue.
Document templates and auto-routing. Common document types (Form 16, salary slip, last 6 months bank statement) get pre-mapped to specific checklist items. The auto-routing reduces the operations-team effort to match uploads against expected documents.
Stale-document alerts. A Document Checklist item that has been Requested for more than 7 business days triggers a follow-up alert to the loan officer. Stale documents are the leading indicator of application abandonment.
Integrations that decide the experience
The mortgage workflow depends on several integrations:
Credit bureau. The hard credit pull happens once the Loan Application is submitted. The integration calls the credit bureau API, retrieves the report, and writes the relevant fields to FSC.
Income verification provider. Third-party providers verify employment and income directly with the employer. The integration runs asynchronously and writes the verified-income field once the response comes back.
Property valuation provider. Automated valuation models (AVMs) provide a property valuation. The integration calls the AVM service, retrieves the value, and writes the verified-property-value field.
Core banking system. Once the loan is approved, the booking integration creates the loan account in the core banking system. The Disbursement record gets created with the funding schedule.
Each integration has a defined cadence and a defined error-handling path. The integrations that fail silently are the ones that produce the worst customer experiences: a borrower whose income-verification request got lost waits days for an answer that never comes.
Compliance overlays
Mortgage origination carries regulatory obligations that the data model must support:
Equal Credit Opportunity Act and analogous rules. The reasons for any Declined or Conditionally Approved decision must be documented and disclosable to the customer. A Decision Rationale object captures the decision factors, with a structured taxonomy that supports regulatory reporting.
Customer disclosures. Many jurisdictions require specific disclosures at specific stages: pre-application, post-application, pre-closing. The workflow ensures each disclosure is generated, delivered, and acknowledged.
Anti-money-laundering review. Large loan amounts trigger AML review. The plan template for AML-flagged applications adds review tasks for the compliance team before the underwriting decision.
Each compliance overlay adds complexity to the workflow. The implementation team has to balance the rigorous compliance pattern with the customer-experience need for speed.
Cycle time as the metric that matters
The metric that dominates mortgage-origination platform performance: application-to-decision cycle time. The faster the bank gives the customer an answer, the higher the conversion rate and the better the customer experience.
The FSC implementation that minimises cycle time does three things well:
- Document collection is mostly automated through the customer portal.
- Verifications run in parallel rather than sequentially.
- Status transitions trigger immediate next-step actions rather than batched daily reviews.
A mortgage workflow that takes 30 days end-to-end is competitive. A workflow that takes 15 days wins business. The data model and integrations are what determines which side of that line the bank lands on.
Building the mortgage origination workflow on FSC? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs Mortgage data-model architecture, integration design, and cycle-time optimisation on every FSC engagement. Get in touch ->
See our Salesforce service page for the team.
