Skip to content
Coming soon: iOS & Android apps.Join waitlist
Mortgage360
Demo
Automations

Mortgage workflow automation software: Your follow-up playbook, run on every file

Mortgage workflow automation in Mortgage360 fires on what actually happens to a file (an application submitted, a condition left open, a renewal window opening) rather than on a date somebody remembered to set. It is part of the mortgage CRM, so the email, the task and the call queue all land on the same record.

Book a demoSee pricing
The short answer

What is mortgage workflow automation?

A set of rules that watch your files and act when something changes. Each rule has a trigger (a lender issues conditions), optional conditions (only purchases, only clients tagged first-time buyer) and a list of actions (send the checklist email, create a task, wait two business days, check again). Because the rules run inside the CRM, they react to real activity (calls, replies, uploads) instead of whatever someone typed into a notes field.

  • 51 triggers wired to real events, from a website form to a deal funding.
  • 98 ready-made automations to switch on, or copy and change.
  • A visual editor: trigger, conditions, actions, waits and if/else branches.
  • Exit rules re-checked before every delayed step, not only at the start.
  • Consent and opt-outs checked before every email and SMS an automation sends.
  • A run history on every automation, so you can see what fired and what it did.
51
Wired triggers
Each one emitted by a real event
98
Ready-made automations
Use as-is or copy and edit
If / else
Branching
Different path for different clients
Per run
Run history
What fired, and when
Triggers

Rules start from mortgage events, not just contact events

Generic CRMs trigger on the things a sales pipeline has: a contact created, an email opened, a deal moved to a stage. Those exist here too, but most of the triggers come from the middle of a mortgage file and from running a brokerage. Each trigger is listed only when something in the platform actually emits it. The one that does not yet, running an automation by hand, is shown as unavailable in the editor rather than accepting a rule that would never fire.

  • Leads and engagement: a form submitted, an email opened, clicked or replied to, an SMS reply, a call outcome logged, a contact going quiet for the number of days you set.
  • Appointments: booked, cancelled, marked no-show, completed.
  • The file: application started, submitted or withdrawn; file under review; conditions issued; approval; funded; declined.
  • Documents and conditions: a client upload, a document approved or rejected with the reviewer's note, a condition still open on a 3, 7, 14 and 21-day ladder, a file sitting past its stage threshold.
  • Closing and after: a closing countdown at 14, 7, 3 and 1 days, a rate hold or pre-approval nearing expiry, a renewal window at 120, 90, 60 and 30 days, a review request 14 to 45 days after funding.
  • Running the brokerage: licence and E&O expiry, CE-hour shortfalls, FSRA licensing steps, new-agent milestones over the first 90 days, vendor documents expiring.
The editor

Trigger, conditions, actions. Then a wait, and a branch

The editor is deliberately plain. You choose the trigger, add conditions as rows (every row must match), then list the actions in order. A wait parks the run and resumes it later rather than holding anything open, and it can count business days so a reminder never lands on a Saturday. A branch sends a client down one path or another, say an SMS if they replied and a task for the agent if they did not, and both paths continue into whatever comes after. The editor only offers actions the engine can carry out, so a rule cannot look configured and silently do nothing.

  • Messages: send an email or SMS from a template, or enrol the client in a campaign.
  • Ownership: assign to a named person or round-robin across the team.
  • Work: create a task, notify the agent, or add the client to the power dialer queue.
  • Record-keeping: add or remove a tag, set temperature or lifecycle stage, log a note on the timeline.
  • Outside systems: call a webhook with the event's details.
Guardrails

Built to stop, not only to start

The expensive automation mistakes in this business are not rules that fail to fire. They are rules that keep firing after the situation changed: a condition reminder to a client whose file funded on Friday, a renewal countdown after the mortgage renewed, the same email twice because a webhook retried. So an automation can carry rules about when it must stop, and those rules are re-checked before each delayed step, not only at entry, because the gap between scheduling a message and sending it is exactly where a deal funds or a client complains.

  • Duplicate protection: one open run per client by default, or once ever, or once a day for recurring signals.
  • Exit conditions (the goal was met) and exclusions (this client should never have been here) checked before every delayed action.
  • Each stopped run records why: goal met, excluded, suppressed, completed or failed.
  • A failed run does not bar the client for good, so a broken first attempt does not mean they never hear from you.
  • The document chase treats a client upload as the end of the reminder, not the start of another one.
Documents and conditions

Chase the client when they are late, and your team when you are

Most of a borrower's time in a mortgage is spent waiting on documents and conditions, and most of the complaints come from there too. The chase automations separate two silences that look alike in a spreadsheet. A condition is open and the client has sent nothing, so reminding them is right, and it escalates as the due date gets closer. Or the client uploaded it and nobody has reviewed it, and asking them again is the fastest way to lose their confidence. In the second case the reminder goes to your side instead. Document classification and review sit with Harvey, the compliance AI; the file itself lives in origination.

  • Open conditions chased on a 3, 7, 14 and 21-day ladder.
  • Uploads waiting on review flagged to the team, not re-requested from the client.
  • A rejected document is its own trigger, and it carries the reviewer's note into the follow-up.
  • Files sitting past their stage threshold surface before anyone has to ask.
For brokerages

Start from the library, make it yours without forking it

The ready-made automations ship as a shared library. When your brokerage edits one, your copy replaces the original for your brokerage instead of running alongside it, so nobody gets two renewal emails because the old version was still switched on. Switching your copy off switches it off for you, even though the library version stays active for everyone else. Automations are scoped to your brokerage: one firm's rules never run against another firm's clients. Unanswered leads get the same treatment: a sweep every 15 minutes finds leads nobody has touched within your policy's window and reassigns them, round-robin or to a named person, with the breach recorded. Brokerage-wide automation is part of the brokerage plans.

  • An edited library automation replaces the original for your brokerage; it never runs twice.
  • Your rules act only on your own clients.
  • Lead reassignment when first contact misses your policy, with an audit record.
  • Licence, CE and new-agent milestone triggers for the people side of the brokerage.
Run history

When someone asks “did that go out?”, you can answer

Every automation has a run history: each run, the client it ran for, where it is now (waiting, finished, stopped or failed) and a running total. “It didn't fire” and “it fired and did something unexpected” are different problems, and you need to be able to tell them apart without asking a developer. An automation you cannot audit is one your team eventually switches off.

  • Recent runs listed on each automation, with status and a total run count.
  • Waiting runs show that they are waiting, rather than looking like nothing happened.
  • Messages and notes land on the client's timeline, where the rest of the file's history already is.
Where it fits

Automations do the routine. The AI does the judgment work

Automations are rules: predictable, auditable, the same every time. They send the templates you wrote and create the tasks you defined. Writing a personal re-engagement email, or deciding which of forty quiet leads deserves a call today, is a different job, and that is what Finn, the agent copilot, is for. Finn drafts and ranks; you approve and send. On the client side, Maya answers borrower questions and books appointments. When she books one, that booking is an event an automation can act on.

New leads usually arrive from your own site, and a form on a Mortgage360 agent or brokerage website is a trigger like any other. Further down the file, the scenarios and lender matching that decide whether a deal will qualify live in underwriting, and the moment a file goes under review is itself a trigger.

Automations — common questions

What can Mortgage360 automate?
Follow-up sequences, renewal campaigns, document chasing, lead routing, task assignment and SLA escalation — triggered by what actually happens on a deal rather than by a date somebody remembered to set.
Do I need technical skills to build an automation?
No. Automations are built from triggers, conditions and actions in a visual editor, and the platform ships with a library of working ones you can use as-is or fork and change for your brokerage.
What triggers an automation?
Events on the record — a deal changing stage, a document arriving, a renewal window opening, a lead going untouched past your SLA, a call outcome being logged. Because dialling and email are built in, the triggers see real activity rather than what somebody typed in.
Can a brokerage enforce automations across agents?
Yes, at brokerage level. Automations belong to the brokerage, so every agent in it works from the same set. The ones that ship with the product are inherited by every brokerage, and editing one creates your brokerage's own copy rather than changing it for anyone else. There are no per-agent copies.
Will automated messages break CASL compliance?
Consent state is held on the contact, and sends check it before they go. Unsubscribe handling and the required identification are built into the templates rather than left to whoever writes the message.
Can I see what an automation actually did?
Yes. Every run is logged against the contact and the deal — what fired, what it evaluated, what it sent. An automation you cannot audit is one you eventually stop trusting and switch off.

Keep reading

The mortgage CRM

The contacts, deals and timeline automations act on.

Origination

Applications, documents and conditions: where most triggers come from.

Underwriting

Scenarios, ratios and lender matching before you submit.

Power dialer

Where the dial-queue action sends a client.

Finn

Drafts outreach and ranks the pipeline. You approve.

Follow-up system

The cadence worth automating in the first place.

Ready when you are

Stop running the same playbook by hand

Bring one follow-up you do manually today. We will build it as an automation on the call.

Book a demoSee pricing