Thank you! I've been looking for something clear and concise on this exact topic for a while. Most of the apps and flows we're building and deploying are SharePoint-based, so it sounds like Service Principals won't really help us much (or at all). Unfortunately, due to the licensing requirement and cost, it's difficult for us to leverage service accounts. Also, the shared nature of those accounts makes our tenant admins and infosec team hesitant to approve their use.
Big Thanks for this. Excellent Video. I just have a question, can service principal help with sending emails on behalf of other users for the action : send email v(2) - outlook, knowing that its an automated flow
Great video and thanks for the explanation. I wanted to ask if you know whether we are also able to use the service principle for the Microsoft Entra ID connector ?
This is very helpful. Thank you for sharing the knowledge. Do we need service account when publishing the flow having premium connector connected to DB with SPN?
Amazing video!! One question Can we have a policy or a flow to auto-renew the key of the application ID and have this reflected to the service principal flow connection to avoid any flow failure when the key is expired?
Hey Julien, Even if this was possible, I would recommend doing it for those who have an exception because reviewing your Azure apps on a regular basis will help keep that Azure apps list clean.
Hey Daniel, Slightly confused with your statement around service principal not requiring licenses. I understand from MS documentation that either per flow or automate process licenses are needed for service principal owned premium flows. Can you please confirm.
Sure. What I meant is that no additional license is need for the utilization of the service principal connection to the data source. However, the flow maker (and maybe users) will need the license.
A thought on the above point - Based on my understanding, for instance, if a premium scheduled flow is owned by a service principal, it would become a costlier option. This seems like a significant drawback to adopting them. Otherwise, service principals are definitely a thumbs up.
For the change with the run only user shown at 27:42 wouldn't the user who runs it (Finn in this case) need write access to the dataverse table? While the way it was run previously with the service principal, even if Finn had no access to the table it would work since his access level wouldn't really matter in this case right?
My Power Plattform admin sent me this link so I can decide if I want to proceed with a Service Account or a Service Principle. Great video, thank you.
Your admin as great taste in videos 😊. Thanks for the compliment.
Excellent video 👍
Thank you very much!
Thank you! I've been looking for something clear and concise on this exact topic for a while. Most of the apps and flows we're building and deploying are SharePoint-based, so it sounds like Service Principals won't really help us much (or at all). Unfortunately, due to the licensing requirement and cost, it's difficult for us to leverage service accounts. Also, the shared nature of those accounts makes our tenant admins and infosec team hesitant to approve their use.
You're very welcome!
Very thorough and clear. Thank you.
Glad it was helpful!
I really appreciate the way you covered the difference between Service Account and Principal. The demo with configuration was very helpful.
Glad it was helpful!
Thank you for this, its so clear and tells me everything I was missing.
Glad it was helpful!
wow, Dan this is something I also got confused at times. you explained beautifully. Thank you so much!
You're very welcome!
Daniel... Excellent video and very neatly explains. Thanks for your patience and efforts.
My pleasure!
Thank you! This is exactly what I was looking for.
Glad it was helpful!
Amazing, keep up the great work Dan
Thanks, will do!
All your videos are great! Please don't stop! You explained this so well. 🙂🙂🙂🙂
Thank you! Will do!
"run-only permissions" save me, thank you Daniel, I was looking why my azure key vault connection wasn't available for other users
Great video. Thanks!
Glad you liked it!
Great video! You earned yourself a new sub. Thank you so much for putting this together.
Thanks for the sub!
Thank you so much Daniel ! you save my day 😉😉
Glad to hear that!
Nice Video! Thank you so much!
I am still learning things, it's so nice that you offer some informations for free.
Happy to help!
Very informative. Thank you.
Glad it was helpful!
Very good video, very useful, thank you!
Do you have a list of datasources accepting the Service Principal?
Big Thanks for this. Excellent Video. I just have a question,
can service principal help with sending emails on behalf of other users for the action : send email v(2) - outlook, knowing that its an automated flow
Great video and thanks for the explanation. I wanted to ask if you know whether we are also able to use the service principle for the Microsoft Entra ID connector ?
This is very helpful. Thank you for sharing the knowledge. Do we need service account when publishing the flow having premium connector connected to DB with SPN?
Good articulation !! Is there any specific reason that SPN authentication supporting in Power Automate but not in Power Apps?
Amazing video!! One question Can we have a policy or a flow to auto-renew the key of the application ID and have this reflected to the service principal flow connection to avoid any flow failure when the key is expired?
Hey Julien,
Even if this was possible, I would recommend doing it for those who have an exception because reviewing your Azure apps on a regular basis will help keep that Azure apps list clean.
Hey Daniel, Slightly confused with your statement around service principal not requiring licenses. I understand from MS documentation that either per flow or automate process licenses are needed for service principal owned premium flows. Can you please confirm.
Sure.
What I meant is that no additional license is need for the utilization of the service principal connection to the data source. However, the flow maker (and maybe users) will need the license.
@@DanielChristian19 got it! And thank you for all the content that you have made available.
A thought on the above point - Based on my understanding, for instance, if a premium scheduled flow is owned by a service principal, it would become a costlier option. This seems like a significant drawback to adopting them. Otherwise, service principals are definitely a thumbs up.
For the change with the run only user shown at 27:42 wouldn't the user who runs it (Finn in this case) need write access to the dataverse table? While the way it was run previously with the service principal, even if Finn had no access to the table it would work since his access level wouldn't really matter in this case right?
Thanks Dani, Service Principal option available on Dataverse. can we use service principal to access SharePoint or other office 365 services. Thanks
No, unfortunately, it is currently not available for SharePoint 😕
Yes we can use Service Principal to access SharePoint Online
Does that mean using service principal, I don't need any premium license to create flows with Dataverse?
The person making the flow will need the license.
Please make videos on power apps projects from scratch
Will do.
Great video ! can you also create a video on Service Principal vs Managed Identity pls?@DanielChristian19
I'll add this to my to-blog list. Thanks Rahul!