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.

Quick feature comparison of Flows and classical D365 Workflows & what to expect

Finally, I found a comparison chart which outlines dis-/abilities of Power Automate (aka Flows) and the classical Dynamics 365 Workflows. Of special interest for me are pre-images of events and transactions. Looking forward…

Source: Thanks to @prokytom (Tweet)

Sperrige Localization von Zeitangaben an UI – 24:30 Uhr?

Wo ich gerade so die DateTime Werte einiger Datensätze anpasse, sticht mir plötzlich diese merkwürdige UI Localization ins Auge:

Erzwungenes Rewrite von Zeitangaben in Stunde “0”

Welche Uhrzeit ist bitteschön 24:30 ? Vielleicht eine besonders “intuitive” Localization? Nun, ich tippe eher auf einen Bug, da solch eine Zeitangabe meiner Kenntnis nach nirgendwo im europäischen Schrift-/Sprachgebraucht existiert. Who wants to raise a MS support ticket? 😉

Team Member Lizenz: Workaround Custom App Zugriffslimitierung (4/4)

Wie eingangs erwähnt, werden Benutzer mit TML fortan keinen Zugriff haben mehr auf benutzerdefinierte Model-driven Apps sowie die Standard Hub Apps der Hauptprodukte wie z.B. Customer Service, Sales und Project Service Automation. Diese Limitierung ist sehr drakonisch und weitreichend, wo sie doch typische TML Anwendungsfälle wie z.B. kleine hochspezialisierte Fachanwendungen (in Form von Model-driven Apps) untersagt. Damit trifft Microsoft eine scharfe Abgrenzung zur generischen PowerPlatform mit deren eigenständiger PowerApp Lizenzierung. Stattdessen führt Microsoft in der 2020 RW1 eigens für Team Members drei neue Model-driven Apps ein, bei welchen es sich sich jeweils um stark reduzierte und TML-kompatible Alternativen ihrer entsprechenden Hub Apps handelt.

Im Falle der Customer Service Team Member App richtet sich diese jedoch meiner Meinung nach nicht an unternehmens-interne Benutzer, wie man erwarten würde, sondern sie ist standardmässig so konfiguriert, dass sie für den eigentlichen unternehmens-externen (End-)Kunden geeignet ist, um quasi einen Self-service Anwendungsfall abzubilden. Vermutlich deswegen wird sie auch nicht standardmässig installiert, sondern muss vom D365 Administrator explizit installiert werden.

Glücklicherweise können die drei Team Member Apps gecustomized werden, sodass also wie gewohnt je nach Anwendungsbereich individuelle App Experiences implementiert werden können, solange hierbei die Team Member Lizenzbedingungen erfüllt werden.

Doch sollte einem Nebensatz im License Guide besondere Aufmerksamkeit gewidmet werden:

“… Customization [of the standard Team Member Apps] is only allowable if it does not result in a change to core purpose of the specified scenario …”

D365 License Guide, Stand 02/2020

Dieser Vermerk ist zwar sehr schwammig formuliert und lässt somit viel Raum zur freien Interpretation, doch dürfte klar sein worauf Microsoft hinaus möchte.

Abbildung 1: Eigenschaften der Model-driven App “Sales Team Member”; Eindeutiger Name sowie folglich der Deeplink der App können nicht modifiziert werden