App data handling rules: App must specify exact fields: e.g. appointment ID, team assigned, contact status; Data flow must trace source, purpose, audience, and destination with clear end conditions; Australian Privacy Principles (APP 3, 6, 8, 11) apply to personal info collected or shared
Image: No-Code Business Guide

Data Modelling

Part of No-code governance

Defining which business data an app may handle

Set a field-level data boundary for a no-code app, including sources, permitted actions, destinations and review triggers.

Approve an app's data by naming the fields it needs, their sources, permitted actions and destinations. “Can use customer data” is too broad to guide a maker. A usable decision states which customer facts the app may read or change, who may see them and what stays in the supported system.

Start with the task and fields

Record the task and the decision it supports. For a hypothetical appointment follow-up app, staff might need an appointment reference, assigned employee and contact status. They may have no reason to copy a full customer profile or case history. Ask the data owner to mark each proposed field as needed for this task, needed later or outside the app's purpose.

For each field, record whether it is entered in the app, read from another system or derived from other values. Identify which system owns corrections. If the app only needs to display a current fact, consider a controlled lookup before creating another editable copy.

Trace the flow

Follow information from its source through the app to any export, notification, automation or connected service. Include files and logs if they can contain the same information. At each destination, identify who can retrieve it and why.

Decision / Answer to record

Source
Which person or system supplies the field?
Purpose
Which task needs it, and when?
Action
May the app read, create, change or send it?
Audience
Which users need access?
Destination
Where may copies, exports and alerts go?
End condition
When should the app stop holding its copy?

In Power Platform, data policies let administrators control access to connectors and classify them into Business, Non-Business and Blocked groups. That guardrail does not decide whether this app should send a particular field to a permitted destination. Review the app's connected account and access rules as well as the policy.

Apply Australian privacy requirements where relevant

If the organisation is an Australian Privacy Principles entity and the app collects solicited personal information, APP 3's necessity requirements apply. Sensitive information has additional collection conditions. APP 6 governs use or disclosure for another purpose unless an exception applies. APP 11 requires reasonable steps to protect personal information held and, subject to its exceptions, to destroy or de-identify it when no longer needed for a permitted purpose.

These principles do not mean every internal app requires consent or that all personal information must remain in Australia. If a proposed flow may disclose personal information to an overseas recipient, the responsible privacy reviewer should assess APP 8 and the actual service arrangement.

Australian Privacy Principles (APP) Application to App Data Handling

  • APP 3 – Collection of Personal InformationOnly collect personal information necessary for the stated purpose. Sensitive information requires additional safeguards.
  • APP 6 – Use or Disclosure of Personal InformationCannot use or disclose for a different purpose without consent unless an exception applies.
  • APP 8 – Cross-Border DisclosureIf data is sent overseas, assess risks and ensure the recipient complies with Australian privacy standards.
  • APP 11 – Security of Personal InformationTake reasonable steps to protect data; destroy or de-identify when no longer needed.

Key Data Handling Rules for Australian No-Code Apps

  • Sensitive Data Collection3
  • Cross-Border Transfers8
  • Data Destruction11

Record an actionable approval

An illustrative decision might read: “This app may read appointment ID, assigned team and contact status from the approved source for follow-up work. It may write the follow-up outcome to that source. It may not export the customer profile or include case notes in notifications.” An actual approval needs the organisation's own fields, systems and decision makers.

Name the data owner, reviewer, permitted audience and environment. State which changes return for review, such as a new field, broader sharing, another connection or a different purpose. Production acceptance can then check the configured routes against this approved boundary.

More from Data Modelling