This walkthrough is the team-level companion to the borrower portal feature page. It covers the operational decisions a loan officer or branch lead has to make when wiring the borrower loan portal into their actual workflow: which channels to invite borrowers through, how to set up two-way communication that updates the portal in real time, whether to let borrowers generate their own pre-quals against pre-set parameters, and which 1003 fields to hide or comment on for the specific way you sell loans. It is not a feature tour; it is the configuration conversation that turns the portal from “available” to “actually used.”
The portal invite is the first decision. Most teams default to email-only because that is what is visible on the borrower record. The walkthrough names the alternative: “I can also copy them via text if I so choose. So you can send this via email and text if you’d like” [Nt5hKI6H0gA m2]. The text-link path matters for two reasons. First, mobile-first borrowers open texts faster than emails. Second, the invite text serves as a passive prompt the borrower can return to.
“You can do that for both the partners and the borrowers” [Nt5hKI6H0gA m2]. Partner invites work the same way: copy the link, send via email or text, partner clicks and lands in their partner portal login.
Real-time portal updates from CRM activity
The portal-as-live-status is what makes the feature worth the configuration time. The walkthrough demonstrates two-way communication with an example: “Frank, here’s Tim Howard’s message. So I could then go in and respond… yes, and I can add that event. So as soon as I do, it’s going to update his portal in real time, so he’ll be able to see [the response]” [Nt5hKI6H0gA m3].
Translation: every message logged on the borrower’s tracker inside the CRM appears in their portal communication log within seconds. The borrower never asks “did anyone get my message?” because they can see the response land in real time.
Letting borrowers generate their own pre-quals (with guardrails)
One workflow decision the walkthrough specifically calls out: whether to let borrowers self-generate pre-qualification letters from inside the portal. “[You] can allow them to generate their own prequels if you so choose. So I could go through and set the parameters for this loan right here, and then they could go in and generate the prequel based upon what I have here in the system” [Nt5hKI6H0gA m4].
The mechanic is: the LO sets the parameters first (max loan amount, max price, down payment range). Once set, the borrower can generate their own pre-qual letter within those parameters from inside the portal. The LO does not get woken up at midnight by an offer that needs a pre-qual; the borrower hits the button, the letter generates, and they get their offer in front of the listing agent.
“If you want to pre-set what the maximums are, you can do that” [Nt5hKI6H0gA m5]. Set the max once on each file you are willing to allow self-generation for. Files outside those parameters do not have the self-generation feature available.
What you can hide on the 1003 form per workflow
The 1003 configuration sub-conversation comes up because the team decides which fields are visible to borrowers in the portal version of the application. The example from the walkthrough: “You don’t want to ask them for their social security number? You can make that invisible, and you’ll see the eye through there” [Nt5hKI6H0gA m6].
The reason for hiding SSN at the borrower-portal stage of the 1003 might be that you collect SSN only after the borrower advances past initial qualification, not on first form submit. That is a workflow choice, not a feature limitation; the platform supports it either way. Same logic applies to other sensitive fields.
Adding inline comments at the field level
Tied to the same configuration: “If you wanted to add a comment or something, you could do that and add the comment in there saying like the [help text appears next to the field]” [Nt5hKI6H0gA m6]. Inline comments are the difference between borrowers stalling on a confusing field and borrowers moving through smoothly. For self-employed income lines, comment “include average of last 24 months income from your tax returns”; for “subject property type,” comment “this is the home you are buying, not your current home if you are refinancing.”
What triggers a campaign step when the 1003 is completed
The walkthrough names a workflow integration that most teams underuse. “If you do trigger app completed, you know, what do you want to happen, like, I want an email notification” [Nt5hKI6H0gA m7]. So when the borrower completes the 1003 inside the portal, two configurable things can happen: a real-time email notification fires to whoever needs to know, and a campaign step advances the borrower to the next stage of automated communication.
This is the same auto-advance setting referenced on the 1003 options page (the “automatically move a borrower’s record to a new step in the marketing sequence pipeline when they complete their loan application” toggle). The walkthrough adds the practical framing: pick what fires when, then test it on a sandbox record before going live.
A specific team scenario: branch lead onboarding three new LOs
A branch lead is bringing on three new loan officers next month. They want every new LO to use the portal from day one, with a consistent borrower experience across the team. The configuration session looks like this:
Open options, set the portal invite default to “email plus text” so every new lead gets both channels.
Set the 1003 field configuration: hide SSN until post-initial-qualification, hide a section of declarations that isn’t relevant to the team’s typical loan product, add inline comments on the three income fields where borrowers consistently get confused.
Enable the auto-advance on 1003 completion, pointing to the team’s “application in process” campaign.
Turn on the email notification for app completion so the LO knows the moment a borrower finishes the form.
Decide team-wide whether to enable borrower self-generated pre-quals (yes for purchase files, no for refi files where parameters change quickly).
Save settings. New LOs onboard with this configuration as the team default.
Honest limits
Real-time portal updates depend on CRM data hygiene. If LOs do not log communications in the CRM (calls outside the platform, side-channel texts), the portal communication log will be missing those touches. The portal is downstream of the data discipline of the team.
Self-generated pre-quals work only within preset parameters. The borrower cannot self-generate a letter for a price above the max you set. They get a prompt to contact the LO instead.
Hiding 1003 fields requires compliance awareness. Some fields are required for specific loan products (e.g., FHA, VA). Hiding them in the borrower portal version can create downstream issues. Coordinate with compliance before hiding non-trivial fields.
The 1003 auto-advance triggers only on completion, not partial save. For drop-off recovery, you need a separate trigger that fires on partial submission and queues a reminder email.
Set up the portal workflow on your account
To wire the borrower loan portal into your team’s actual workflow with the configuration decisions covered here, request a demo and ask the BNTouch team to walk through the options-tab configuration on a sandbox account. The borrower portal page covers the client-facing experience.
