Tobias is a Power Platform administrator at Meridian Healthcare. He is reviewing a DLP policy for the production environment. A developer needs to build a cloud flow that uses BOTH the Dynamics 365 connector (currently in 'Business') and a third-party appointment scheduling SaaS connector (currently in 'Non-Business'). The developer wants to move the scheduling connector to 'Business' to allow the two connectors to work together. Tobias must evaluate whether this change is appropriate. What are the implications of moving the scheduling connector to the 'Business' data group?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Promoting a connector from Non-Business to Business is like giving it a badge to enter the secure wing. Yes, it solves the DLP grouping problem — but now business data can flow to that third-party vendor. The admin must vet the vendor's data governance before approving the move. Answer: C.
Full explanation below image
Full Explanation
Power Platform DLP policies organize connectors into data groups — 'Business', 'Non-Business', and 'Blocked' — with the rule that connectors in different active groups (Business vs Non-Business) cannot be used in the same cloud flow. Moving a connector between groups is a policy configuration change that has both technical and compliance implications.
Option C is correct and captures the full picture. Moving the scheduling connector from 'Non-Business' to 'Business' achieves the developer's technical goal: the scheduling connector can now be used in the same flow as Dynamics 365. However, this configuration change means that data from Dynamics 365 — which may include patient records, HIPAA-protected health information, or other sensitive business data — can now be passed to the third-party scheduling SaaS system. The administrator must assess whether the scheduling vendor has appropriate data handling agreements (BAA for HIPAA, data processing agreements for GDPR, etc.) and meets the organization's data residency requirements before authorizing the move.
Option A is less complete than C. It identifies the compliance risk but frames it less precisely — it mentions 'data residency' but misses the broader data governance, BAA, and contractual compliance assessment that a healthcare organization's administrator must perform.
Option B is incorrect and dangerous. DLP policies are specifically designed to control data flow between connectors within the same tenant. The 'tenant boundary' is not the only protection concern — moving sensitive healthcare data to a third-party SaaS connector within the same tenant can still violate HIPAA, data sovereignty laws, or contractual obligations.
Option D is incorrect. DLP group assignments are independent of existing flow usage. An administrator can move a connector between data groups at any time; existing flows using that connector will be evaluated against the updated policy the next time they run. There is no requirement to delete flows before reassigning a connector.
Exam tip: DLP policy changes require both technical understanding (which connectors can be combined) and governance awareness (what data risks does the change create). The AB-620 exam tests whether candidates understand that moving a connector to 'Business' is not just a technical checkbox — it opens a data flow pathway that must be evaluated for compliance.