A consumer products client needed shipment tracking on their website. The order data they needed lived in Microsoft Dynamics 365 Finance & Operations: sales order headers and the ship-to address on each one. The job sounded simple. Read those orders through the D365 API and show customers where their shipments are.
The code for that part really is simple. What slows most teams down is access. D365 F&O has a security step that is easy to miss, and the error you get when you miss it doesn't point you to the fix.
Two registrations, not one
Most developers know the first step. You create an app registration in Microsoft Entra ID (formerly Azure AD), give it a client secret or certificate, and use it to request an access token for your D365 environment. That token request succeeds, which makes it look like everything is working.
It isn't. Finance & Operations has its own security model on top of Entra ID. The application also has to be registered inside D365 itself, and it has to be mapped to a D365 user account. Until that happens, a valid token still gets you nothing, because D365 has no user to check permissions against.
The second registration lives here in D365:
- System administration > Setup > Azure Active Directory applications
- Click New, enter the app's Client ID and a name
- Pick the D365 user the application will act as
Give it its own service user
It is tempting to map the app to an existing person's account, often whoever is doing the setup. Don't. When that person leaves or their roles change, the integration breaks, and every change the integration makes shows up under a human's name.
Create a dedicated service user instead, something like SVC_ShipmentTracking, with Azure Active Directory as the provider. Then assign only the security roles the integration needs. For a read-only shipment lookup that means read access to sales orders, customers and addresses. A standard role like Sales clerk covers it, or you can build a custom role limited to the one data entity you query.
That is least privilege in practice. If the app's credentials ever leak, the damage is limited to reading a few order fields, not posting journals.
Use data entities, and test with one row
D365 F&O exposes business data through data entities over OData, at URLs like /data/SalesOrderHeadersV2 on your environment. Many companies also have custom entities that add their own fields, and those are often the ones you actually want.
Before writing any application code, prove the access with a single request that asks for one record ($top=1). A 200 response with one order in it means both registrations, the service user and the roles are all correct. A 401 or 403 means one of them isn't, and it is far easier to fix at that point than after the whole integration is written.
Put the permissions request in writing
In most companies the developer building the integration doesn't have D365 admin rights. We write the request up as a one-page document for the client's D365 administrator. It lists the Client ID, the exact entity, read-only access, the suggested service user and roles, and the test URL. The admin can finish it in ten minutes without a meeting, and the client keeps a record of exactly what access was granted and why.
The takeaway
Most Dynamics 365 integration problems are really access problems. Plan for both registrations, a dedicated service user and least-privilege roles from day one, and the integration code is the easy part.
If you need your ERP data somewhere it isn't today, on your website, in another system or in Power BI, that is the kind of work we do. See how we approach systems integration, or start with a free assessment.