cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
jzia93
Helper I
Helper I

Power Platform Build Tools Canvas App Owner - cannot share app

Hi,

 

We recently migrated our deployment pipeline into Azure DevOps using the Power Platform build tools, running into an issue with regards to canvas app ownership:

 

We migrate the solution from dev to test as expected, all components work just fine, except I cannot, as the system admin, access the Canvas App.

 

Looks like all components of the solution are 'owned' by the application user in the environment (the one connected to the service principle in Azure DevOps.)

 

This includes the canvas app, such that in the imported Power Apps solutions I can see:

 

Canvas App: MyAppName

Owner: ApplicationUser

 

Problem is, as the system admin for the environment, I can't access the Canvas app, as it has not been shared with me.

 

With the application user being a service account, I also don't know how to share the canvas app.

 

My workaround has been to remap ownership of the application using Power Automate. I migrate ownership from Application User -> System Admin for that environment, and then share the app in the normal way.

 

However, this isn't something I'd like users doing every time we have to import an upgraded solution.

 

Moreover, I'm unsure how changing the owner affects importing newer versions of the solution. I definitely don't want users to have to run a flow everytime a solution is imported, just to be able to access the canvas app.

 

Hopefully I'm missing something and would really appreciate some clarity here.

 

Thank you

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
EricRegnier
Super User II
Super User II

Hi @jzia93,

I believe that's a current limitation. What I've done is have an additional Azure DevOps task that sets the right owner and permissions after the package or solution has been successfully deployed in the target environment. You can have a PowerShell task or even a invoking a Power Automate flow via a http request task.

PowerShell cmdlets: https://docs.microsoft.com/en-us/power-platform/admin/powerapps-powershell

Set App Owner: https://docs.microsoft.com/en-us/connectors/powerappsforadmins/#set-app-owner

Hope this helps...

View solution in original post

15 REPLIES 15
EricRegnier
Super User II
Super User II

Hi @jzia93,

I believe that's a current limitation. What I've done is have an additional Azure DevOps task that sets the right owner and permissions after the package or solution has been successfully deployed in the target environment. You can have a PowerShell task or even a invoking a Power Automate flow via a http request task.

PowerShell cmdlets: https://docs.microsoft.com/en-us/power-platform/admin/powerapps-powershell

Set App Owner: https://docs.microsoft.com/en-us/connectors/powerappsforadmins/#set-app-owner

Hope this helps...

View solution in original post

@EricRegnierthank you for the swift response - much appreciated!

 

Two followups, if you don't mind:

 

  • For deploying/updating across tenants (ISV model with continued updates), does changing the owner affect whether the service principal can continue to apply updates to the app?
  • Also across tenants, is there a way to set the new owner email at runtime - on a per tenant basis? Specifically:
    • Client A, tenant = Contoso, environment = contoso.crm4.dynamics.com,  admin user primary email = john@contoso.com
    • Client B, tenant = Acme Parts, environment = acmeparts.crm5.dynamics.com,  admin user primary email = jane@acmeparts.com
    • Ideally, we would want to configure A, B such that separate owning users are set for each tenant/client (using flow/powershell)

Thank you

  • As long as SPN account has the right access to the target environment, it should be fine. What do you mean by across tenants? If different O365 tenants then you’ll need different pipelines for each because as far as I know, an Azure DevOPs service connection is only bound to one O365 tenant
  • Not sure I understand your scenario. Seems like you have CDS environments by the URL so you don’t need to change the email. These admin account with their emails are configured in O365 and if they have D365 Service Admin or Power Platform Admin role in D365 than they will have admin on all environments. If not you can assign System Administrator role to their respective environment

Thank you for clarifying point 1 @EricRegnier ,  again, much appreciated 😊

 

RE: point 2 - we manage deployments of the same solution to multiple clients, so our CI/CD pipeline aims to keep a consistently updated version for all customers of the same solution (as per this MSFT Ignite Video)

  • In my example, Contoso is one client and Acme Products is another.
  • Each client (Contoso, Acme) has a service principle in DevOps setup so we can patch solution updates to them, as a separate import stage in a single Azure pipeline.
  • Each tenant is a separate O365 tenant and company- so the admin is a different user.

RE part 2: The admin user will be a known individual but will vary between clients (jane vs. john).

 

Based on what you've said, my plan at the moment will be something like:

  • Create variables for each client in DevOps with the admin primary email $(AdminEmail<ClientName>)
  • For each new deployment, either run a flow or PowerShell script in the client environment to migrate the app owner to the admin, building this into onboarding.

Will see how far we get with this approach.

Thanks for clarifying point 2, makes sense. I would actually have a Variable Groups per client, so each client settings is self contained in their own group. Then I would tag the proper variable group per stage (i.e client). Let me know how that goes. Cheers

 

Thanks Eric, I hadn't been using groups until now, I think that's a perfect way to keep everything organised.

 

Will mark your first response as a solution for the time being, as it clarified my initial question.

 

Much obliged!

PowerChewie
Frequent Visitor

@EricRegnier Could you expand on how to perform this directly on Azure DevOps? Everything I have seen online requires you to first find the AppID in order to perform the change, which would defeat the purpose of automating the process using the pipeline. 

PowerChewie
Frequent Visitor

An option is presented in the following video but is not an automated solution 1:25 in the video below.

 

DevOps for Power Platform - YouTube

Hi @PowerChewie, what part exactly would you like me to elaborate? Cheers! 

Helpful resources

Announcements
PA User Group

Welcome to the User Group Public Preview

Check out new user group experience and if you are a leader please create your group

secondImage

Demo Extravaganza is Back!

We are excited to announce that Demo Extravaganza for 2021 has started!

MBAS on Demand

Microsoft Business Applications Summit sessions

On-demand access to all the great content presented by the product teams and community members! #MSBizAppsSummit #CommunityRocks

Power Apps June 2021

June Power Apps Community Call

Did you miss the call? Check out the recording here!

Users online (36,715)