Dynamics Code

Common Data Service (CDS) connector in Flow of Power Automate let you connect to the data source using a Service Principal. David Yack posted the instruction here. If you follow all the instructions, you are all good.

But, it becomes interesting in Flow if security roles from the application user are removed.

The flow editor will still allow you to connect to CDS using a Service Principal. You will still be able to compose different CDS actions and triggers in flow editor.

In the following example, I only register an app and grant Dynamics CRM API permission in the Azure portal. Please note I do not create an application user in CDS.

Now, I use the registered application as a Service Principal. The connection is successful.

I can see metadata like entities and actions.

Now we got the problem

In this example, the flow is configured to trigger on create of Account. However, it will never be triggered when I create a new account record in CDS.

Being a developer, I am not afraid of bugs and error messages except two things – the same generic message for different types of errors and the silent failure without showing any symptoms. This makes debugging a nightmare.

Like a baby

In fact, both behave like a baby.

When a baby is hungry, she will cry. When a baby is sleepy, he will cry. When a baby is sleepy, one will cry. They give you the same message regardless of what they want.

Now, if a baby is not making any sound, you start to worry “Is she ok?”, “Is he too weak to make a sound?”, “Is everything alright?”.

Both cases, a baby gives you no clue.

Silent failure without showing a clue

As I said, the flow will not trigger without showing any errors, if the Service Principal does not have proper permissions CDS. As you can see, the last time my flow is run was 3 weeks ago.

Tip

Always remember to check (double and triple check) if the Service Principal has proper permissions in CDS instance. Failure to do so may result in silent failures.

Train of thoughts

While I am writing this post, I remembered Alex Shlega wrote a post about how Flows and Apps communicate with connectors.

In his case, he cannot compose a flow because of a firewall issue. However, the flow can be run without any problems. What I encounter is sort of exact opposite to him. I can compose a flow but cannot run the flow.

So, I investigated further how Flow editor works. I added a new CDS action and made sure it’s using the Service Principal.

When I clicked Entity name drop-down list, it will make a call to listEnum API.

Here is the full cURL request.

When the bearer token was decoded, it was all about my current login user account. I could not see any information related to the Service Principal.

Apparently, Flow editor will use the current login user to connect to data sources, regardless of the connection you configured in the action.

Not another tip

There may be no errors in your flow. Flow checker may not raise any concerns.

But, always test your flow even after making the smallest change.

There is saying “Seeing is believing”. Allow me to improvise it.

“Seeing the succeeded test is believing”.

What’s next?

I am working on a series of posts focusing on identity, authentication and authorisation on external users. Stay tuned!