Headaches with CallbackRegistration entity, user permissions and CDS triggers in Logic App/Flow

Just a reminder: when creating an automated Flow with a CDS trigger (f.e. Create or Update of certain entity), the service principal used to authorize the API Connection in the background, needs to have full privileges on system entity callbackregistration (german: “Rückrufregistrierung“). Privilege scope User is sufficient.

If you forget this, you might ran into a cumbersome troubles. 😉 The most obvious sign, is that your Power Automate Flow or Logic App does (no longer) trigger. In the overview blade of your Logic App ressource, no invocation is listed so you need to go deeper through See trigger history in order to see every invocation that took place. Entries with Status = Failed and indicate Fired column indicate that this is no regular invocation (from CDS userland) but one that happened internally. Peeking into the trigger output data, we now would see an error message like this, when CDS trigger creation did silently fail in the background:

"Principal user (Id=b21db7e8-2a64-40ea-96d9-ef0e023bf1c4, type=8, roleCount=3, privilegeCount=745, accessMode=4), is missing prvCreateCallbackRegistration privilege (Id=a916618b-c454-45bb-ae0a-c30446362191) on OTC=301 for entity 'callbackregistration'. context.Caller=801866e1-0fd9-43f0-9259-d964984c5446"

Or this, when CDS trigger invocation fails silently after a matching event happened in CRM/CDS:

"Principal user (Id=b21db7e8-2a64-40ea-96d9-ef0e023bf1c4, type=8, roleCount=3, privilegeCount=744, accessMode=4), is missing prvReadCallbackRegistration privilege (Id=a916618b-c454-45bb-ae0a-c30446362191) on OTC=301 for entity 'callbackregistration'. context.Caller=801866e1-0fd9-43f0-9259-d964984c5446"

Purpose of callbackregistration entity

In version 9.0 a new event handler type was introduced to the PowerPlatform (aka Dynamics 365), called WebHooks that can be registered similarly to for example Plugins, and be configured to listen for certain Messages like Create or Update and also be narrowed to certain Attributes only. But compared to Plugins — which consist of custom code that is compiled, published as assembly to CRM and being executed right in the physical context of the underlying CDS/CRM database –, a WebHook is actually just an mechanism used to inform a remote party (represented by an URL-addressable HTTP endpoint) that a certain event has happened. The term WebHook is nothing invented by Microsoft in this context, rather more it’s the name of a well-known HTTP communication pattern for doing a primitive form of Inter-Process Communiation (IPC) by exchanging plain HTTP requests with some well-defined payload. The WebHook pattern is quite popular nowadays and it’s origins reach back already 10+ years, where it has been concepted as a simple, versatile and powerful mechanism to enable a connected real-time web, in which different webservices are able to communicate with each other regardless of their underlying technologie stack.

The way WebHooks has been adopted by Microsoft in the PowerPlatform is quite straight forward. Represented by callbackregistration records, their definition consists basically of the entity type and message a WebHook should be registered on, Attributes that should be monitored, the systemuser responsible for it and what data to be included in the WebHook payload.


In our original case, the problem arised by using a Service Principal for the API Connection used by the CDS trigger of our Logic App or Flow, that had no sufficient privileges to Read the callbackregistration entity everytime a certain entity record was Created or Updated for which a WebHook has been defined (happening automatically in the background when CDS trigger is created in Logic App/Flow → CDS trigger registration will silently fail when Service Principal lacks Create privilege on callbackregistration entity, too).

This little but important detail is unfortunately only mentioned once in a side sentence of a little paragraph across the whole Microsoft documentation, and even asking Google doesn’t yield any further details. Especially when crafting Security Roles with only the really neccessary privileges, such a tiny detail could easily be forgotten.