Analogy: Getting Access to a Building

If you’ve been building flows in Power Automate for a while, you’ll have used actions and connection references to access services like Dataverse or SharePoint. You’ve possibly also used the HTTP action to call Azure or external APIs.

Connection references are essentially a wrapper around an API, so why the different approach and exactly how are they different? And why sometimes is neither an option, and use of a service principal is required?

Let’s break it down using a metaphor of an office building:

  • Our building has rooms containing different services.
  • We have employees and visitors that want to access the rooms and use these services.
  • The building has a doorman, the API or connector that checks credentials before letting anyone in.

HTTP Action: The Master Key Approach

The Power Automate HTTP action is a raw restful API caller. You define everything manually:

  • Method (GET, POST, etc.)
  • Endpoint URL
  • Headers (including Authorization: Bearer API keys)
  • Body (if needed)

It’s flexible and works with any rest API — but it’s use comes with some risk because an API key is the equivalent of a master key to the office building.

  • You copy the key and hand it to anyone who needs access.
  • It works for every room and service in the building.
  • You have to remember it, protect it, and change it manually.
  • If someone loses it, whoever finds it can also use it.

This is how the HTTP action works. You say:

“I’m here, I’ve got the key, let me in.”

And the doorman says:

“Sure, you have a valid key, I trust you! Come right in.”

But the doorman doesn’t know who you are. There’s no audit trail as to who has used the key, no scoped access, and no way to revoke your access without changing the whole lock — which locks everyone else out too!

Some services (such as ChatGPT) use HTTP but with a username and associated key for each user. This does allow users to be tracked, and only provides access to the services to which the user is subscribed.

Connection Reference: Named Employee with a Badge

A connection reference in Power Automate is like registering a named employee and giving them a badge with specific permissions.

Connection references are tied to specific connectors like Dataverse and SharePoint. You configure them once when they are created, and henceforth Power Automate automatically handles everything for you behind the scenes. The connection references has access to the services assigned to the user. In Dataverse, that is configured via security roles.

A connection reference with Microsoft services expects OAuth 2.0 tokens with specific security requirements. OAuth 2.0 is a security standard. Behind the scenes, using a connection reference is a two-step token process. The connection reference authenticates, gets a token, and uses the token to access the service. All this is managed by the connection reference.

Why use OAuth 2.0 tokens? Tokens are better than HTTP API keys for the following reasons:

  • Time-limited: Tokens expire after a short period, reducing exposure.
  • Rotatable: You can change the secret used to access a token without breaking flows.
  • Auditable: All activity is logged under the user identity.
  • Scoped access: You can assign security in Dataverse or SharePoint to restrict access to specific data.

When the flow runs, the Power Automate connection reference automatically:

  • Requests a token from Azure AD.
  • Uses that token to authenticate each action.
  • Refreshes the token when the existing token expires.

This is how connection references work. You say:

“I’m here, I’m on the guest list, and I have permission to enter these rooms for this amount of time.”

And the doorman checks your badge, confirms your permissions, and lets you in — securely and with full traceability.

Connection references handle the complexity using OAuth 2.0 and make interacting with the Power Platform eco-system nice and easy.

However, if the connected account is disabled or deleted, for example, if a user leaves the company, the connection reference will no longer work. That is why service accounts, generic accounts that don’t belong to an individual user are often used instead.

Why Dataverse can’t be Accessed with HTTP?

Think of Dataverse and other services such as SharePoint as particularly secure rooms in the building.

Dataverse is protected by Azure AD and expects OAuth 2.0 tokens with specific security requirements. You must use a Dataverse action with a connection reference backed by a user identity. This ensures secure, scoped, and auditable access.

To get access to the room, you need to be a known employee who physically signs in and shows an ID. A Power Automate action with a connection reference allows you to do this. The HTTP action does not.

Accessing Dataverse Externally

The Power Automate HTTP action and connection references are fine, for internal employees and apps, but what about apps that live outside the corporate firewall? In our analyogy, these are like external visitors wanting access to the building.

When it comes to accessing the Dataverse room remotely from a non-Microsoft platform, as you can imagine, the requirements are even more stringent.

For external visitors or apps, the Dataverse API is the only way the Dataverse room can be accessed. A normal user account won’t work with the Dataverse API as it requires delegated access meaning the user must sign in interactively. Additionally with a user account, MFA (multi-factor authentication) is often enforced, making automation impossible.

For this reason a service principal is required. A service principal is a secure, non-interactive identity created via an Azure Entra App Registration. It uses credentials to authenticate securely and for this reason, it doesn’t require any user involvement when signing in.

A service principal is assigned one or more security roles, which defines the tables, data and other components it has access to. For additional security, service principals are assigned an expiry date that is defined when they are created.

Think of it like this, for external systems wanting to access the building, only the service principal is trusted enough to be allowed in.

Incidently, service principals can also be used with connection references, and because they are passwordless, they are a better, more secure option, than using service accounts.

Summary

As we now know, not all access methods are created equal!

HTTP

The Power Automate HTTP action offers flexibility for calling RESTful APIs, but it relies on static keys — like handing out a master key to anyone who asks. It’s powerful, but potentially risky, with limited traceability and usually with no scoped access.

Connections & Connection References

Connection references are like named employees with badges. Backed by Azure Entra and OAuth 2.0, they authenticate securely, request time-limited tokens, and access services like Dataverse and SharePoint with full auditing and granular permissions.

Service Principal

A service principal is a non-interactive identity that meets strict security requirements and enables automated access without user involvement.

For external automated systems requiring access to Dataverse, use of a service principal via the Dataverse API is necessary. The service principal is trusted and therefore doesn’t require additional security features such as MFA, so is perfect for automation.

The fact that the service principal is assigned one or more Dataverse security roles means the Dataverse administrator is always in the position of being able to specify exactly what the service principal is allowed to access.

Scroll to Top