These two steps together create the technical identity that the DQE Standalone (Unify) module uses to communicate with Dynamics 365 automatically, without a human user logging in.
Azure App Registration
The Standalone module doesn't connect to Dynamics using a regular user account — it authenticates as an Azure AD application. Registering this application in your Azure tenant produces three values required for the rest of the setup: the Application (client) ID, the Directory (tenant) ID, and a Client Secret. Without this registration, there is no identity Dynamics can recognize as coming from the Standalone application — it's the authentication building block on the Azure side.
Dynamics Application User (S2S)
An Azure app registration alone doesn't grant access to Dynamics data. A non-interactive server-to-server (S2S) application user must also be created inside Dynamics, linked to that same Azure app (via its Client ID), and assigned the DQE security roles — in particular DQE – Unify Application User, which grants read/write access to Account, Contact, Lead and DQE entities, including the Merge privilege. This is what turns the Azure identity into an account that actually has permissions in the Dynamics environment.
In short: the Azure App Registration creates the identity (who connects), and the Dynamics Application User grants it access (what it can do in Dynamics). Both are required because the Standalone application needs to read and write Dynamics data programmatically. The credentials generated during the Azure registration are also reused when creating the application user and when configuring the Dynamics credential inside the Standalone application itself.
Related to