In the first part of this blog series, I wrote about how can we import a Power Platform solution from a user’s context using delegated permission of Dynamics CRM. But what if we want to import a solution from an application’s context, where there is no user interaction at all? In this blog, I’ll try to explain the same.
While Application Lifecycle Management of Power Platform solutions can be done using Power Platform Build Tools in Azure DevOps, solutions can be managed using custom code (PowerShell, Rest API, SDK API) as well. In this article, I’ll try to explain how we can import a Power Platform solution into a target environment using a delegated permission.
I’m a recent college graduate. You get it now, I’m used to do things the hard and long way as constraints like time, ease of development, team collaboration etc. were not applicable to me till now. I was not exposed to industry level problems/constraints, so even if I had great ideas, it used to take me very long to develop a product. I must say I got so overwhelmed with Microsoft technologies when I started working as a Cloud Consultant. Everyday has been a new learning for me since I started my career at Rapid Circle. So this blog is an attempt of sharing my experience of going from “Woah I have to write a lot of code” to “It could be done in a short time, but woah there are so many things out there, what should I choose”. I chose to write about Power Apps because I had worked a lot on native Android when I was in college, and currently I’m exploring Power Apps. There are so many things about Power Apps that I haven’t explored yet, but that’s the story of every tech guy, right?