
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
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.



