Everything we did to the system, and everything we found that does not work or that we do not understand.
In order, so there is context for why things are the way they are.
The Purchase, Refinance and Selling forms in NEW FORMS 2026 came from the RJG forms you originally built and duplicated.
We duplicated those same three forms and added a single trigger question so the system knows the submission is a dependent rather than the employee. Everything else on those forms is identical to the employee versions.
Deliberate. Only the Purchase forms ask when someone plans to move. It does not apply to a refinance or a sale, so we took it out. This matters later — see Part 2.
Publish Changes in the NEW FORMS 2026 template editor fails. The last successful publish was version 80 on August 19 at 9:54 AM. Since then, every attempt fails with no error message shown anywhere.
Because we could not publish, we used Use template to create a board and folder per employer in BOS Forms: Beztak, Village Green, DCD, Aqua-Aerobic, Cafe Imports, Northern Ohio, RJG, BB&E, Jing-Jin, LightGuide, ClearRate, MICPA, Trenton.
For each one, by hand: renamed the folder and board to the employer, toggled the Deal Triage workflow to Active, deleted roughly 70 old test contacts that came across with the template, and turned on email notifications. Thirteen times.
46 controlled submissions. A full 11-test matrix on four partners — RJG, Beztak, Village Green, DCD — covering purchase, refinance with the same and a different property, selling with the same and a different property, the four dependent equivalents, and a referral. Two further tests on Trenton on August 24.
We deliberately varied the answers between partners so different status labels got exercised rather than testing the same path four times.
Timing: RJG Aug 21 evening, Beztak, Village Green and DCD in sequence early Aug 22, Trenton midday Aug 24.
The intake workflow was failing with "one of the status labels you chose has been deactivated" and then switching itself off. Two labels on the Deal Triage Timeline column — "I Am Ready Now" and "A year or more" — had been deactivated, which meant every member choosing the most urgent option was silently failing. We reactivated both on August 22 and re-tested. Both paths now work.
The EasyMail connection was disconnected. Every test before August 24 was running against a disconnected mailbox. It has now been reconnected.
On the Trenton test, we selected the lender, received the assignment email, clicked Assign MLO and entered our own details as the loan officer to see what would happen. We received the confirmation email back. The member received nothing.
Grouped by where in the sequence it happens. Tagged as broken, wrong data, missing, or unexplained.
Roughly 70 old test contacts arrive with each new partner board and we delete them by hand. We do not understand why a template is carrying record data at all.
All 46 test submissions landed in the correct group on the employer's board with full data, and 40 of 40 deal-type submissions produced a Deal Triage card within about seven seconds. Program type, employee versus dependent, and both address branches all came through correctly.
Noting it because it is the one part of the chain we trust.
The First Name column fills in with the literal words "Incoming form answer" instead of the member's actual first name. The card's title assembles correctly from first and last name, so the data is clearly there.
We opened the intake workflow and looked at the mapping on all three branches. It appears to point at the right field. We cannot explain the result and we are not going to guess. This string will end up in the greeting line of member emails if it is not resolved.
A dependent selling submission on RJG produced a triage card marked Employee instead of Dependent. The identical test passed on Beztak, Village Green and DCD. One out of 40. It behaves like a timing issue between two things writing the same field.
Covered in Part 1. Corrected on August 22, but flagging it here because of how it failed: members were disappearing with no error surfaced to anybody, and the workflow was switching itself off. We only found it by going looking. We have no way of knowing whether the same condition exists on other columns.
On August 24 a real member, Aaron Halloway at Aqua-Aerobic, submitted through the old Aqua-Aerobic form. He came through the old pipeline, which does not set program type, source or status, so his card arrived with no program on it at all. Meanwhile the new Aqua-Aerobic board has zero items on it.
We know both pipelines coexist during transition. We do not know what has to be true before the old forms can be retired.
There is a workflow in BOS System Workflows called Triage to Workflow — Item creation that contains rich field mappings, and there is a simpler automation sitting on the Deal Triage board itself, added August 20, that creates a record with about four fields. Our test members look like they came from the second one.
We do not know which one is supposed to be authoritative, or whether both can fire and produce duplicates.
Its condition splits three ways on Timeline: "I'm ready", "6 months", "6+ months". Our new purchase forms write "I Am Ready Now", "6 Months" and "A Year Or More". Our refinance and selling forms do not ask about timeline at all, so that field is blank for them by design.
The only member we have seen come through this workflow fully is Aaron Halloway, who arrived on an old form carrying an old label value.
Deal Triage records it correctly. Member Workflow has no column for it at all, so once a member advances we can no longer tell an employee from a dependent. The name of the employee a dependent belongs to also stops at the employer board and goes no further.
Member Workflow has no field for it. The MLO needs it on a refinance, and HomeAdvantage needs it on a sale in order to source an agent in that area.
To be clear on what this field means, because it is easy to get wrong: on a refinance it is the home being refinanced. On a sale it is the home being sold. On a purchase there is no subject property — a buyer only gives us the general area they want to buy in, which exists so HomeAdvantage knows where to place an agent. An empty subject property on a purchase is correct, not missing data.
Our forms capture the refinance amount as a range, for example $250,000 – $349,999. The Target REFI Loan field on Member Workflow is a number field. A range does not go into a number field.
The part that concerns us most is that it reports success while delivering nothing. We would never have known without checking inboxes by hand.
We cannot find any notification to support@gobevel.com when a new member submits. Without it, nobody knows to action the member, and the manual step at step 7 of the sequence never starts.
It delivers reliably, which makes it the one email in the chain we know works. But it goes to mike@gobevel.com. It needs to go to support@gobevel.com.
We looked. It is not in any board automation we could find. Beyond changing it, we need to know where it lives so that changing an address in future does not require a ticket.
The branded layout arrives intact. Program, timeline, state, loan amount, purchase price, down payment, credit score, occupancy, household income — all blank. Presumably because the record it reads from is empty, but the effect is that whoever receives it cannot act on it.
We clicked Assign MLO on the Trenton test and entered our own details as the loan officer. We received the confirmation email back, and it carried barely any of the member's information — the same empty-field problem.
At the moment the MLO was assigned, nothing went to the member. In the sequence we want, this is the email that tells them who to expect a call from.
The member should move from New to Request for Pre-Approval once the MLO is assigned and notified. It did not happen.
Two separate faults on all partner boards. The subject line contains the literal text [Employer] instead of the employer's name. And three merge fields in the body point at columns that do not exist on the new boards — {pulse.text_mm25wrk8}, {pulse.email_mm25a1xy} and {pulse.text_mm25dst9} — so a recipient sees raw placeholder code where the employee's name, email and employer should be.
We do not want this sequence firing to members under the new flow. It should be removed from the pipeline entirely rather than left switched off where it can be reactivated by accident. To our knowledge it runs from the 3/5/7 Day Hold setup in BOS System Workflows, but if it is wired in more than one place we want all of it gone.
Matching 3, 5 and 7 day text messages also exist. We are leaving SMS alone for now and will deal with those separately.
The two email automations that arrive with each partner board are inactive with no mailbox connected. That is deliberate on our side for now. Noting it so nobody switches them on assuming it was an oversight.
We have built the branded templates, so the fields they require are now fixed and known. Listing them here because the amount of data involved is very different from one email to the next, and the welcome email in particular needs far less than we had assumed.
Three versions exist — purchase, refinance and selling. Program type decides which one sends. Beyond that, each template only merges two member fields:
Everything else in the welcome email is fixed copy and static resource links that differ only by program: Buyer's Guide and Purchase FAQ, Refinance Guide and Refi FAQ, or Seller's Guide and Sell FAQ, plus the Benefit Page.
No financial data, no address, no timeline. If the member's first name and employer are available, and the program type is known, the welcome email can send. That is worth knowing because we had been treating it as blocked behind the full data problem, and it may not be.
This is the email support receives when the lender is selected. It should carry the program details only, with no contact information, since at this stage the file is being reviewed rather than worked:
Fields that do not apply to the member's program should simply not be shown. A refinance has no purchase price or down payment; a purchase has no refi loan amount.
Today every one of these renders as an empty bar. The layout is correct and the labels are correct — the values are missing.
Sent once support assigns the loan officer. This one carries everything above, plus the member's contact information, because the MLO is about to call them:
The distinction between these two emails is deliberate. The POC sees enough to review and route. The assigned MLO sees enough to open a conversation.
Also built and branded. Two versions: one introducing a lending professional for purchase and refinance, one introducing a real estate agent for a sale. These need the member's First Name and Partner Name again, plus details of the person being introduced:
Lending professional (purchase and refinance): LO name, mortgage brokerage, LO NMLS number, company NMLS number, direct line, email address.
Real estate agent (selling): agent name, brokerage, license number, direct line, email address.
This matters for the assignment step. When support assigns the MLO, the form they fill in has to capture all of those fields, not just a name — otherwise this email cannot be completed. It is worth confirming the form is built to collect them.
We have also built the pre-approval email for purchase and the loan-approved email for refinance. Both are further down the journey than this phase covers, and both reference the LO by name. Flagging them so they are accounted for but not built into the current scope.
This is a list of what we know to be wrong, measured against the sequence we want. It is not a list of instructions, and it is not us asking to be taught how to fix any of it.
We have already spent a lot of time trying to diagnose and repair these ourselves. That is not a good use of anyone's time and it is not where our expertise is. What we can do is describe precisely what we want to happen, show what we did, and report what we observed. That is what these two documents are.