A Salesforce CRM implementation for a brokerage is ready to launch when a sample borrower file moves from first enquiry to a recorded lodgement handoff. Along the way, only the right staff can see it, and the right checks stop it when consent or documents are missing. Decide which Salesforce object holds the borrower, the loan application and the settled loan before anyone builds a field. Changing that design after launch means moving every record again.
Define the Salesforce Launch Outcome
Write down the broker tasks Salesforce will support before configuration starts, and name one person who owns the process. That owner decides what the file stages mean, approves each change and signs off the release. An implementation partner can build the system, but the brokerage owner or practice manager decides when it is accepted.
Broker Tasks the Launch Supports
- Record a new enquiry and assign it to a broker.
- Capture the borrower’s privacy consent and credit-check consent before work starts.
- Collect and store the documents each application needs.
- Move the file through its stages to lodgement with the aggregator.
- Record settlement and schedule the post-settlement review.
Prerequisites Before Configuration
- Licences for every broker and administrator, on an edition that has the features you plan to use. Person accounts, for example, are available on Professional, Enterprise, Performance, Unlimited and Developer editions, according to Salesforce’s person accounts setup guide.
- One administrator with full system administrator access, plus a second person who holds a backup administrator login.
- A sandbox or other non-production org for building and testing. Include one in the licence order if your edition doesn’t already have it.
- Approved sample data: fictional borrowers, or real records the brokerage’s privacy officer has approved for testing.
Go-Live Acceptance Criteria
Write each criterion as a result a person can observe on screen. “Brokers can find their clients” is too loose to test. “Broker A sees all of Broker A’s open files and none of Broker B’s” passes or fails on screen. Write every criterion this way and list them in the release plan before the build starts.
Design Salesforce Records and File Stages
Map each thing the brokerage tracks to one Salesforce object, then list every field in a field dictionary. Salesforce’s standard objects cover people, applications and activities. Custom objects cover what a sales CRM doesn’t include out of the box, such as a settled loan or a consent record.
Object Map for a Brokerage
| Brokerage record | Salesforce object | Why |
|---|---|---|
| Borrower | Person account | Combines account and contact fields into one record for an individual |
| Related borrower, guarantor or referrer | Person account, linked through Contacts to Multiple Accounts or an opportunity contact role | Records how each person relates to the file without merging them |
| Loan application | Opportunity | Its stages track the file from enquiry to settlement |
| Settled loan | Custom object, such as Loan | Holds the lender, balance, settlement date and review date after the opportunity closes |
| Consent | Custom object, such as Consent, related to the person account | Keeps each consent as its own dated record, so later consents don’t overwrite earlier ones |
| Calls, emails and meetings | Tasks and events | Standard activity records linked to the borrower and the opportunity |
Enabling person accounts is permanent. Salesforce’s setup guide says that once person accounts are enabled, they can’t be disabled. It recommends previewing them in a sandbox first. Make that choice early and test it.
Field Dictionary
The field dictionary lists each field with its object, type, the role that maintains it and the stage at which it becomes required. This sample covers part of a loan application.
| Field | Object | Type | Maintained by | Required from stage |
|---|---|---|---|---|
| Lender | Opportunity | Picklist | Broker | Preparing application |
| Loan purpose | Opportunity | Picklist | Broker | Fact find |
| Consent current | Opportunity | Checkbox, set by automation | Automation | Documents requested |
| Aggregator application reference | Opportunity | Text | Lodging broker | Lodged |
| Settlement date | Loan | Date | Administrator | Settled |
| Next review date | Loan | Date, calculated | Automation | Settled |
Leave trail commission tracking out of the Loan object. Track My Trail reads the aggregator’s monthly reports and shows which clients discharged, refinanced or dropped off, so the CRM doesn’t need its own commission build.
Relationships, Owners and Stages
Three concepts often get mixed together in a brokerage design, and each answers a different question.
- A relationship answers who is connected to the file. A co-borrower is linked to the opportunity as a contact role.
- The record owner answers who is responsible. The owner is the broker managing the file, and ownership drives what other staff can see.
- The pipeline stage answers where the file is, from enquiry through to settled.
Incorrect: a “Co-borrower” stage in the pipeline. A co-borrower is a person, so they belong in a relationship. Correct: add the co-borrower as a contact role and keep the stage at “Fact find”.
Record settlement by moving the opportunity to a closed stage named “Settled”. A record-triggered flow then creates the Loan record with the settlement date and the next review date. Record each review as a task on the Loan, so the history of reviews stays with the loan.
Configure Permissions and Workflow Controls
Salesforce controls data access in layers: who can use each object, which fields they see and which records they can open. Salesforce’s data security module recommends permission sets and permission set groups for object and field access. Use profiles for the baseline each user type needs, then grant brokerage roles through permission sets.
Access Design for Broker Records
| Layer | Brokerage setting | Result |
|---|---|---|
| Org-wide defaults | Private for accounts and opportunities | Each broker sees only the files they own by default |
| Role hierarchy | Principal above the brokers | The principal sees every file owned by brokers below them |
| Sharing rules | Share files with the administrator team | Administrators can update documents and stages on every file |
| Field-level security | Hide identity document numbers from staff without a need | Those staff can open the record without seeing the field |
| Manual sharing | Owner shares one file during leave | A covering broker sees that file and no others |
Decide who approves changes to these settings. A sharing rule that widens access changes who can see borrower records. The process owner approves it in writing before the administrator saves it.
Validation and Automation Checkpoints
Validation rules stop a save. When a rule’s formula is true, the record isn’t saved and the user sees the rule’s error message, as Salesforce’s validation rules unit shows. Duplicate rules use matching rules to find likely duplicates, then alert the user or block the new record. Record-triggered flows run when a record is created or updated.
| Checkpoint | Control | Expected record state |
|---|---|---|
| Duplicate borrower | Duplicate rule set to block, using a matching rule on name, email and mobile | No second person account exists, and the user is shown the existing borrower |
| Missing consent | Validation rule that requires the “Consent current” box before the stage passes “Documents requested” | The stage stays where it was, and the error says consent is missing |
| Failed stage change | Validation rule that requires the aggregator application reference at “Lodged” | The opportunity stays at its previous stage and the error names the missing reference field |
| Failed automation | Fault path on the settlement flow that emails a named administrator | The opportunity is settled with no Loan record yet. The administrator has the error email |
Salesforce’s duplicate management unit lists duplicate management at no charge on Professional, Enterprise and Unlimited editions. Set the borrower rule to block, because an alert lets staff continue and create the duplicate anyway.
Prove the Aggregator Handoff
The receiving system for a lodged application is your aggregator’s lodgement platform. Don’t assume a direct Salesforce connection to it. The approved transfer route is the one your aggregator supports. For most brokerages, that means the broker keys or uploads the application into the aggregator’s platform and records the result in Salesforce.
Walk an Illustrative File Through the Handoff
This example follows a fictional borrower refinancing an owner-occupied home loan.
- Enquiry: the administrator creates a person account and an opportunity at “Enquiry” and assigns the broker as owner. Check that the broker can see the file and another broker can’t.
- Consent: the broker records the privacy consent and credit-check consent as Consent records. Check that the flow ticks “Consent current” on the opportunity.
- Documents: the borrower’s payslips and statements are uploaded as files on the opportunity. Check that only the owner, the principal and the administrator team can open them.
- Lodgement: the broker lodges through the aggregator’s platform, then enters the application reference and moves the opportunity to “Lodged”. Check that the stage won’t save without the reference.
- Receipt evidence: the opportunity now holds the application reference, the lender, the time of lodgement and the broker who lodged it.
Field Ownership After Lodgement
Once the file is lodged, the aggregator’s platform owns the application’s lender status. Salesforce owns the borrower record, the consent history, the documents collected and the file stage. Write that split into the field dictionary, so staff know which system to update when the lender responds.
Failure Owner and Reconciliation Check
The broker who lodged the file owns a failed handoff. Run a weekly report of opportunities at “Lodged” and compare it with your aggregator’s pipeline report. A file that appears in one and not the other is a failed transfer, and the lodging broker fixes it that week.
Accept the Salesforce Release
Accept the release in the sandbox before any live data moves. Run these steps in order, and don’t start the next one until the current one passes.
- Sample migration: import a small file of approved sample records. Salesforce’s data import unit says the Data Import Wizard handles up to 50,000 records at a time and advises testing with a small file first.
- Role checks: sign in as each role in turn (broker, administrator and principal). Confirm each sees exactly what the access design says.
- End-to-end file acceptance: run the illustrative file from enquiry to settlement and confirm the Loan record and review date appear.
- Exception repair: fix every failed test, then rerun the whole sequence, because one change can break another rule.
- Controlled cutover: freeze changes in the old system, run the final import, compare record counts and switch staff over the same day.
The full migration runbook, including reconciliation and cutover protection, is in the guide to CRM migration.
Expected Results for Release Tests
| Test | Setup | Expected result |
|---|---|---|
| Duplicate borrower | Create a borrower with the same name, email and mobile as an existing one | Salesforce blocks the save and shows the existing borrower |
| Restricted staff member | Sign in as a broker who doesn’t own the file and open its link | Salesforce refuses access to the record |
| Failed transfer | Move a file to “Lodged” with no application reference | The save fails with the error, and the file stays at its earlier stage |
| Export with relationships | Run a full data export and open the opportunity and Loan files | Each record carries its own ID and the IDs of its linked borrower and opportunity |
Salesforce’s data export unit explains the Data Export Service. It delivers CSV files in a zip archive. Enterprise, Performance and Unlimited editions can export weekly, while Professional can export every 29 days. Attachments and documents are included only when you select them, and the zip files are deleted 48 hours after the email is sent.
Train Staff and Support the First Files
Train each role on the tasks it does in the brokerage’s own Salesforce org. A broker practises taking over an assigned enquiry and moving a file to “Lodged”. An administrator practises assigning an enquiry, updating a file’s documents and correcting a failed automation from the fault email. The principal practises reading the pipeline and the weekly lodgement report.
Trailhead, Salesforce’s free learning site, is optional support for the administrator. Its Admin Beginner trail covers data modelling, data management and reports. A Trailhead badge shows the learner finished a module. It doesn’t show that the brokerage’s records, permissions and handoff pass their acceptance tests. Plan wider role-based sessions with the guide to CRM training.
Support the first files closely. For the first two weeks, the administrator checks each new file at every stage, logs each problem and fixes it in the sandbox before changing the live org. When the first files reach settlement with their Loan records and review dates in place, the brokerage owner signs off the implementation. If you are choosing a partner to build it, the guide to CRM implementation covers scope and supplier acceptance terms.
