Referral partner updates without privacy mistakes

A referral partner may want reassurance that an introduction was received and handled. That does not mean they need visibility into the client’s income, borrowing position, lender, application conditions or private conversations.

The workflow should prove follow-through without opening the file.

Before sending a status, establish whether the client expects or consents to that disclosure.

Australian Privacy Principle 6 generally limits an APP entity’s use or disclosure of personal information to the purpose for which it was collected, unless consent or another exception applies. The exact application depends on the brokerage, the information, the purpose and the legal framework.

Consent is not a blank cheque. The update still needs to be necessary, proportionate and consistent with what the client was told.

Create a master form that can be duplicated for approved partners.

Client-visible fields

• full name;
• preferred phone and email;
• broad reason for the introduction;
• preferred contact method and time;
• acknowledgement of the brokerage privacy notice;
• permission for the brokerage to contact the client; and
• the referral-update choice above.

Do not ask the referral partner to collect a detailed financial position unless your approved process explicitly requires and protects that information.

System fields

• referral partner ID;
• referral source type;
• form name and version;
• submitted timestamp;
• consent state and version;
• assigned broker or queue; and
• originating page or campaign.

A hidden form field can carry a partner ID, but hidden fields can be altered in a browser. Validate the submitted ID against an approved partner register before it triggers any communication.

Use a naming convention that identifies the partner without forking the underlying fields.

The visible partner name, internal ID and workflow tag may change. The client, opportunity and consent fields should stay canonical.

• `source:referral-partner`;
• `partner:{{partner_code}}`;
• `consent:partner-updates-approved`; and
• `consent:partner-updates-withdrawn`.

Do not let tags become the only record of consent. Store the actual choice, timestamp and version in defined fields or an auditable consent record.

If the partner submits a referral but the client has not yet agreed to updates, the safest default is internal-only handling until the brokerage establishes the permitted communication.

Not every internal stage deserves an external message.

The model below is a proposed sharing pattern for the pipeline. It is not an industry standard, and it is not a substitute for client consent and legal review.

A builder, buyer’s agent, accountant and general introducer have different legitimate needs. Do not make one construction-update rule available to every partner type.

The post-settlement client relationship belongs to the broker and the client, unless the client has asked for continued partner involvement.

Keep these behind a human decision:

• decline or adverse decision;
• conditional approval requirements;
• credit history or credit score;
• income, expenses, liabilities, assets or deposit;
• loan amount, lender or product;
• valuation result;
• hardship, vulnerability or complaint;
• document names, contents or missing items;
• reasons a file is paused;
• identity or contact changes; and
• internal compliance or audit status.

Even a neutral update can reveal that a person is seeking finance. Confirm that disclosing the existence and stage of the relationship is permitted at all.

Each of these says that something moved, and nothing else. Use a reference the partner already knows, and keep the client’s matter out of the subject line.

Trigger

Use the specific partner form submission or the validated partner ID, not a broad contact-created trigger.

Contact and opportunity

Create or match the contact, then create an opportunity carrying the partner ID and consent status. Prevent one client’s second scenario from overwriting the referral source on an earlier opportunity.

Stage listener

1. listen for the stage change;
2. confirm the partner ID is valid;
3. confirm the current client permission includes that milestone;
4. confirm no hold, complaint, decline or privacy suppression is active;
5. create a human-review task where required;
6. send the approved status-only template;
7. record message, channel, timestamp and trigger; and
8. stop duplicates.

Withdrawal

If the client withdraws permission, update the consent record and suppress future partner messages. Do not delete the minimum audit record needed to show that the withdrawal was honoured.

Maintenance

Review the workflow whenever the pipeline changes, a partner’s role changes, consent wording changes, the client withdraws permission, a new channel is used, a privacy incident or complaint occurs, or product behaviour changes.

“Built once” should mean reusable, not forgotten.

Email and SMS can be forwarded. Keep the message minimal.

For a partner portal, apply role-based access, individual accounts, multi-factor authentication where available, time-limited access where appropriate, audit logs and a visible client-permission state. Do not expose the full CRM record simply because a portal can display it.

OAIC guidance on APP 11 emphasises technical and organisational controls, third-party providers, access security and the whole information lifecycle.

Share proof of movement, not the file.

Give every partner a controlled source. Give every client a clear choice. Let selected pipeline stages trigger status-only messages, and keep every consequential or sensitive event with the broker.

That is enough to show professional follow-through without treating the client’s information as referral-partner property.