A Power Platform administrator is reviewing a DLP policy that has the Microsoft Dataverse connector in the 'Business' group and the Twitter (X) connector in the 'Non-business' group. A developer creates a new Copilot Studio agent topic that uses a Power Automate flow. The flow reads employee salary data from Dataverse and then posts a summary to a corporate Twitter account for a social media campaign. The admin has not changed the DLP policy. What happens when the developer tries to save and publish the Power Automate flow?

Power Platform DLP policies enforce connector group separation to prevent data from flowing between classified connectors. The core rule is: connectors in the Business group and connectors in the Non-business group cannot be used in the same Power Automate flow, Power App, or related artifact.

The correct outcome is that the flow cannot be saved because the DLP policy prevents connectors from the Business group and the Non-business group from being used together in the same flow, regardless of whether either connector is in the Blocked group. The scenario places Dataverse in the Business group and Twitter in the Non-business group in the same flow. DLP policy enforcement evaluates the combination of connectors in a flow when the flow is saved. If the combination violates the Business/Non-business separation rule, the platform prevents the flow from being saved. This is design-time enforcement, not runtime enforcement. The developer will receive an error at save time indicating that the DLP policy restricts the combination of connectors being used.

The idea that the flow saves and runs successfully because both connectors are allowed, and that the DLP policy only blocks connectors in the Blocked group, is incorrect because Blocked is not the only enforcement mechanism in a DLP policy. The Business/Non-business group separation is an equally enforced rule. Connectors in the Blocked group cannot be used at all. Connectors in the Business group cannot be used together with connectors in the Non-business group in the same artifact. Both rules apply simultaneously.

The idea that the flow saves successfully but fails at runtime when the Twitter action executes, because the DLP policy evaluates connector permissions during execution rather than at save time, is incorrect because DLP policy enforcement for connector group separation happens at save time, also called design time, not at runtime. The platform evaluates whether a flow's connector combination is policy-compliant before allowing it to be saved. If it is non-compliant, the save operation fails and the flow is not published. Runtime failure would imply the flow was saved successfully, which is not the case here.

The idea that the flow saves successfully but the Twitter connector action is disabled in the flow designer, preventing the developer from configuring the Twitter connection details, is incorrect because DLP policies do not selectively disable individual connector actions in the flow designer UI. The policy enforcement operates at the flow artifact level, not at the individual action level within the designer. Connectors are not greyed out or disabled within a flow; the flow itself fails to save if the connector combination violates DLP.

Exam tip: DLP connector group rules: Blocked connectors cannot be used in any flow or app. Business and Non-business connectors cannot be in the same flow, and this is the most commonly tested rule. Connectors from the same group, both Business or both Non-business, can coexist. DLP enforcement happens at save time for flows. Memorize this as 'Business and Non-business don't mix — ever.'