July 10, 2026

IPP 3A Is Live: Building New Zealand's Indirect-Collection Notice into Salesforce

New Zealand's IPP 3A now requires notice when you collect personal data indirectly. Build compliance into Salesforce with source fields, a Flow, one report.

TL;DR

New Zealand's Privacy Amendment Act 2025 added Information Privacy Principle 3A (IPP 3A) to the Privacy Act 2020. It came into force on 1 May 2026 and applies to personal information collected on or after that date.
If your organisation collects someone's personal information from a source other than the person themselves (a purchased list, a referral, an integration, an event attendee list), you must take reasonable steps to notify them, as soon as reasonably practicable, unless a listed exception applies.
The notice must cover: the fact of collection, the purpose, the intended recipients, your organisation's name and address, any law that authorised the collection, and the person's rights of access and correction.
This is buildable in Salesforce with three custom fields on Lead and Contact, one email template, and one record-triggered Flow. Add a scheduled backfill for records created since 1 May and a report that proves compliance.
The Office of the Privacy Commissioner (OPC) has published final guidance and a decision flowchart. Read them, then build.

What You'll Learn

What IPP 3A requires, who it applies to, and which exceptions you can actually rely on
Where indirect collection hides in a typical Salesforce org
The exact data model: Collection_Source__c, Notice_Sent__c, Notice_Sent_Date__c, Notice_Exception__c
A record-triggered Flow that sends the notice and stamps the audit trail, step by step
How to backfill records created between 1 May 2026 and your go-live, and the one report that shows the Privacy Commissioner you are on top of it

The Problem

Since 1 May 2026, every New Zealand organisation that gets personal information about someone from anywhere other than that person has a legal duty to tell them. That is Information Privacy Principle 3A, added to the Privacy Act 2020 by the Privacy Amendment Act 2025. It is not a proposal or a consultation. It is live law, and the records flowing into your Salesforce org right now from list purchases, referrals, enrichment tools, and integrations are creating notification obligations every day.

The legal firms have published plenty of "what IPP 3A means for your business" articles. What nobody has published is the actual build: which fields, which Flow elements, which report. That is what this post is. I am a Salesforce consultant, not a lawyer, so treat the legal summary here as a practitioner's working understanding and get proper advice for the edge cases. The Salesforce recipe, though, I will stand behind.

Common questions this article answers:

What does IPP 3A require, and does it apply to records we already had before 1 May 2026?
How do I track collection source and notice status in Salesforce?
How do I automate the IPP 3A notice with a Flow, and what goes in the email?

Quick Answer

IPP 3A requires New Zealand agencies to take reasonable steps to notify a person when their personal information is collected indirectly (from a third party), as soon as reasonably practicable, unless an exception applies. The notice must state that the information was collected, the purpose, the intended recipients, the collecting agency's name and address, any authorising law, and the person's rights to access and correct their information. In Salesforce, add a Collection_Source__c picklist, a Notice_Sent__c checkbox with Notice_Sent_Date__c, and a Notice_Exception__c picklist to Lead and Contact. Build a record-triggered Flow: on create, if the source is indirect, no exception is documented, and an email exists, send an email alert built from a template containing all six disclosure items, then stamp the notice fields. Backfill records created since 1 May 2026 with a one-off scheduled flow, and run a report of indirect-source records with no notice and no exception. That report at zero rows is your compliance evidence.

What IPP 3A actually requires

The Privacy Amendment Act 2025 received royal assent on 23 September 2025 and inserted IPP 3A into the Privacy Act 2020, in force from 1 May 2026. It closes a real gap. IPP 3 has always required you to tell people what you are up to when you collect information from them directly, which is why your Web-to-Lead form links to a privacy statement. But when the information arrived via a third party, the person often never found out you had it. IPP 3A fixes that: indirect collection now triggers a notification duty too.

When you collect personal information from a source other than the individual, you must take reasonable steps to make sure they know:

That the information has been collected
The purpose of the collection
The intended recipients of the information
The name and address of the agency that collected it and the agency that holds it (for most orgs, both are you)
If the collection is authorised or required by law, which law
Their rights of access to, and correction of, the information

Notification must happen as soon as reasonably practicable after collection. The duty applies to personal information collected on or after 1 May 2026, so your pre-existing database is not retroactively in scope. New records arriving today are.

The exceptions matter because they are what your Flow's decision logic will encode. You do not need to notify where the person is already aware of everything on that list, where the information is publicly available, where non-compliance would not prejudice the person's interests, where notifying would prejudice the purpose of the collection (a fraud investigation, for instance) or the maintenance of the law, where it is not reasonably practicable, where notifying would create a serious threat to health or safety, or where the information will not be used in identifiable form or is for statistics or research. There are further narrow exceptions around security, defence, international relations, trade secrets, and commercial prejudice. The OPC's guidance is clear on one more point: cost and inconvenience alone do not make notification impracticable, and if you rely on "they already knew," you need evidence.

The OPC has published final IPP 3A guidance and a decision flowchart on privacy.org.nz. Print the flowchart. It is essentially a specification for the Flow you are about to build.

Your imports are the risk, not your web forms

Direct collection is the case you already handle. Someone fills in your Web-to-Lead form, your event registration page, your support portal: they gave you the information themselves, and IPP 3 plus your privacy statement covers it. Set those records' collection source to Direct and move on.

Indirect collection is everything else, and a typical org has more of it than anyone admits:

List imports and purchases. A marketing list bought from a broker or inherited through an acquisition. Every row is an indirect collection.
Referral fields. "Referred by" on a Lead means someone else gave you this person's details.
Data enrichment tools. Anything that appends contact details, job titles, or firmographics from an external database is collecting indirectly on your behalf.
Integrations. Contacts pushed in from an ERP, a booking system, a partner portal, a parent company's CRM. The person gave their details to that system, not to you.
Event attendee lists. The conference organiser sends you the delegate list. Classic indirect collection.
Partner-shared leads. A reseller or alliance partner passes you a prospect.

Each of these is a moment where, since 1 May 2026, a notification duty can attach. The build below makes that moment visible and handles it automatically.

The data model: three fields, two objects

Create these custom fields on both Lead and Contact. Keep the API names identical across the two objects so your flows, reports, and Data Loader mappings stay symmetrical.

Collection_Source__c (picklist, required going forward): Direct, Referral, Purchased list, Data enrichment, Integration, Event attendee list, Partner. Add values to match your actual channels, but keep Direct as the explicit "no IPP 3A action needed" value rather than leaving the field blank. A blank source is an unanswered question, and unanswered questions are what audits find.

Notice_Sent__c (checkbox) and Notice_Sent_Date__c (date): the audit trail. The Flow stamps these; humans should not edit them.

Notice_Exception__c (picklist, optional): Already aware, Publicly available information, Not reasonably practicable, Would prejudice purpose of collection, Maintenance of the law, Statistical or research use, Other (documented). Populating this field is a human decision made at import time or during review, never something the Flow infers on its own. The point of the field is that every indirect record ends up in exactly one of two states: notice sent, or exception documented. Anything in neither state is your compliance gap.

Set Collection_Source__c defaults at the point of entry: Web-to-Lead and web forms pass Direct as a hidden field, import templates make the analyst choose a value before the file loads, and integrations set their own value in the payload. For an integration you cannot modify, add a fast field update (before-save) flow: if the record was created by that integration user and the source is blank, set it to Integration. Integration-created records should never depend on a human remembering to classify them.

The notice email: map every disclosure item to the template

Build one Lightning email template (or Classic template if your email alerts need it) that contains all six required items. Here is the outline, with each IPP 3A item mapped:

Fact of collection: "We recently received your contact details from a third party" with a merge of {{{Lead.Collection_Source__c}}} phrased in plain language ("from an event attendee list", "from one of our partners"). If the source value is too internal to show verbatim, use a formula field that translates it to customer-facing wording.
Purpose: one or two sentences on why you hold it ("to contact you about X and provide Y"). Write this once, honestly, and resist marketing's urge to make it vague.
Intended recipients: who sees it ("our sales and service teams; we do not sell your information to third parties" or whatever is actually true).
Name and address: your legal entity name and physical address in the body or signature block, not just a logo.
Authorising law: for most commercial collection there is none, and you can omit the line. If a specific statute authorises your collection, name it.
Access and correction rights: "You can ask us for a copy of the information we hold about you and ask us to correct it" plus a real contact channel, and a link to your privacy statement.

Keep it short and human. This email is legally required, but it is also the first thing this person ever receives from you. A cold, legalistic notice reads like spam and invites complaints; a plain, honest one reads like a company that has its act together.

Wire the template to an Email Alert on Lead and another on Contact, sending to the record's email field from a monitored org-wide address (replies of "delete my details" are access and correction requests, and someone must be reading them).

The record-triggered Flow, step by step

One flow per object, identical shape. On Lead:

Trigger: record-triggered flow on Lead, when a record is created, optimised for Actions and Related Records (after save, because we are sending email and updating the record).
Entry conditions: Collection_Source__c is not null AND Collection_Source__c does not equal Direct AND Notice_Sent__c equals false. Keeping the conditions in the trigger means the flow never even starts for direct-collection records, which keeps your flow interviews clean.
Decision: exception documented? If Notice_Exception__c is not blank, take the exception path and end. The record is compliant because a human documented why no notice is needed. Do not have the flow set exceptions itself; a flow asserting "the individual was already aware" with no evidence is exactly the kind of automation the OPC guidance warns against.
Decision: can we reach them? If Email is blank, do not silently do nothing. Create a Task for the record owner ("IPP 3A notice required, no email on record") so a human decides: find another channel, or document Not reasonably practicable in Notice_Exception__c if there is genuinely no way to contact them. Silence is the one outcome the design must not allow.
Action: send the email alert built on the template above.
Update Records: set Notice_Sent__c to true and Notice_Sent_Date__c to {!$Flow.CurrentDate} on the triggering record.

Clone for Contact, swap the object and email alert, done. Test with a bulk import of 200 rows, not a single record, because imports are exactly how these records arrive and you want to see the flow behave in bulk before your marketing team loads 10,000 rows on a Friday.

One design note: the flow fires on create only, and the Notice_Sent__c condition guards against duplicates. A person you notified at first collection is already aware of everything IPP 3A requires, so subsequent syncs of the same record fall under the already-aware exception, which the create-only trigger handles structurally.

Backfill: the records created since 1 May are already in scope

IPP 3A has applied since 1 May 2026. Your flow goes live today. Every indirect-source record created in between carries an unmet obligation, and "we had not built the automation yet" is not an exception on the list.

Run a report of Leads and Contacts with CreatedDate on or after 1 May 2026, Notice_Sent__c false, Notice_Exception__c blank. Records with a blank Collection_Source__c need triage first: use CreatedBy (integration user versus human), lead source, and import history to classify them, then update Collection_Source__c in bulk with Data Loader. Cross-check who actually created what against your login and audit data; if you want a fast way to see which integration users are creating records, the approach in our free event monitoring baseline guide pairs well here.

Then send the backlog notices with a one-off schedule-triggered flow: same decision logic and email alert as the record-triggered version, entry conditions matching the report filters, scheduled to run once. Deactivate it after the run. For a small backlog, a report plus a manual list email plus a Data Loader update of the notice fields is honestly fine; the point is that the fields end up stamped either way.

The report you show the Privacy Commissioner

Compliance you cannot demonstrate is compliance you do not have. Build one report per object: Collection_Source__c not equal to Direct, Notice_Sent__c false, Notice_Exception__c blank. Call it "IPP 3A gap report". Its target state is zero rows, permanently. Subscribe your admin or privacy officer to it weekly.

If a complaint ever reaches the Privacy Commissioner, this is the conversation you want to be able to have: every indirect collection is classified at the point of entry, notices go out automatically with a date stamp, exceptions are documented per record with a named reason, and here is the report showing nothing has fallen through since go-live. That is a fundamentally different position from "our privacy statement mentions third parties," which is where most orgs are today.

This work sits alongside the rest of your NZ compliance picture: where the data physically lives is covered in Salesforce data sovereignty in New Zealand, and mapping your org's security posture to the Privacy Act and NZISM control by control is covered in Mapping Salesforce security to NZISM, the NZ Privacy Act and ISO 27001. For health data, the Health Information Privacy Code has its own parallel Rule 3A, and the stakes are higher: see Why Salesforce Health Cloud needs its own security review. At CloudCounsel we build exactly this kind of privacy and compliance plumbing for New Zealand orgs on Salesforce, so if you would rather have it reviewed or built than DIY it, get in touch.

Frequently Asked Questions

Q: Does IPP 3A apply to the records that were already in our org before 1 May 2026?

A: No. IPP 3A applies to personal information collected on or after 1 May 2026, so your historical database is not retroactively in scope. But a new collection about an existing person is in scope: if an enrichment tool appends fresh details to a five-year-old Contact today, that append is an indirect collection that can trigger the notice duty. The backfill you owe is for records collected since 1 May 2026, not for everything you have ever held.

Q: Does a purchased marketing list count as indirect collection under IPP 3A?

A: Yes, clearly. The people on the list gave their details to someone else, and you obtained them from that third party, which is the definition of indirect collection. Unless an exception applies (for example, the information is genuinely publicly available, or the seller demonstrably notified people that your organisation would receive it, making them already aware), you must take reasonable steps to notify each person as soon as reasonably practicable. If a list seller cannot show you what the individuals were told, price that notification work, and the complaint risk, into the purchase decision.

Q: Can the Flow just set the "already aware" exception automatically?

A: No, and do not build it that way. The already-aware exception requires the person to know everything IPP 3A covers, and the OPC guidance expects evidence if you rely on it. A flow has no basis for that judgment. Have humans set Notice_Exception__c at import time or during review, with the evidence filed somewhere findable, and let the flow's only autonomous behaviours be sending the notice and stamping the date.

Q: What do we do with indirect records that have no email address?

A: Do not let them fall through silently. The Flow should create a Task so a human decides: notify by another channel you do have (post, phone), or, if you genuinely hold no way to contact the person, document Not reasonably practicable in Notice_Exception__c. The OPC's position is that cost and inconvenience alone do not make notification impracticable, so "we only built the email path" is not a defence. Having no contact details at all can be.

Key Takeaways

IPP 3A is live law. In force 1 May 2026 via the Privacy Amendment Act 2025, it requires notice for indirectly collected personal information, and it applies to what your org is importing right now.
The notice has six required items. Fact of collection, purpose, recipients, your name and address, any authorising law, and access and correction rights. One email template covers all of them.
Three fields make it auditable. Collection_Source__c, Notice_Sent__c with its date, and Notice_Exception__c put every indirect record in exactly one defensible state.
One record-triggered Flow makes it automatic. Entry conditions filter to indirect sources, decisions respect documented exceptions and missing emails, the email alert sends, the date stamps.
One report makes it demonstrable. Indirect source, no notice, no exception, zero rows. That is what evidence of compliance looks like in a CRM.

What's Next?

Recommended Reading:

Salesforce Data Sovereignty in New Zealand: There's No NZ Region, So What Actually Protects Your Data?
Mapping Salesforce Security to NZISM, the NZ Privacy Act and ISO 27001
Hardening Agentforce Against ForcedLeak-Style Prompt Injection and Auditing Your Agentforce Footprint: AI agents that read and act on customer data are the next place privacy obligations and Salesforce configuration collide.

Action Items:

Read the OPC's IPP 3A guidance and decision flowchart, then inventory every channel that creates Leads and Contacts in your org and classify each as direct or indirect.
Build the three fields, the email template, and the record-triggered Flow in a sandbox this week, and test with a bulk import.
Run the backfill for records created since 1 May 2026, then schedule the gap report to your privacy officer weekly.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.