Fabrikam: A DLP Policy That Broke 22 Flows
Fabrikam runs its service desk in a single Default environment: 180 production flows, 40 apps, and 12 Dataverse tables, built by 15 internal makers and two vendor consultants. A newly published data loss prevention policy classifies SharePoint, Dataverse, Outlook, and Teams as Business and blocks everything else. Within a day, 22 flows failed - most read a SharePoint list, call an internal REST API through the HTTP connector, and post the result to Teams. Separately, a vendor edited a shared unmanaged solution directly in the same environment, and a component another team deleted kept reappearing. Fabrikam has no test environment and no solution pipelines.
1. The team wants to unblock the 22 flows immediately. Evaluate the options in order of what should happen first.
Read the worked answer
The fastest fix - moving the HTTP connector into the Business group - is also the worst one, because it grants every maker in the environment the ability to combine internal API calls with corporate data. That is exactly what the policy exists to prevent.
Because DLP policies are scoped to an environment, the correct first move is structural, not a policy edit: create a separate environment for the flows that legitimately need the HTTP connector, and apply a policy there that permits HTTP alongside only the connectors those flows need. Then rerun the 22 flows there. Only after that should the Default environment policy be tightened further, ideally block-by-default so new connectors cannot be added silently.
For the longer term, replace raw HTTP calls with a custom connector fronting the internal API, so the allowed surface is one reviewed connector rather than a general-purpose escape hatch.
2. How should environments and solutions be restructured given two external vendors and 15 makers?
Read the worked answer
Split into development, test, and production environments, with vendors confined to development. Because DLP, security roles, and connector policies are environment-scoped, this separation is what actually enforces the boundary between vendor work and production data.
Deliver everything as managed solutions in test and production; keep unmanaged only where active development happens. This also explains the reappearing component: in a layered solution stack, deleting a component in an unmanaged layer does not remove it if a managed solution above still carries it, so the deletion must be made in the solution that owns the component.
Use a service principal or application user with a scoped security role for any automated deployment rather than a person's credentials, and require every vendor change to arrive as a solution rather than an in-place edit.
3. A maker asks for the HTTP connector so they can call the internal API from a new app. What should the platform team decide?
Read the worked answer
The decision hinges on what the app actually needs, not on the connector name. If the app needs a small, known set of endpoints, the answer is a custom connector built and reviewed by the platform team, published to an environment where HTTP itself stays blocked. That gives the maker the capability without giving everyone the capability.
If the maker needs arbitrary endpoints, the request should be refused and routed through an API gateway or Azure API Management, which centralizes auth, throttling, and logging.
Either way the approval must be tied to scope: which environment, which endpoints, who else can use the connector. Approving HTTP globally to unblock one maker is how the original 22 failures happened in reverse.