The gap between "approved" and "executed" is where the audit fails

Look at a typical change flow at an MSP: the client raises a need in a ticketing system, a coordinator approves, a technician reads the ticket and makes the change in Entra ID — in the portal or with PowerShell. Three systems, two hand-offs, and in the middle a human translating free text into action.

Everything can go right. But the architecture does not guarantee it. The technician can put the user in "Sales-North" instead of "Sales-Norway," assign the license that looked similar, or do everything correctly in the wrong tenant. The ticketing system will still show "resolved," and the approval will still look clean. The discrepancy exists only in Entra ID's own log — disconnected from both the request and the approval. When the client's auditor asks to follow one change from justification to execution, someone has to stitch three sources together by hand and hope the timestamps tell the same story.

Entra Logic's answer is to remove the hand-offs. An order is not free text — it is structured data from the moment it is created: which user, which group, which license, which tenant. The approval happens on that same structured object. And the execution happens when an execution engine runs PowerShell against Microsoft Graph with the order's contents as parameters — no technician re-typing, no interpretation, no "I assumed you meant." What was approved is, by construction, what gets executed.

The technology choice is worth pausing on. PowerShell and Microsoft Graph are the standard way to automate Entra ID — what your administrators already know, already debug and already trust. Entra Logic does not insert a proprietary scripting language between you and Microsoft; it wraps an order-and-approval layer around the tools you use today, and turns running them into a governed, logged event instead of a quick fix.

The result is one coherent audit trail per change: who requested what, with what justification, who approved, what was run, against which tenant, with what result. Not three logs to reconcile — one chain.

For the MSP, this delivers two gains that rarely arrive together. Quality: the category "correctly approved, wrongly executed" disappears as a failure class, and with it a steady stream of correction tickets your service desk currently handles without counting them. And provability: the next client audit is a lookup in one system, not a week of archaeology across three.

Ask yourself: if a client asked tomorrow for the complete trail on the last ten changes in their tenant — how long would it take to answer today? If the answer is measured in hours, the gap is real.