Purchase Order Security Pack for Dynamics 365

Least privilege, applied to purchasing

Security design in Dynamics 365 usually concentrates on what users can do — create, confirm, post. The quieter question is what they can see. My Purchase Order Security Pack answers it for the procure-to-pay process: it filters purchase orders in Dynamics 365 Finance and Supply Chain Management so each user’s view contains only the orders they are directly involved in, as requestor or orderer. It is published on Microsoft Marketplace as Dr Dynamics – My Purchase Order Security Pack; the launch announcement has the full story of the release.

The problem

In many implementations, purchase order visibility is broader than it should be. A user with a standard purchasing role can typically open purchase orders far outside their own responsibility — other people’s orders, other departments’, sometimes other legal entities’. That means unnecessary exposure of procurement data, increased risk, and manual governance standing in where the security model should be doing the work.

The gap bites hardest in a few situations:

• Segregation of duties. Organisations with formal SoD requirements need visibility boundaries the standard roles do not draw.
• Shared environments. Multiple departments or entities in one environment end up seeing each other’s purchasing.
• Sensitive procurement. Pricing, supplier terms and order detail circulate wider than intended.
• Financial overexposure. Teams simply want fewer eyes on financial documents than the default roles allow.

What the pack does

• Restricts visibility to the people involved. Users see only purchase orders where they are the requestor or the orderer — everyone else’s orders drop out of their lists and lookups.
• Extends to related documents. Product receipts and invoices follow the same rule, keeping security consistent across the procure-to-pay chain.
• Aligns security with real responsibilities. Access maps to who actually raised or ordered something, improving data privacy and internal controls without manual workarounds.
• Stays lightweight. It is a focused pack that is easy to implement — not a re-architecture of your security model.

How it works

The pack is deployed to your environment and then activated per security role — no restriction applies until you opt a role in. A user with the Security administrator role opens Security configuration, picks the role to restrict, and enters the security policy context string POMyWorker against it. Once the security configuration is published and the role assigned, those users only see their own purchase orders.

The recommended design is to leave the standard Microsoft roles untouched: copy a role such as Buying agent, restrict the copy, and assign it to general purchasing users, while managers and shared-service users keep the original unrestricted role. That preserves a clean fallback if someone later needs broader visibility. The step-by-step walkthrough — role copies, naming, publishing and how to test with restricted and unrestricted users — is in the Purchase Order Security Pack setup guide.