By 10 December 2026, most Australian privacy policies will gain a new section on automated decisions. Plenty of them will be too vague to be useful.
We have covered what the new rule says and how to find the automated decisions in your Salesforce org. This guide is about the last step: turning that inventory into wording your customers can understand, and your privacy team can stand behind.
This is general information, not legal advice. Your privacy and legal advisers should make the final call on what your policy says.
What the final guidance settled
On 30 September 2026, the OAIC published its guidance on the new obligation: an updated chapter of the APP Guidelines, a fact sheet and a flowchart. A few points matter most when you sit down to write.
It is not just AI. The guidance covers rule-based tools, everyday software and generative AI. One of the OAIC's own examples is a spreadsheet. In Salesforce terms, that means Flows, scores and routing rules, not only agents.
A human at the end does not take it out of scope. If a program's output is a key factor in the decision, it counts, even when a person signs off.
Good outcomes count too. The rule applies whether a decision affects someone adversely or beneficially, and refusing or failing to make a decision counts as a decision.
Categories are allowed. Vagueness is not. You can group decisions and types of personal information. As Corrs puts it, generic, high-level transparency statements will not be enough. The detail needs to be meaningful to a reasonable person, without burying them in technical specifics.
The three things APP 1.8 asks for
Where the rule applies, your privacy policy needs to describe:
The kinds of personal information used in the operation of the computer programs.
The kinds of decisions made solely by those programs.
The kinds of decisions where the program does something substantially and directly related to making the decision.
That is the whole frame. Your section does not need to explain how a model works, list every Flow, or reveal anything genuinely commercial-in-confidence. It needs to tell a customer what kinds of decisions you make this way, and what kinds of information you use to make them.
From inventory to categories
If you followed our inventory guide, you have a list of every place your org makes or shapes a decision about a person. The writing job is to group that list into categories a customer would recognise.
A practical way to do it:
Group by what the decision does for the customer, not by where it lives in Salesforce. "Whether we can offer you a payment plan" is a category. "Opportunity Flow v3" is not.
Keep separate things separate. Allens notes that processes with different outcomes, purposes or inputs may need to be identified separately. If two decisions use very different data, give them their own line.
Describe the information by type, such as contact details, account history, transaction history or service usage, rather than field names.
Say which kind of decision it is. Is the decision made by the program on its own, or does the program do something substantial and a person makes the final call? APP 1.8 treats these as two kinds, so your wording should be clear about which is which.
An illustration: what this might look like for a typical Salesforce org
Here is an illustrative structure for a fictional organisation running Sales Cloud, Service Cloud, Data 360 and Agentforce. It is an illustration of structure, not legal wording. Your categories, wording and scope will depend on your own inventory and your advisers.
Decisions about offers and pricing. "We use automated tools to decide which offers and prices are available to you. These use your contact details, the products you hold, your purchase history and how you interact with us." (In the fictional org: Data 360 segments and calculated insights that drive offers, and pricing logic in Flow.)
Decisions about eligibility. "We use automated tools to check whether you are eligible for certain services, payment arrangements or support. Some of these checks make the decision on their own. Others prepare a recommendation that one of our team reviews." (Eligibility checks in Flow, with an approval step for some.)
Decisions about how we respond to you. "We use automated tools to decide how quickly your request is handled and which team handles it, based on the type of request, your service level and your history with us." (Case routing and entitlements in Service Cloud. Whether routing is significant enough to include is a question for your advisers.)
Decisions about sales follow-up. "We use automated scoring to help decide which enquiries our team follows up first, based on the information you give us and how you interact with our website and emails." (Lead scoring in Sales Cloud.)
Actions taken by our AI agents. "Some requests are handled by AI agents that can take specific actions on your account, such as [examples]. They use your account details and the information you provide in the conversation." (Agentforce actions and topics.)
Notice what each line does. It names the kind of decision in customer language, the kinds of information used, and whether a person is involved. That is the substance APP 1.8 asks for.
What to call out separately
Sensitive information. The OAIC fact sheet says that where more sensitive types of information, such as health information or biometric templates, are used, this should be clear. Do not fold it into a broader category. If a Data 360 segment or an eligibility Flow uses health information, say so in its own line.
People experiencing vulnerability. The guidance notes a decision may have a greater impact on people experiencing vulnerability. This shapes which decisions you treat as significant, so check your categories with that lens before you finalise them.
Suppliers and AppExchange apps
The obligation sits with the organisation that "arranges for" the program, and the OAIC lists procuring a third-party program as one way of arranging for it. Corrs is clear that using a vendor's software does not transfer the disclosure obligation to the vendor.
So if an AppExchange package, a credit check, a fraud screen or a pricing engine shapes a decision about your customers, it belongs in your section. You can keep how a tool works confidential where that is genuinely commercial-in-confidence. You still need to disclose that it is used, and for what.
Two practical steps: ask your key suppliers for a plain-English description of what their tool decides and what data it uses, and check your contracts let you get that information.
Who signs it off
Three people should see the final wording before it goes live:
Your privacy or legal lead, who owns the policy and the call on what is significant.
Your Salesforce platform owner, who can confirm the wording matches what the org actually does.
Whoever owns customer communications, who can make sure a customer would understand it.
If the platform owner reads the section and says "that is not quite how it works", that is the most useful feedback you will get all month.
Keeping it current
The section is only accurate on the day it is published. New Flows, new segments and new agents will keep arriving, and that is a good thing. It just means the inventory and the policy need an owner and a review rhythm.
A simple approach: add a question to your change process. "Does this make or shape a decision about a customer?" If yes, update the inventory, and check whether the policy wording still covers it.
A month to go
The deadline is close, but this is a very achievable piece of work. Start with the inventory, group it into categories your customers would recognise, call out the sensitive parts, and get the right three people to sign it off.
If you would like a hand mapping your Salesforce org to clear disclosure categories, talk to us. We will leave your team with an inventory they can keep current themselves.
General information, not legal advice.
#sustainablestacks
