Yes, a Notion CRM works for a sole broker or small brokerage, as long as the aggregator CRM stays the record for applications. Using Notion as a CRM suits tracking enquiries, client links and next actions. Notion is a flexible database with no fact find, lender submission or aggregator connection. Beside the aggregator system, it organises the work around each application without replacing the file that proves what was lodged.
Decide Whether Notion Fits Your Client Workflow
Notion fits when the job is organising enquiries and follow-ups, and it stops fitting when staff start keeping the same client details in two places. A mortgage broker CRM supplied by an aggregator handles fact finds, document collection, lender submissions and commission data. Notion can only hold what your team types or imports into it.
When a Lightweight Tracker Is Enough
| Notion as a CRM is enough when | Duplicate file administration outweighs it when |
|---|---|
| One or two people handle every enquiry | Several brokers and assistants work the same clients |
| Most enquiries need a call and a document request before a deal exists | Most enquiries go straight into the aggregator CRM as deals |
| The workspace holds names, stages, owners and next actions | Staff want to copy addresses, incomes and loan details into Notion |
| Someone has time to update statuses from the aggregator CRM each week | Nobody owns reconciling the two systems |
| The brokerage already uses Notion for procedures and team notes | The team would learn Notion only for this |
If most rows fall in the right-hand column, use the aggregator CRM’s own enquiry and task features instead. Every field copied into Notion is another field someone must keep correct.
Structure Clients, Loans and Next Actions
Build three linked databases: Clients, Loans and Tasks. Keeping them separate lets one client hold several loans, one loan link to two applicants and each task point to the record it moves forward. Notion’s relations and rollups guide explains how a relation links items across two databases.
An Illustrative Schema
The schema below is an illustrative starting point for a small brokerage. Rename properties to match your own stages.
| Database | Property | Type | Purpose |
|---|---|---|---|
| Clients | Client name | Title | The person’s full name |
| Clients | Aggregator reference | Text | The client or contact ID from the aggregator CRM, once one exists |
| Clients | Loans | Relation to Loans, shown on both databases | Every loan this client is an applicant on |
| Clients | Owner | Person | The broker accountable for the client |
| Clients | Consent evidence | Text | Where the signed privacy consent is stored, such as a document reference |
| Loans | Loan name | Title | A short label, such as “Refinance, Lee and Park” |
| Loans | Applicants | Relation to Clients | One or more clients, so joint applicants share one loan record |
| Loans | Stage | Status | Enquiry, Documents requested, Broker review, In aggregator CRM, Settled or Closed |
| Loans | Deal reference | Text | The deal ID from the aggregator CRM once the broker creates it |
| Tasks | Task | Title | One action, such as “Request two recent payslips” |
| Tasks | Loan | Relation to Loans, limited to one page | The loan this task moves forward |
| Tasks | Assignee | Person | The staff member who must do it |
| Tasks | Due | Date | When it must be done |
Use the aggregator reference as the stable identifier. Names change and two clients can share one, but the aggregator’s ID matches each Notion record to the authoritative file. Notion lets you limit a relation to one page, which suits the Tasks-to-Loans link because each task belongs to one loan.
Views Organise Work but Don’t Restrict It
Add a board view of Loans grouped by Stage, a “My tasks” view of Tasks filtered to the current user and a Clients table sorted by owner. These views decide what each person sees first.
A filtered view is not a permission. Anyone with access to the database can open another view or search for a client by name. Access is controlled only through sharing settings, covered in the next section.
Starting From the Notion CRM Template
Notion publishes its own Sales CRM template in its template gallery. It is built for a sales pipeline, so treat it as a base and adapt it to the three databases above:
- Duplicate the template into the brokerage’s teamspace.
- Rename its pipeline database to Loans and map its stages to your loan stages.
- Add the Clients and Tasks databases, then create the relations listed in the schema.
- Open each relation’s settings and confirm it shows on both databases.
- Add two fictional clients, a joint loan linking both and a task on that loan.
- Open each fictional client’s page and confirm the joint loan appears on both.
Step 4 matters after any copy. Notion’s help says duplicating a database converts its two-way relations to one-way, so a duplicated template can lose the link from Clients back to Loans.
Control Permissions and Consent References
Give each person the least access their job needs, and review sharing on a fixed schedule. Notion’s sharing and permissions guide lists the access levels and how pages inherit them.
Staff and Guest Access
Keep the three databases in a teamspace limited to brokerage staff. Give the owner Full access and give other staff “Can edit content”, which lets them edit records without changing the database structure, views or filters.
For an assistant who should see only their assigned clients, Notion’s page-level access rules give access based on a Person property, such as Owner or Assignee. These rules need the Business or Enterprise plan. Notion applies the broadest access a person has, so remove teamspace-wide access to the database before relying on a rule.
Guests are people outside your organisation, and they need their own Notion account. Don’t invite clients as guests. Share a single page with an outsourced processor only when the work requires it, and remove the guest when the job ends.
Checking Public Links and Inherited Access
Open the Share menu on each database every month and check General access. It should read “Only people invited”, not “Everyone at” the workspace or “Anyone on the web with link”. Never use the Publish tab for client data, because publishing creates a Notion Site that search engines can index.
Check inheritance too. A page nested under another page takes on the parent’s permissions, so a client page moved under a widely shared page becomes widely shared.
Consent Fields and Consent Evidence
A checkbox that says consent exists is a staff member’s statement. Evidence is the signed privacy consent itself, stored where it can be retrieved and shown to the client, the licensee or a regulator. Use the Consent evidence field to record where that document sits, and keep the document in the brokerage’s approved document system.
Keep identity documents, payslips and bank statements out of Notion uploads for the same reason. They belong in the approved document channel the brokerage already uses.
Notion stores workspaces in the United States by default. Its data residency page lists United States, European Union, Japan and South Korea regions, available on the Enterprise plan. Record that location in your privacy assessment under the Australian Privacy Principles, and confirm your licensee permits client records there.
Keep the Aggregator File Authoritative
The aggregator CRM or lodgement system holds the application, and Notion holds the work around it. Each fact should have one place where it is maintained:
| Fact | Maintained in | What Notion keeps |
|---|---|---|
| Client contact details | Aggregator CRM, once the deal exists | Name and aggregator reference |
| Documents | Approved document system | A task showing they were requested |
| Application, lodgement and approval | Aggregator CRM | Stage and deal reference |
| Signed privacy consent | Approved document system or aggregator CRM | Where the document is stored |
| Client emails | The mailbox or CRM that logs them | Nothing beyond a task that needs action |
| Next actions before the deal exists | Notion | The task, assignee and due date |
For email record ownership, the Gmail CRM guide covers which system holds message history.
Tracing an Enquiry Into the Aggregator File
An illustrative enquiry moves through the two systems in this order:
- A new enquiry arrives, and the assistant creates a Client, a Loan at Enquiry and a task to call the client.
- After the call, the assistant sends the document request through the approved portal and moves the Loan to Documents requested.
- When the documents arrive, the assistant creates a broker review task assigned to the broker.
- The broker reviews the documents, creates the deal in the aggregator CRM and records its deal reference on the Loan.
- From this point, the aggregator CRM holds the fact find, documents, submission and lender correspondence.
What Comes Back to the Workspace
Only two things return to Notion: the deal reference and a stage copied from the aggregator CRM, such as In aggregator CRM, Settled or Closed. Name one person, usually the assistant, to compare Notion’s stages with the aggregator CRM’s pipeline each week. When the two disagree, the aggregator CRM is right and the assistant corrects Notion.
A card in a Notion board column or a ticked task shows only that someone moved it. Lodgement is proved by the submission record in the aggregator CRM and the lender’s acknowledgement, so never report lodged or approved loans from Notion alone.
Validate Sharing, Retrieval and Exit
Run these checks with fictional records before real client data goes in, and again after any change to sharing:
- Joint applicants. Create two fictional clients and one loan with both as Applicants. Each client page should show the loan.
- Multiple loans. Link one fictional client to two loans. The client page should list both, and a rollup counting Loans should show 2.
- Restricted assistant. Sign in as a test staff account limited by a page-level access rule. It should see only clients where it is the Owner, and searching another fictional client’s name should return nothing.
- Departing staff member. Reassign the test account’s tasks, then remove it from the workspace. Notion’s members and guests guide says a removed member loses access immediately and their Private pages are hidden, so no client record should ever sit in a private page.
Export and Relation Limits
Notion’s export guide says a database exports to CSV from its current or default view, not every view. Notion’s relations guide adds that CSV exports show relations as plain text URLs, which can’t be re-imported to restore the links. A full workspace export arrives by emailed link that expires after seven days and leaves out pages the exporter can’t access.
Run a sample retrieval check each quarter. Export the Clients and Loans databases, pick one fictional client and match their loans using the aggregator reference rather than the relation column. If you can rebuild that client’s record from the files, the export is usable.
If the brokerage later moves to a dedicated CRM, expect manual work. Someone must re-link loans to clients by reference, recreate open tasks and attach documents from the document system, as covered in the CRM migration guide. Start with Notion only if your team will keep the aggregator reference on every record and reconcile stages every week.
