BrokerEngine Plus for Brokers: Setup and Handoffs

BrokerEngine Plus is the lodgement-enabled BrokerEngine offering for Australian Finance Group (AFG) mortgage brokers, with workflows for assigning file work across a team. Set it up around the broker responsible for each deal and the staff responsible for its tasks. Before using automatic stage changes, follow a fictional file through a handoff and confirm that incomplete work keeps the next action waiting.

Confirm the BrokerEngine Plus Offering

BrokerEngine’s pricing page, as at October 2026, distinguishes Plus for AFG brokers from its classic platform for brokers across aggregators. Plus adds direct lodgement to ApplyOnline to the underlying collaboration and workflow platform. The page describes a Suite360 bundle containing BrokerEngine Plus and FLEX, alongside other AFG services.

Plus isn’t a generic automation add-on available regardless of aggregator. Its lodgement access is specific to AFG brokers, while the classic offering also has pre-built workflows and a client portal. A brokerage evaluating its operating model can use the mortgage broker CRM guide to compare the jobs a customer relationship management (CRM) system must handle.

BrokerEngine charges by user, with separate Broker User and Support User categories and monthly or annual billing. Its pricing page lists a free demonstration instead of a free trial. Kickstart is a separate onboarding programme with a one-off broker-group fee, covering workflow configuration and migration, with training and support.

Each person needs an individual login. Broker Users write deals under their own broker codes, while Support Users include processing staff and non-writing management. Subscription category, permission level and assignment to a file answer different questions: what the user subscribes to, what they can change and which work they own.

The broker platform guide explains the systems a brokerage uses around its file-management workflow.

Map Records and File Stages

Map the household to its applicant contacts, the loan opportunity to a lead or deal card and the work to named staff. BrokerEngine’s applicant roles are Primary Applicant, Co-Applicant and Guarantor. A FLEX opportunity is a connected record, so keep its identifier with the BrokerEngine card when the file is linked.

Separate Login Trouble From File Access

Use the User Login entry on BrokerEngine’s official website and sign in with your own account. If authentication fails, resolve the account or two-factor authentication problem before looking for a deal. BrokerEngine’s security guidance directs account-security changes to its staff, so contact support@brokerengine.com.au when recovery needs their intervention.

If you can sign in but can’t find a file, check the board search and active filters first. Then ask the authorised Super User to inspect your record-access settings. BrokerEngine’s permissions guide permits access to all group records or selected users’ records, so a successful login doesn’t establish access to every broker’s work.

Access to User Management is disabled by default and requires Super User permissions enabled through BrokerEngine support. The business owner, or a person the owner designates, can hold that permission. Give processors the access their assigned work needs while retaining control of workflow editing with the responsible administrator.

Keep the Records Together

Use the following map as a brokerage design example, with stage names chosen for your own workflow. It doesn’t assume these are default BrokerEngine stages.

File stage	Household and opportunity	Responsible staff	Evidence to retain
New enquiry	Existing or new applicant contacts linked to the lead	Writing broker and enquiry handler	Client objectives and contact notes
Research	Applicants linked to the correct loan request	Broker and research processor	Fact find, income evidence and policy notes
Broker handoff	Deal card with broker and processing role assigned	Broker approves the handoff. Processor accepts work	Handover checklist and outstanding conditions
Submission	Deal linked to the intended external opportunity or application	Lodging broker and submission processor	Final documents, lodgement reference and exception correspondence
Approval and settlement	Same applicants and correct loan record	Broker and settlement processor	Lender approval and remaining settlement conditions

BrokerEngine’s lead-to-deal procedure moves the card to the selected board and stage. Use that move for the continuing loan file. Create a separate card only when you’re recording a distinct opportunity that needs its own work and evidence.

Check BrokerEngine Plus and Connections

Plus enables the AFG lodgement route, while each connected service has its own prerequisites and data-transfer behaviour. BrokerEngine’s Suite360 integration guide requires both the person sending the request and the broker on the deal to connect Suite360 and FLEX. This applies to credit-guide and privacy-consent requests as well as direct lodgement.

For that connection, the documented route is the account icon, then Settings and Integrations. Expand Suite360, select Connect and enter that user’s Suite360 credentials. The expected connection result is the Account Connected notification.

Treat a record push to FLEX differently from a continuously updated shared record. BrokerEngine’s FLEX guidance describes a one-way push that creates an opportunity, with separate operations for card data, fact-find data and notes. Linking an existing FLEX identifier doesn’t update the lead or deal details there.

Choose the intended creation route once. For a FLEX-integrated fact find, the provider directs users to push from the fact find instead of also using the card’s FLEX sync. That prevents a duplicate opportunity from being created by the second route.

BrokerEngine documents other integrations, including Mercury and document-signing tools. Their behaviour must be read separately from FLEX’s one-way transfer rules. Include the account owner and the direction of transfer in your connection map, with the destination record identifier and the fields each system maintains.

Configure Team Handoffs

Configure handoffs through roles assigned on each card, with a task owner and an explicit approval point. BrokerEngine’s Team Roles guidance routes workflow tasks and messages to the person holding that role on the specific lead or deal. Assign the processor on each file before its workflow reaches the handoff.

The following fictional example uses invented applicants Alex and Morgan and a policy exception requiring broker review. Use synthetic documents and internal test recipients. Keep live client communications and lender lodgement out of this configuration exercise.

1. Create the synthetic loan file and link Alex as Primary Applicant and Morgan as Co-Applicant. Assign Priya as the writing broker and Sam as the processor. Confirm that each user can open the file using their own login.
2. Prepare an exception-review checklist. Record the policy question and supporting evidence. Add separate items for the lender response and the broker’s decision. Leave the lender-response item incomplete while the exception is unresolved.
3. Configure the review task with an assignee and due date. Attach the synthetic evidence and link the checklist as required. Select the broker in Notify user to receive the completion alert.
4. Configure a workflow task for the processing role at your chosen handoff stage. BrokerEngine’s published stage workflow creates the assigned task when the card enters that stage. Check that Sam receives this task, with the intended file reference and instructions.
5. Have the processor record the exception question and supporting documents, then hand the decision to Priya. Keep the approval task incomplete until the broker has assessed the response and recorded the decision.
6. After every required checklist item is complete, finish the approval task. If its completion triggers a stage move, confirm the new stage and the next owner’s task. Confirm the completion alert reaches the broker selected in Notify user.

In this design, the stage-triggered workflow records the handoff by creating the review task. The processor records the evidence in the file, and the broker records the approval decision before completing the task. The workflow doesn’t establish that a lender has agreed to an exception.

Where a policy exception needs lender acceptance, obtain that lender’s confirmation for the actual circumstances and retain the response. Bulma’s Scenario Planner can identify exception pathways with confidence levels and supply the policy wording behind its assessment. A pathway is a research lead for the broker, and the lender still decides whether it will accept the exception.

BrokerEngine’s checklist guidance supports a required checklist that must be complete before its linked task can finish. Give one person responsibility for each checklist. Separate the processor’s evidence-gathering checklist from the broker’s decision checklist when both people have work to complete.

Validate Automation Before Use

Validate automation by leaving a required item incomplete, repeating a trigger and changing the person responsible for the file. BrokerEngine documents workflow conditions and card duplication, but your configuration decides which downstream actions run. Keep a record of the expected outcome beside each result before using the workflow for clients.

Test	Documented behaviour	Brokerage check and expected result
Required evidence missing	A required linked checklist controls task completion	Leave one item incomplete. The linked task must remain unfinished and the approval-dependent action must wait
Conditions unmet	Positive workflow conditions all need to be true. Any true negative condition prevents triggering	Make a configured condition false. Confirm the action governed by it doesn’t run
Duplicate card	Duplicate Card lets users choose copied information and the destination board and stage	Review copied applicants and assignments. Entering the destination stage must not send unintended messages or produce unwanted tasks
Broker reassigned	Changing the broker can affect branding, metrics and integrations	Inspect the new broker, communication brand and external connection before the next action
Processing role changed	Role-based workflow tasks target the person assigned on that card	Inspect existing open tasks as well as the next generated task. Explicitly reassign outstanding work where needed

BrokerEngine’s duplication guide tells users to review the new card’s name and copied information before selecting its board and stage. A duplicate card is another file needing its own review. Don’t assume it inherits a clean approval state or that moving it into a stage suppresses automation.

Changing a card’s broker and changing a task’s assignee are separate actions. After reassignment, inspect pending work and its completion-notification recipients. If a task still belongs to the former processor, edit its assignee before continuing the file.

For FLEX, check the external record before repeating a push. A repeated note push creates another note in FLEX, and the provider’s fact-find guidance warns against creating the opportunity through both routes. Match the destination identifier to the intended client file before transferring more data.

Keep automatic approval-stage movement dependent on the required review task, with the lender response retained where an exception needs it. Use the workflow for client files once the synthetic handoff produces the intended assignment and incomplete evidence keeps the next action waiting.