Power Platform Community Forum Thread Details

Hi all,

I've been reading about service principles and for the most part they make sense. I've found some great guides on how to create them (A Visual Guide To Power Platform Service Principal Setup (matthewdevaney.com and Service Principal in Power Automate | Power Platform Universe) but it's not clear on how many you should have and how to divide them up based on tasks you need them to do.

Should the Azure app I create for a Dataverse service principle also have access to the Key Vault? And should I have one of these for each of our environments?
What should I be using a service principle for?
- Dataverse
- Key vault
- One article adds the service principle to the environment as a system admin role
Who can access and use these service principles? If I use one in a flow for Dataverse and connect it using the service principle, who else can now do the same thing as the connector has now been added to that environment? Will it prompt for the secret when someone goes to use it next time? Same goes if I use a service principle for a key vault.
Licencing - I've read conflicting things regarding licencing.

Cheers

Categories:

Microsoft Dataverse with Power Apps

Should the Azure app I create for a Dataverse service principle also have access to the Key Vault? And should I have one of these for each of our environments?

There is no way to do that, EntraID apps provide client id/secrets which could be stored inside key vault and then other services which need to connect to Dataverse using those clientID/secrets will need access to the key vault, the app itself is a stationary object and doesn't do much beyond providing a middle party registration

What should I be using a service principle for?
- Dataverse (YES)
- Key vault (NO)
- One article adds the service principle to the environment as a system admin role (YES)

A service principal (SP) is a non licensed non human "user" of dynamics which can be assigned a security role and then based on the security role this SP can read data from CRM, the third point mentioned is a common practice to use this SP user as an integration account.

Who can access and use these service principles? If I use one in a flow for Dataverse and connect it using the service principle, who else can now do the same thing as the connector has now been added to that environment? Will it prompt for the secret when someone goes to use it next time? Same goes if I use a service principle for a key vault.

anyone with access to clientID/clientSecret provided by the the AAD during app registration can use this. so it needs to be properly secured.

Licencing - I've read conflicting things regarding licencing.

Service principals don't need separate licnese, and also provide far better API connectivity than a licensed user, their sold purpose is to act as an integration user (non human)