I recently had the pleasure of being invited to the Microsoft Innovation Podcast with Mark Smith, a prominent member of the Power Platform community.

We discussed a practical rethink of how teams use Power Platform and Dynamics 365 to reduce technical debt, improve governance, and build sustainable solutions. The discussion centres on shifting from tech-first thinking to business outcomes, balancing low-code and pro-code principles, and preparing for AI and Copilot. The key insight is that long-term success comes from disciplined governance, reuse, and choosing when to adopt versus adapt.

Please have a listen here https://www.microsoftinnovationpodcast.com/adopt-vs-adapt-cut-power-platform

Mark Smith (nz365guy) has been a Microsoft Business Applications MVP for over 14 years. He am passionate about helping people reach their full potential, through training, coaching and mentorship.

Please pay him a visit on Linkedin

The Purpose

To dispel a myth – getting certifications will not walk you into a job, at any level. They are simply Microsoft’s way of measuring your understanding of the topics their material on MS Learn is based around – nothing more, nothing less. They are not a measure of real-world experience, or that you know how to apply the material.

Secondly, how some of the questions are worded is very obtuse. Sure, you shouldn’t be spoon fed the answers, but there could actually be multiple correct answers for some questions. Some are even out of date, referencing places to install solutions from that don’t even exist anymore, long replaced by App Source. This is primarily why I am going through the process of preparing for an MVP nomination and offering any views I can to help people – to try and improve this from the inside.

Finally, you can cheat. I’m not going to say where, but many people know that question dumps exist of the answers. Someone could memorise these, never having done the material and be “certified”. They would have no idea how to be a Power Platform developer.

How are they used?

Most organisations will not take certs as an absolute measure of experience. What they may do is use it as a way to engage in conversations about other topics. When we recruit Power Platform developers, we treat them like coders, or any other developer – your experience counts. We also have no desire to push staff to doing the exams, as it may not be for them. However, we do want them to complete the MS Learn material and we have open, varied interviews to gain an undertanding of the applicant and them us.

The platform is constantly evolving and the certs, or the desire to complete the material for them, shows enthusiams to grow with the tools and provide the best possible value to our staff and members, as a non-private organisation.

What should you do?

There are 2 main courses you should do as a bare minimum: PL-900 and 200. You should then work on your experience and discover what part of the platform you want to get deep into.

Then

Work on PL-300 if you wish to become a data analyst and pursue the world of Fabric.

Work on PL-400 if you wish to continue as a pro-developer, into the world of Azure, plugins, PowerFx, etc.

Work on PL-600 when you are a few years in and wish to pursue an architectural role, overseeing design, governance, etc.

But remember, these are complimentary to your experience. Practice matters most.

Summary/Next…

Do not be drawn into the current trend of Power Platform being treated as a quick money earner, like so many development platforms are. Think about what you want from it as a career and work up to that.

The next few posts will continue talking about the industry and buy vs build, if users are always right and agile frameworks. The first video podcast will come soon, regarding data modelling.

The Microsoft and media machine

Where do I start with this? Well, if there’s anything that will turn me off generative AI just out of spite, it’s this. How much MS, Google, Apple and others pump AI like it’s a 1980’s capitalists wet dream of the 2000s, is becoming really detrimental to I.T. Recently, I saw an advert for Norton on TV saying “create fake wifi network” like that’s something you could type in and it would work. Don’t worry about routers and SSIDs and packet sniffing, you’re at risk! Buy our resource hogging software that adds nothing over Windows Defender!

Point being, the companies and their cheerleaders (employees and community members) need to tone it down. Show us the actual benefits and drawbacks, be honest and people will be far more keen to adopt in a way that makes sense. I want to shout out Mark Smith and Luise Freese as they’ve posted quite a few things online with really good critical thinking, considering both sides.

Is it good – Generally?

tl;dr it depends. A colleague and I have been drafting an introduction to Power Platform and Dynamics for non-technical audiences at work, so using it to get better quality wording was quite useful. That’s not something you could use voice assistants or a search engine to do.

Somewhere in the middle was looking for general information like stats, or event information, or weather, etc. It’s good at doing this, but ultimately, it’s just a text version of Siri/Google Assistant/Alexa.

Then comes the more “creative” stuff. Dear god. I moderate the Reddit community and I’ve tried to use Copilot to generate a banner, with the Snoo being in front of a computer doing some Power Platform work. The results were laughable – stood on the desk, mangled text on the screen, all sorts.

Is it good – Power Platform?

Yet again, it depends. Agents are just a rebadged Power Virtual Agents and that was always excellent, especially how it can directly plumb into Teams, Power Automate, Customer Service, etc. Where you use them for exactly what their niche is – you can’t beat it.

If you’re not going this far, prompts for advice can be excellent, like why your flow is failing. This can appear automatically sometimes and gives info where the flow checker is empty. Sometimes they don’t understand your prompt though.

On the bottom end – avoid building things with it at all costs. If your statement is too broad, it’ll wipe out your entire flow, or give you an action with completely incorrect functions.

Summary/Next…

I think what it comes down to at the moment, is for it to be good you have to be very specific and it has to be when there’s a binary result to achieve. The more focussed the usage, the better it is. If you’re trying to be more creative, or the claim that it’s going to replace your job – like every other fad of the last 30 years, forget about it.

Think very hard about what you need from it – sometimes it’s a great compliment, sometimes it’s a huge hinderance. It’s no different to any other tool. Just don’t swallow the idea that Number 5 is alive, as it wont be, plus it’ll be a lot less fun than Johnny.

Next time I’ll be mopping up a few common questions like training, jobs, etc. Then moving into a series about software development in general, complemented by the start of a new (hopefully monthly) video series, with free form conversations about the industry.

p.s. give Hardware Unboxed a visit in the link earlier – they are great guys doing high quality work.

Why automatic?

You don’t need to. Power Pages includes registration options, where people create accounts via your configured authentication methods. However, our use case is contacts are created for various reasons, by staff, from the people registering, and used in various services.

We have a custom authentication service which allow logging in, but they will see the message of not having permissions to view the pages. This used to be solved via workflows/processes, but as everyone should know – they have been deprecated for years.

How via cloud flows?

Ultimately, there are 4 key columns that need updating on the contact and link to a web role. You should already have web roles setup when you built the website in Power Pages and assigned it to required pages and data.

Setup your flow with a trigger that ensures updates to a contact will not result in an infinite loop – ours are state is active, the columns required are already setup, plus other organisation specific data. The base trigger for us is row updated/added with filters.

Next, get the role from the Site Components table, either via get rows if you know IDs will be retained in each environment, or list rows if getting by name. Either way, you should use an environment variable to define the ID or name in each environment (see my previous articles in releases via Azure Devops).

Your 2nd action is where the main problem lies – assignging the web role to the contact.

• The table and ID is obviously contact and the ID of that.

• Relationship is powerpagecomponent_mspp_webrole_contact.

  • There’s strange behaviour here, as powerpagecomponent is where most site elements reside (roles, settings, pages, etc) but mspp_webrole is a virtual table over the top of it (which you can’t access via SQL or webapi) and the one above, which is also selectable via SQL like a table.

• Relate with is the @odata.id column of the role.

  • This cannot be the id with syntax pluraltablenae(id) due to the nature of how these components work, which has been too convoluted to understand.

Finally, update the contact with the following columns:

• Email Confirmed = Yes

• Login Enabled = Yes

• Security Stamp = function guid()

• Username = whatever string that matches the login of your authentication service.

Summary/Next…

I hope you found this useful, it was very frustrating to find the answer, which in turn was actually quite simple. Credit goes to this blog https://community.powerplatform.com/forums/thread/details/?threadid=9f300dd1-b679-47a2-ab58-dcfbb501e82f which helped explain the tables well.

Next, I’ll be switching topics to the current trend of AI and Copilot. Until then, have an excellent end of the year break.

Left Menu

On the left hand side you will see all the usual options such as connections, solutions, etc however they are now moveable and pinnable. They are also contextual to the site you are using, be it Automate Apps or Pages (although Pages is more limited).

The Good

Pinning and moving is obviously by far the best feature here, to create a layout that suits your development workflow individually, as per these screenshots

You will see many contextual options such as process mining on automate or choices on apps, as it saves too many options being available on a single tool. There are also filters for unmanaged and managed solutions.

There are also some very useful features such as editing tables, flows, etc within solutions in new tabs, however they only work within the relevant make site (flows within Power Apps don’t have new tabs for example)

The Bad

If there are contextual options, why does tables appear on automate and open apps? Or websites on apps that opens pages? Solution filtering is also not on automate yet. This is confusing matters tremendously for developers and it should either be a single site for the entire platform and group on the left, or properly segregate the options.

Summary…

This is a more succinct article, as this is the fundamental core of the new interfaces. My recommendation for now would be to use all 3 sites depending what you are editing – apps, flows, sites, etc. Do not cross them over as it will become a poor experience.

However, as always, keep as much as you can in solutions (this blog is primarily focussed on pro-developers at the moment, so this should be a given) and this will naturally happen anyway.

Key Community Members

As well as meeting new people via talks and finally saying hello to those already connected with online, here are some recommendations of very interesting and useful people to follow their work,

Matt Beard, Ben den Blanken and Mark Carrington gave superb talks on extending the platform, especially PowerFx. That’s going to be a complete game changer. Matt is also part of the team that organise Scottish Summit and Mark has some well regarded plugins for XRM Toolbox.

Mike Bassani and Sean Fiene head up the Dataverse team at Microsoft and have some amazing things coming for pro devs, governance and security (cough source control public preview next month cough).

April Dunnam has a YouTube channel about new features, but importantly soft skills and inclusion in the workplace.

An honourable mention to Scott Durow who also not from the conference, has some fantastic technical development videos online with the product teams at Microsoft. I’d also give Will Dorrington a follow who will open your eyes to how to be a lot more strategic with Power Platform, even if you’re a experienced pro-developer and your organisation is progressing down the maturity path.

Platform Extending

There are many options to extend the platform beyond the core tools of model driven apps, Power Automate, business rules, etc. I would follow Mark, Ben and Matt’s work to get more and better detail on this, but I’d like to summarise some key points I discovered about web resources, PCF and PowerFx.

Web resources are commonly JavaScript, which althought powerful are not within the native editors (you edit outside then upload), so it is very hard to debug, unit test, etc. It is also less responsive as it sits higher up the execution stack. There’s always a debate between business rules and JS in terms of out of the box tools or code, but being honest, I don’t think either suit the bill particularly well. Although both are solution aware, so you can tie them into your release pipelines.

PCFs can be written in C# or React, which gives many advantages – they are a lot more responsive as they sit at the same layer as the Microsoft code behind the scenes; react allows use of Fluent UI; also solution aware and browsable via the plugins panel on the left.

I wont mention webhooks and processes here as they are quite old at this point and Power Automate can pretty much do what both used to do.

PowerFx

Although primarily focussed around plugins, PowerFx has the ability to be a total game changer. The primary reason is it currently supporting 4 of the 5 execution pipeline stages: Pre Operation, Main Operation, Post Operation Sync and Post Operation Async. Only the first Pre Validation is currently not supported, but planned. This differs to flows, as they only operate at the very end after the transaction is completed, at an unknown time.

This has the potential to simplify plugins away from C# due to a simpler language and building them directly within the platform. They also have the potential to replace workflows/processes, webhooks, business rules and JavaScript, depending how far Microsoft take it, due to the real-time nature of execution. They also have robust monitoring, unit testing and can use connection references just like flows and apply to flows, model driven apps and canvas apps due to being tied to a table.

They are not fully there though. This is very much in preview, do not support steps like in C# plugins and do not support custom connectors.

If you wish to try it, go to make.preview.powerapps.com, click more on the left, then more again and it will be down the very bottom.

Governance

During an AMA, Mike Bassani mentioned “Power Catalogue” a tool to organise and group customisations, which sounded very useful. Not a great deal of detail was mentioned, but keep an eye out for this.

Source control is coming into public preview this month. This could be a total game changer to allow proper isolated developer environments (like branching) and therefore increase in cadence and reduction in risk during your CI/CD pipelines.

Microsoft Purview now has a Dataverse connector, which is great news for departments needing to act on Subject Access and Freedom of Information requests on this data without custom tools. We are currently testing this in work and I will write an article of my findings soon.

Security Hub is in preview and has many useful features which I wont go into here – but again Microsoft have some articles and presentations on this, please go to the source for more detail. Think Centre of Excellence and Admin Centre, but a lot bigger and a lot better.

Summary/Next…

It is difficult to not make this too long whilst also not copying other peoples presentations. I will write further articles soon, which will go into the detail of various features discussed here, strategic approaches to the platform, plus more.

I will also be starting some YouTube videos to discuss some items that are easier in audio/video format rather than text. But for anything you would like to learn or discuss, please comment, email or contact me on linkedin.

Page Structure

Firstly, visit releaseplans.microsoft.com and you will be taken to 1 of 2 tabs “All release plans”. You will see this is for Dynamics 365 and Power Platform, with all modules and tools segregated

• Left panel – Individual modules of Dynamics such as Sales, Customer Service, etc, or areas of Power Platform such as Apps, Automate, etc. Select each one individually to show the features for that item.

• All release plans – This shows everything from the selected area.

• My release plans – Items you have added to your personal list, from the all list.

• Planned – Features that are yet to be released in any form.

• Coming soon – Features that are due to be released in the next month. Note – this may be in the state of early access, public preview or general availability.

• Try now – Features currently available, but may be in any state.

• Main panel – List of features from the area and period selected. Expand the feature to show details on the left and current dates for each stage on the right.

• Plus symbol – Add the feature to your release plan. This will be retained for next time you login.

Dates of the 3 phases of release may be far apart. For example, a feature in “try now” may have been in public preview in 2023, but isn’t planned for final release until summer 2024. Do not assume Planned, Coming soon and Try it now mean it is a fully production ready feature.

My Release Plan

To use your section, you must be logged in first. In the top right there will be a button, then choose to login as your personal or work Microsoft account

You will see “Power Platform” is available to select in this view, as well as the areas underneath. This allows you to show all items, unlike the All release plan view, or filter by area if you choose.

Items can be expanded in the same way, as well as notes added for your tracking. You will also see the + has now been replaced with a bin, to remove items from your plan.

Finally, the share icon in the top right creates a link that you can share with your teams. This is highly useful as everyone can view the same plan for items that are relevant to your organisation. However there are some caveats to note:

• After a fairly short period, you will need to login again, it doesn’t retain your session onto the next day which is a shame.

• Others cannot modify your plan, only add notes to the items added. Keep this in mind when you choose who manages this list and have everyone inform them what to add or delete, otherwise multiple plans becomes unmanageable.

When you expand the item, sometimes there are links to MS Learn for more details on the feature, such as how to set it up, known limitations, etc. Also don’t forget that when an item moves forward in its release cycle, it may move between the 3 tabs – it has not disappeared, you simply need to look elsewhere for it.

Summary/Next…

This is just a quick intro to what release plans do. You will find how it suits you best, but we have found it extremely valuable in the less than a month we have used it, as it now allows us to keep track of items we intend to research and test. We can then plan far better in when we will make them available to users or technies, rather than be reactive when less information was available previously.

I’ll be following this up with some very interesting features I have researched. These will be spread over time, based on when they actually launch from Microsoft and we have determined the usefulness. I hope you’ll find some value in these.

Some other video and article creators upload content mere hours after Microsoft release their info. Please note this is not be the case with this blog, as everyone knows how to access MS Learn material, so copying and pasting here provides little value to you. This blog is based on experiences in my day job and therefore only features I have used in the real world will be discussed, with a little delay to document those experiences for you.

Is there a blog or information on best practices regarding custom connectors, connections and connections references and how should these be managed in multiple environments? How should these components be shared among devs for proper control?

What are these?

This has been covered in various articles previously and I will not go into the detail of automation, etc as it is covered heavily in the Azure Devops series. But as a brief intoduction to the concepts:

• Connectors: Sevices available to be used by Power Automate, Apps, Copilot, etc.

  • Outlook, Onedrive, Dataverse, Twitter, SQL Server, etc.

• Connections: The account/details with which you will connect to these services. Note – this account will obviously need permission to access these services.

  • Personal/service interactive account, SQL database username/password, external service API key, etc.

• Connection references: Items within solutions that flows use, which in turn point to connections. This prevents the flows using connections directly.

Why do I need references?

If your flow uses a connection directly and it needs to access the service as a different account, the connection will need to change. In turn, the flow will need to be edited. This in turn will mean you have different versions of the flow in different environments, fundamentally defeating the main purpose of multiple environments.

Connection references being used by the flow means the connection (and in turn the account used) can change with no effect on the flow and in turn, reduced risk. This does not mean any changes should happen in non-dev environments, but the concept stands.

How to use in different environments?

Solutions. Regardless of references, flows, apps, you should always use solutions. All customisations (flows, apps, variables, JS, etc) should exist in a number of solutions that suit your use csae and changes are only ever done in the unmanaged solutions in dev. These should then be exported as managed (I’d recommend automatically, see my previous articles covering this). This will prevent any changes being made in those environments and ensure stability of your test and live environments. Microsoft also have a feature coming soon where you can completely lock down an environment to not allow customisations at all.

When you import, If you wish to change the connection it uses, you simply repoint the reference to that connection. Easy and safe.

Sharing between devs?

Using them in dev between multiple devs is a slightly strange answer. If you have a flow that already has an action, let’s say send an email for the Outlook connector – even if that action uses a connection reference that points to another devs connection (this is legitimate in dev) it will continue to work and you can still edit the flow, even if you add more Outlook actions.

The difficulty comes when you want to add new connectors to that flow. Let’s say you want to add a row to Dataverse – even if you have a connection reference that will be exported, you may not be able to see it within a flow that does not already use it. Sometimes it will work, but if it doesn’t, the reason is almost always because you cannot see the connection the reference is pointing at. To solve this, ensure no one else needs to edit flows for it and change the reference to point at one of your connections, it will then work no problem.

Please note an important point: This is dev environment only. Your references should always point to connections owned by a service account in test and live environments (where managed solutions exist), as this avoids issues such as people leaving and accounts being deactivated or deleted.

If Microsoft make this better in the future (ideally being able to share connections), I will cover it in an article, as it will have a big impact.

What about custom connectors?

See above. References will point to connections for your custom connector like connections for any out of the box connector, the behaviour is no different in any way. Obviously it goes without saying, like any customisation – include your custom connector in a solution to export to other environments.

Summary…

I hope this gives a simple but understandable explanation of why and how to use connections and references. I am always happy to clarify anything, please comment here or leave a comment on discord or post on the Reddit community.

Also, as this is the first community question, please feel free to ask for anything you would like to know and I will try to address it in an article.

It may seem a little late to the game to talk about the new designer, but it’s a slight blessing in disguise, as this was planned before Christmas and would have been a very middling observation, with poor performance, missing features, but a lot of promise. Now it has had time to bed in, it’s not perfect but we’re on the right track in a big way.

What came before?

We all know what the old designer looked like, but in case anyone has forgotten, here’s a reminder

It was very visual and did a good job, but it became very clunky when it came to loops (items not moving in or out), moving items to the top of a chain didn’t work, copy and past sometimes worked sometimes didn’t, etc. However, one of the main issues what the sheer space it took up, especially if you used a switch with multiple cases, or parallel branches, as well as not seeing the progress of a loop during a run.

Layout

As mentioned, zooming in and out as well as moving the canvas around makes things a lot more flexible and overcomes the serious issues with space constraints in the old designer. You will see from the example below (text modified to obscure sensitive naming) that loops are a lot more compact and easier to read and manage

Another massive bugbear is also fixed – actions can be moved to the top of a path! In my example above, the 2nd action within the loop couldn’t be moved about the 1st, you had to do it the opposite way around and play a game to get them into order.

Finally, copy and paste. This now works, every time, even if you try pasting into a loop which before regularly gave an error at the top for no reason. One issue is you can only copy 1 action at a time – in the old designer you could do multiple and they would all appear in the list. Let’s hope this will return in the future, but for now I will take a fully working option and do them 1 at a time over a half baked one.

Actions

A huge improvement with creating and using actions is the left panel. Combining everything from within each action and the 3 dot menu, gives a lot more space (body of the email below gives a great example of this) for these items, plus handles them in the exact same consistent clean way.

Advanced parameters can also now be chosen, instead of everything or not appearing.

Finally, the connection appears at the bottom and when you click “change”, it is a far cleaner list to chose from.

I would recommend looking into the rest of this panel yourself, but these are the major benefits for me so far

Runs

When a flow runs, everything you can see is as before, but in the new layout. Therefore it has all the same benefits as above, however there is one major one – loops are now visible in real time! Have a loop of 1000 records? You can see what the first 100 have done without waiting, which is fantastic for development, debugging errors, etc.

However, there is one major gripe with runs. The new designer only appears when you use “test” mode running manually. If you run manually via the “run” option, or it’s an automated run, the old designer appears. It seems bizarre why this is the case and a massive shame, but I’d be shocked if this isn’t update very soon by Microsoft.

Copilot

This is where I try and restrain myself and keep the blog short. In my view, there is one and only one benefit of this – giving you the framework of a flow from scratch. I tried to add a new action and it wiped my entire flow out; I gave it more detail and it did add the action in the correct place, but with the wrong information; I tried to add a condition on the initial trigger and it put the entirely wrong text in the wrong place.

For the effort to figure out what you need to type for the AI to understand it and action it properly, in my view you might as well do the work yourself. You’ll have full control and safety, just like in the good old days of coding.

Overall, I can see why this may suit learners, but despite what some may like to say with AI is going to write all your code, build all your apps, make your breakfast and everything for you (which trying to be polite I see nothing more than a headline to get YouTube clicks), as a professional developer I see no current benefit from it. Current being the key word.

Summary/Next…

I hope this gives a little insight into the day to day changes I’ve been able to make in the real world. I’d highly encourage researching it yourself, as there’s a lot to it, but overall it’s a fantastic update to Power Automate.

Next time I’ll be covering the new changes to the Power Apps and Power Automate interfaces outside of your apps/flows (mostly excellent, with weird inconsistencies). Take it easy and see you soon.

These news posts will be my real world perspective of why I think they are useful, i.e. how the previous version worked (likely poorly) and how this improves on that. Like all my articles, it will have a practical focus.

What happened before?

If you’re not aware, when you use environment variables in a solution, there’s 2 options – default value and current value. Default value means the content will be retained in all environments you import the solution into and cannot be overridden. Current value can be changes per environment on import (if default isn’t set). That’s how Microsoft advertised it, but it wasn’t how it worked.

In reality, default was fine, but current values could only be set once. After that, on 2nd and further imports, you could never set the variable value again, regardless of the source. So both were effectively acting like default values, but based on the target value not the source. It was very bizarre and made no practical sense, with the only way around it being deployment settings files in DevOps pipelines (highly recommended, with a 4 part series recently published, hint hint).

What has changed?

The main detail is in this article from Microsoft. I’m not going to repeat it here and pass it off as my own. You will see that they have now allowed the ability the set the current value of the variable, regardless if anything is set in the source environment. This is massive when you’re importing manually and should have been the behaviour all along.

I have tested this with a current value set and on 1st import, it uses that value, but allows you to edit it. One thing that’s not mentioned in the article, is if you do change it, a button appears for “reset”. On subsequent imports, it has the value you have set in the target environment, which is excellent as you have no risk of setting it incorrectly.

My second test was having a default and current value set in the source environment. This doesn’t seem to make any difference and behaves the same as above during import. However, after import the value is actually set to the default. This is what you would expect, but is very confusing as it is letting you set the current.

My final test was a default set, current not. This showed exactly the same as the 2nd test.

Summary/Next…

Ultimately, this is a massive improvement and if anyone from the MS product team read this, well done, it will be very useful to people. Sadly, due to the very odd default value behaviours, it’s a little 2 steps 1 back situation. Still, we’ll take what we can get.

Next time I’ll have another small news item about the new cloud flow editor, covering the key differences I’ve found day to day.

Terminology: ADO = Azure DevOps. Pipelines Service = Group on left that contains pipelines and releases. Pipeline = Build that exports solutions. Release = Release that imports solutions.

Preparation

There is 1 step you need to perform before we start running your pipelines, as it ensures the account DevOps imports solutions as can access the connections defined in your connection settings file.

• Visit make.powerapps or make.powerautomate and select each target environment.

• Select Connections

• For each connection, click the 3 dots, then Share.

• Enter the name of your app registration that ADO uses in the release.

• Ensure Permission is Can use then save

Repeat the above for all connections and all target environmens.

Running Pipelines

As you will be aware, Power Platform does not use code and therefore does not use a git repo, pull requests, CD, CI, etc, so instigating the process is manual. However, manual is still a different context to fully manual via PP itself.

Firstly, navigate to pipeline service > pipelines > all > the folder you created. Within here you created your multiple pipelines for each solution and each will be run individually. This may seem confusing, as you have multiple pipelines but only 1 release, but the reason is the release can be triggered from any of the artifacts generated from these pipelines.

• Click the 3 dots on the right of the pipeline representing the solution you need to export.

• Ensure Branch/tag is your mainline branch, such as develop, master, etc.

• Click Run

The pipeline will now run completely unattended, version and export your solutions and publish the files ready for the release. You should ensure it did not fail and this should be repeated for each solution you need to export for the work item you have been working on.

Running Releases

This stage, in terms of actioning the running itself is fully automated. Although only 1 release exists, an instance of that release will be created for every successful pipeline. So let’s say 2 pipelines were run in the previous section to export 2 solutions – you will have 2 release instances automatically created, 1 for each and they will release your 2 solutions in completely isolated paths.

The renaming stage will run automatically, then the release will pause before your first environment. This is because you have set a pre-approval condition, to ensure appropriate staff approve it rather than it automatically flying into each environment instantly. To approve:

• Each person (be they individuals in the list or part of a team) will recieve an email from ADO. You can click this to take you to the release.

• If you don’t do the above, you can go to the renamed release instance.

• With both options, click the Approve button underneath the first stage.

• A panel will fly out from the right hand side, you need to click Approve or Reject on here.

You should do the above when you are happy the change has been reviewed and is an appropriate time to import. Once everyone (as individuals or representative of a team) has approved, the stage will start and import the solution automatically.

At this point your ways of working take over and you carry out work your teams are required to, such as QA testing. When you are happy the change is acceptable in that environment, you can repeat the process above for the next environment (you will already have receive the email), all the way to live.

Summary/Next…

This may seem short, but this is really all there is to releasing your solutions to other environments after development. This is by design, to provide the following benefits:

• Faster release process and less manual steps.

• Decreased risk of human error.

• Increased visibility and governance of entire process.

• Increased accountability of process stages and actions to be perfomed within them.

• Increased security with personal accounts not required to be logged in to untake this.

This is a massive step towards improving the overall governance of Power Platform in your organisation. You will start to discover more and more items you can improve from here, such as security, environment structure and we will discuss some of these wider ways of working in future articles, in collaboration with specialists from other fields such as QA, infrastructure, coders.

I hope you have enjoyed this series and it serves as a helpful basis to start your ALM journey. I am openly available to discuss these topics on Reddit, Discord and Linkedin (links on this and all pages of this site), to help others as well as discuss options where we can all learn.

As an important thing to remember – no one is automatically wrong or right, but we should understand ways of working can and should always be improved and we can adapt with that to make things easier and safer for ourselves.

I’ll see you next time.

This guide will also include information such as backing up the solutions, linking work items and others, which are not critical but long term will prove valuable to your team. I will briefly touch on those, to limit the length of this post and give the general idea, but I would highly recommend you use this to research your own preferred extras to have in your ALM strategy.

Terminology of “ADO”, “pipelines” and “pipelines service” are as per previous post.

Preparation

There are a few steps to cover before you can start to create your release, as they will become critical to the whole process and need to be maintained. These are:

• Deployment settings JSON file

• Environment variable values

• Connection IDs

Deployment Settings

In your git repository, you should already have created a pipelines folder in the previous blog post, with a folder for each solution within that. In the first solution folder, create a file named deployment_settings.json and copy the following sample. This name and sample must be exact.

{
"EnvironmentVariables": [
{
"SchemaName": "myorg_VarName",
"Value": "#{EnvVar-myorg_VarName}#"
}
],
"ConnectionReferences": [
{
"LogicalName": "myorg_O365Outlook",
"ConnectionId": "#{ConRef-myorg_O365Outlook}#"
"ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365"
}

The above sample reflects the structure of your file, but the content should match the exact number of environment variables and connection references that are in your solution. If there are none of one, then remove everything between the {} and simply keep the []. This means the structure is maintained, preventing errors, but it is an empty array and the release will now there is nothing to use. If you have none of both, then make them both empty.

• SchemaName – This is the “name” of your environment variable in full, as displayed when you edit it. Not the display name.

• Value – Ensure the format is exactly as above and between the EnvVar– and }# enter the exact same text from SchemaName.

• LogicalName – This is the “name” of your connection reference in full, as displayed when you edit it. Not the display name.

• ConnectionId – Ensure the format is exactly as above and between the ConRef– and }# enter the exact same text from LogicalName.

• ConnectorId – This is the type of connector you are using. Go to your connection (which you should already have in dev), open it and in the URL, copy the value after apiName and replace shared_office365 with this.

You will now have a complete settings file for your solution. Check it in and repeat the above for every one of your remaining solutions, then pull request them all into your main branch (such as develop, depending on your git strategy).

Environment Variables

For each solution that contains environment variables, open the variable and note down the name, value and solution somewhere safe. Once this is done, determine what value each variable should have in your target environments. This may legtimately be the same for every environment, or may be different.

It is best practice to never use default value unless you know the value will never change and you never need to set it. If you do need to set it, ensure default is empty and you use current value in all environments.

Connection IDs

For each solution that contains a connection reference, you will already be aware these point to connections. Therefore, for all the connections you know you use, carry out the following steps. Note: this may not be equal, you may have 3 Outlook references, 2 Dataverse, 1 SharePoint, but the connections themselves may only be 3.

• Go to your connections.

• Open each individually.

• In the URL, copy the text after connectionName as well as noting down the connector and connection reference that uses it.

Setup & Artifacts

Select Pipelines then Releases. From here, click the folder icon and create a new folder under All pipelines. Finally, select that folder then New release pipeline.

The first main stage within your release will be artifacts. In a typical code based project, there will be only one, which will a CI build triggered by a pull request completion (not Connor MacLeod from the Highlander). However, as you may have multiple solutions containing your customisations, you will need to link to all pipelines created in the previous article.

The first will be your git repository, to allow backups of the solutions to be added.

• Next to Artifacts, click Add

• Source type = Azure Repos Git

• Project = the main project you’re working within (viewable in the top left as the second item in the path).

• Source = repository you used or created in the previous articles.

• Default version = latest

• Keep everything else as is.

Next, add your first pipeline (representing your first solution).

• Source type = build

• Source = name of pipeline from previous article.

• Source alias = same text as your solution internal name and global variable in pipeline.

• All other options remain the same as above.

Finally, ensure your triggers are as below.

• Click lightning bolt in top right of artifact.

• Enabled

• No filter

• PR trigger disabled.

Repeat the above 2 steps (not the first git repo) for all remaining solutions/pipelines you created in the previous article.

Rename

For the first part of our stages, we will be renaming the release to something more meaningful and backing up the solution to your git repo.

• Next to stages, click +Add then New stage, then Empty job

• Stage name = something meaningful to you

• Owner = defaults to yourself, but change account if you wish. Notifications will go to this account.

Within the stage, click 1 job, 0 task and you will see the basic structure of a release stage. This is where your steps will exist to carry out many different actions, such as importing, renaming, backing up, etc. On Agent job:

• Agent pool = Azure Pipelines

  • This means the stage will run on your default ADO agent. If you are using different custom ones, select those.

• Agent Spec = windows-latest

• Artifact download = click every item and deselect Select all artifacts

  • This ensures artifacts are not downloaded for this stage, reducing execution time as they are not required.

You are now ready to add a step, by clicking on the + icon next to Agent job. You will see there are many steps available, just like in your pipeline. For this stage, we will use PowerShell.

• Display name = Something meaningful of your choosing.

• Type = Inline

• Script = Write-Host “‘##vso[release.updatereleasename]”$(ReleaseCustomName)

  • This is the command to rename your release. The ##vso command is built into ADO and you can search online for many more. ReleaseCustomName is a variable we will shortly set to contain the text and as we progress, you will see all variables have to be referred to in this format.

Git Backup

Next, we will create another stage for git backups. As understanding how this script works is quite detailed and will not be covered here, feel free to skip this section. Otherwise, this can serve as a basic first step to get it working, but I would highly recommend researching it to maintain it in the future.

• Add a new stage with agent settings as above.

• Add a step with Power Platform Tool Installer

• Add a step with Power Platform Unpack Solution

  • Solution Input File = $(System.DefaultWorkingDirectory)/$(Release.TriggeringArtifact.Alias)/SolutionArtifacts/solution_unmanaged.zip

    • This points to where ADO uses files during pipelines and the directories within it where your artifact from the pipeline was published.

  • Target Folder to Unpack Solution = $(System.DefaultWorkingDirectory)/$(Release.TriggeringArtifact.Alias)/unpack/$(ReleaseCustomName)

    • This points to your solution directory within the ADO directory and a new unique folder within that to place the unzipped files from the solution.

  • Type = Unmanaged

• Add a step with PowerShell

  • Name = your choosing

  • Type = Inline

  • Script = copy the entire text below.

Write-Host "** Setup **"
$branchName = "dataverse/release-unmanaged_solution_backup"
git config --global user.email "xxx@uk.teams.ms"
git config --global user.name "Release_Dataverse-ImportSolutions"

# Check branch exists
if (git ls-remote --heads origin $branchName)
{
Write-Host "** Branch exists - checking out **"
git checkout $branchName
git pull
}
else
{
Write-Host "** Branch does not exist - creating **"
git checkout -b $branchName
}

if (Test-Path -Path './$(Release.TriggeringArtifact.Alias)')
{
}
else
{
New-Item -Path . -Name "$(Release.TriggeringArtifact.Alias)" -ItemType "directory"
}

Write-Host "** Copying unpacked files **"
Copy-Item -Recurse -Force $(System.DefaultWorkingDirectory)/$(Release.TriggeringArtifact.Alias)/unpack/$(ReleaseCustomName)/* ./$(Release.TriggeringArtifact.Alias)

Write-Host "** Checking for changes **"
$changedFiles = $(git status --porcelain | Measure-Object | Select-Object -expand Count)

if($changedFiles -gt 0)
{
Write-Host "** Changes exist **"
Write-Host "** Staging files **"
git add .
git status

Write-Host "** Committing changes **"
git commit -m "Automated Release - $(Release.TriggeringArtifact.Alias)_$(Release.ReleaseId) #9999"

Write-Host "** Pushing to repository **"
git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" push origin $branchName
}
else
{
Write-Host "** No changes **"
}

I will not go into all the detail of this script, but ultimately it is creating a new branch or using one if it already exists, taking the unzipped solution files, checking if there’s changes and commiting them to the branch.

Environment Import

This section will cover importing a solution to a single environment. This stage should be repeated for all other environments, with changing elements detailed at the end.

• Add another stage, but this time ensure agent settings has Select all artifacts ticked for all artifacts apart from your git repo.

• Task: Replace Tokens (this is a 3rd party step, ensure you use the one by Guillaume Rouchon)

  • Root directory: $(ArtifactPath)

  • Target files: $(DeploySettingsFile)

  • Token pattern: #{…}#

    • You will see this reflects the format specified in the deployment settings json created in the preparation section of this guide.

• Task: Power Platform Tool Installer
  Task: Power Platform Import Solution

  • Auth type: Service Principal

  • Service connection: Connection for relevant environment you created in the first setup ADO guide.

  • Environment Url: $(BuildTools.EnvironmentUrl)

  • Solution Input File: $(System.DefaultWorkingDirectory)/$(Release.TriggeringArtifact.Alias)/SolutionArtifacts/solution_managed.zip

  • Use deployment settings file: ticked

  • Import solution as asynchronous operation: ticked

  • Import as a holding solution: ticked

    • This is equivalent to the “stage” option, as a straight upgrade is not possible in DevOps.

  • Activate plugins: ticked if you want flows, etc to be on, unticked if not.

• Task: Power Platform Apply Solution Upgrade

  • Auth type: Service Principal

  • Service connection: Connection for relevant environment you created in the first setup ADO guide.

  • Environment Url: $(BuildTools.EnvironmentUrl)

  • Solution Name: $(Release.TriggeringArtifact.Alias)

This will now import and upgrade your managed solution into your target environment. You will need to repeat all steps from this section for the remaining environments, only changing the service connection to point to a different location.

Pre-Deployment Rules

This section will cover how to place your stages in a specific order, as well as approvals for each. It is key to ensure you are releasing solutions in a specific order and not jumping to live before QA for example. It also ensures you undertake peer reviews and approvals prior to import.

In each stage, click the lightning bolt and person icon to the left, then follow these recommended settings:

Rename

• Triggers: After release

• Pre-deployment approvals: disabled

Backup

• Triggers: After stage, rename

• Pre-deployment approvals: disabled

QA

• Triggers: After stage, rename

• Pre-deployment approvals: enabled

• Approvers: Enter names or groups of people you wish to approve to this step.

• Approval order: Any order

• Policies: The user requesting a release or deployment should not approve it

UAT

• Triggers: After stage, QA

• Pre-deployment approvals: enabled

• Approvers: Enter names or groups of people you wish to approve to this step.

• Approval order: Any order

• Policies: The user requesting a release or deployment should not approve it

Live

• Triggers: After stage, UAT

• Pre-deployment approvals: enabled

• Approvers: Enter names or groups of people you wish to approve to this step.

• Approval order: Any order

• Policies: The user requesting a release or deployment should not approve it

Variables

Environment Variables

This section will cover how we will use your deployment settings file to populate the environment variable and connection reference settings you created at the start of this article.

Click Variables at the top, you will an option to add and you can provide a name, value and scope.

• Name: This should be exactly the same as the Value text of your environment variable in the file. For example EnvVar-MyVariable

• Value: This should be the value you intend to put into the variable.

• Scope: This is the stage in the release where this will be used. This means for each variable, you will need to add multiple versions if the values are to be different between environments and select the relevant stage. Otherwise, if it is to be the same, just select Release.

This is important – you now need to add a variable for every single environment variable you have in all your deployment settings files. Then in the future, if any are added or removed, they should also be added or removed from here. This means if a value is to change, you don’t need to edit the settings file, but it can be done here and is therefore a lot easier to manage. It also provides better visibility of the values.

Connection References

• Click Variable groups

• Click Manage variable groups

• Add a new group

• Give the group a meaningful name, such as Dataverse Connection Refs – QA

• Add all your connection references from all settings files and values from Connection IDs section earlier in this article in exactly the same way as environment variables.

• When done, save.

• Return to your release and click Link variable group and select the group you just created.

The above separates these out from variables, as the values will rarely change, unless you add or remove connections, or change which account you use. Therefore it provides security in not mistakingly changing values within the release.

Repeat the above for all remaining environments, then apply a scope to determine which stage will use each group, just like environment variables.

Summary/Next…

This is a lot of information to take in, so I would recommend reading it first before attempting to create your builds and releases. Once the concepts have fully sunk in, you can then start applying ALM options that suit your organisations needs, such as linking work items, different approvals and more. But this will serve as a solid foundation to build off.

The next and final guide will, you will be happy, be a shorter one to explain how to run these and a summary of general concepts to continue on with.

Please feel free to reach out in the comments, on Reddit or on Discord if you have any questions. I am very active there and happy to help, as well as many other community members.

Ensure you have read, understood and carried out the setup in the previous post, as you will not be able to connect to your source environment in a reliable way. Also ensure your environment, security and licensing strategy is defined and fixed before continuing, otherwise time consuming re-creation of your ALM processes will be required.

Azure DevOps will be referred to as “ADO”.

The whole group containing releases, task groups, etc will be referred to as “pipelines”

“Builds” are the previous term used for what is now “Pipelines”. There is also a service (groups on the left menu such as boards, repos, etc) names pipelines, this can be very confusing. For this guide, pipelines will refer to what you are building and “pipelines service” will refer to the menu item/group.

Preparation

Firstly, you will need to ensure you have a code repository (Git is recommended). If you have an existing repo you wish to use, I would recommend adding an identifiable folder such as “dataverse”, or create a new repo specifically for dataverse/PP/D365 work.

Next, create an initial set of folders as below. You could consider adding more in the future for additional usages such as backups of other components, plugin code, etc. For the location, “root” refers to within your “dataverse” directory or root of repo, depending what you have chosen above.

• pipelines (root) – This will contain folders and files required for solution exports and imports.

• Solution folders (within pipelines folder) – Create a folder for every solution you will use, named the same as the internal name of the solution (no spaces), not the display name.

• solutions (root) – This will contain backups of your solutions after export.

Finally, visit pipelines > pipelines > all > new folder. Enter a name of your choosing to include your pipelines, as there will be many (something like “Dynamics Power Platform”.

Create YAML File

You will need to setup the initial file with the following steps. There is an otion for ADO to create the file for you, but this will be put into the root of the repository, which you may not want.

• Check out your repo to your local machine and create a branch.

• Within your pipelines folder, create a file with a meaningful description and .yml extension. An example is dataverse-export-solution.yml

• Commit and push your branch to the remote repo.

Next, you will start creating the pipeline with this file.

• Click 3 dots on the folder you created, then new pipeline.

• Under where is your code, select Azure Repos Git.

• Select the repository you created or are using in preparation.

• Select Existing Azure Pipelines YAML file

• Select the branch you created above.

• Select the path to the file you created.

• Select continue.

You will now have your empty file within the editor, allowing you to select options from the right, add variables, etc.

Finally, click the arrow next to run, then click Save. Then click the 3 dots, rename and enter a new name of your choice, I would recommend a description followed by the internal solution name, such as Export Solution – MySol1.

Pipeline Core Settings

In this section, we will add the initial variables and settings to the pipeline prior to the main steps. As futher steps and subsequent release depend on this information, it is key to understand why the setup exists..

First, you will need the basic pipeline starter information. Pool defines what virtual machine to run it on (linux, windows, etc). You also need a trigger value, in this case there is none as we are not running the pipeline based off a code check in, pull request, etc. Finally, a name is required which is used to name each instance/run of the pipeline. As we will be creating a pipeline for every solution with a unique name, this should be the version number as it will be easily identifiable and be useful later.

pool:
vmImage: windows-latest
trigger:
- none;
name: $(Date:yyyy.MM.dd)$(Rev:.r)

Next, we will setup a global variable, available to the whole pipeline but not settable.

• Click the variables button in the top right.

• Click the + button.

• Enter your chosen variable name. To align with examples in this guide, I will use SolutionNameGlobal.

• Value should reflect the internal name of your solution. In line with the prep section, I will use MySol1.

• Ensure keep this value secret and let users override options are unticked.

Next, we will need to setup local variables (ones used within the pipeline but cannot be used or seen outside). Each of these are described below, with a code sample.

• deploySettingsFullPath – This is local path (within the ADO build agent) where your git repo is checked out to and the json file within it. Replace your specific folders with the ones created in the preparation section.

• solutionFilesDirectory – Although not strictly required, it will be very useful to have separation in folders for your solutions.

• solutionManagedFileName – A fixed name for your exported managed file, this is very important for releases later.

• solutionUnmanagedFileName – As above, but for unmanaged.

variables:
deploySettingsFullPath: $(Agent.BuildDirectory)\s\dataverse\pipelines-releases\$(SolutionNameGlobal)\deployment_settings.json
solutionFilesDirectory: $(Build.ArtifactStagingDirectory)\$(SolutionNameGlobal)
solutionManagedFileName: solution_managed.zip
solutionUnmanagedFileName: solution_unmanaged.zip

This concludes the initial core of your pipeline. The next section will cover the remaining steps, which are the actual exporting of the files.

Pipeline Steps

This where you will now add steps to your pipeline to perform actions, such as exporting, publishing artifacts, etc. On the right hand “tasks” panel, this will allow you to add items to the file and edit what is already there.

This guide will cover the following steps, to allow you to perform cross-environment releases:

• Version chosen solution.

• Export chosen solution.

• Publish artifacts for release to use.

First, in your .yml file, underneath the variables, add the following line:

steps:

When you perform the next steps, ensure your cursor is underneath the code above. Open the tasks panel by clicking show assistant on the right and type “power platform” into search tasks. This will show you all tasks available to use in your pipeline. As per the previous guide, you will notice these are very similar to the CLI, as they are ultimately wrappers for that. When you add each item, you will be presented with fields to fill in before adding (apart from tool installer). We will now go through each task to add, with the fields to complete and an explanation of what it does.

Authentication type – where available, this should always be Service Principal regardless of the task, as it allows us to use the Azure App Registration.

Service connection – this will always be the name of the connection you created at the end of the last post for your dev environment.

• Power Platform Tool Installer [this is always required once, prior to every series of PP tasks]

  • No values required

• Power Platform Set Solution Version [as with manual releases, this is done prior to export]

  • Solution Name: $(SolutionNameGlobal) [the name of the global variable in the previous section]

  • Solution Version Number: $(Build.BuildNumber) [obtained from the name field populated earlier]

• Power Platform Export Solution

  • Environment Url: $(BuildTools.EnvironmentUrl)

  • Solution Name: $(SolutionNameGlobal)

  • Solution Output File: $(solutionFilesDirectory)/$(solutionManagedFileName) [puts the managed zip file in the specific solution build directory]

  • Export as Managed Solution: ticked

  • Target Version: $(Build.BuildNumber) [to use the version set above]

  • Export async: ticked

  • Advanced > Overwrite local solution.zip: ticked

• Power Platform Export Solution

  • Environment Url: $(BuildTools.EnvironmentUrl)

  • Solution Name: $(SolutionNameGlobal)

  • Solution Output File: $(solutionFilesDirectory)/$(solutionUnmanagedFileName) [puts the unmanaged zip file in the specific solution build directory]

  • Export as Managed Solution: unticked

  • Target Version: $(Build.BuildNumber)

  • Export async: ticked

  • Advanced > Overwrite local solution.zip: ticked

• PowerShell

  • Type: inline [this means you don’t have to store a .ps1 file anywhere]

  • Script: cp “$(deploySettingsFullPath” “$(solutionFilesDirectory)” [this copies your deployment settings json file to the directory that will later be published as an artifact]

• Publish build artifacts

  • Path to publish: $(solutionFilesDirectory) [2 solution zips and settings json are all here, so all 3 will be published for the release to use]

  • Artifact name: SolutionArtifacts [set this to whatever you like, just ensure you remember it for the release]

  • Artifact publish location: Azure Pipelines

Summary/Next…

This concludes your pipeline. From above, you should now see that both a managed and unmanaged solution have been exported from your dev environment, as well as the deployment settings, all ready for the next stage which is importing to your target environments.

Before moving on to the next post to start your releases, ensure you do the following. Repeat the Pipeline Core Settings and Pipeline Steps for every solution you have in your source environment. You will use the exact same yaml file, so the steps should already be there, but you will need to create a new global variable for each pipeline. The end result of this is if you have 5 solutions, you have 5 pipelines, as you will be triggering them individually. There will be a future blog post on how this all runs and ties together.

All examples below will use my organisation environment structure, for ease of explanation via consistency. Dev, QA, UAT, Live with solutions exported from Dev and into the others in turn.

Initial Reading and Preparation

To reiterate one thing from the previous post, all tasks within DevOps are ultimately wrapped for the Power Platform CLI and I would highly recommend reading this first, as even though we are not using it directly, it will help to debug problems.

To understand the basics of what the build tools are, read this page but refrain from setup for now. I will cover this via App Registrations within Azure Portal, which is visually more understandable and maintainable. You can decide to do things differently in the future if you choose.

Read about deployment settings files prior to even thinking about DevOps, as they are fundamental to using DevOps. You will not be able to populate connection reference or environment variable values without them.

Ensure you or an infrastructure colleague have access to Azure Portal from your infrastructure teams. Good practice is this being a different from your regular account, such as an admin account.

Ensure you or a colleague have access to the environments you wish to include, as above typically via an admin account.

Azure App Registration

The following steps below should be repeated for each environment you wish to use in your ALM process. 4 app registrations are required in this example to ensure isolation and security.

• Sign into portal.azure.com

• Open App registrations

• Select New registration

• Enter a meaningful and consistent name, such as Dataverse – ALM – Env Name

• In app registration, select Certificates & secrets

• Click New secret and enter a meaningful name and select chosen dates

• Copy value

  • Do not store this anywhere after you have used it in steps below, it is a security risk.

• In Overview, copy Application (secret ID)

• Copy Directory (tenant) ID

Power Platform Admin Centre

• Sign into the admin centre

• Select your first environment (Dev)

• Select Users on the right

• Select app users list link at the top

• Select New app user then add an app

• Search for name of app registration you created above and add

• Select appropriate business unit

• Assign system administrator role

• Create

Repeat the above steps for the other 3 environments, ensuring the use the 3 other app registrations from above. This will result in the 4 environments each having their unique app users assigned to them.

Azure DevOps Service Connections

• Sign into your organisations DevOps instance

• In bottom left, select project settings, service connections

• Select New service connection, then Power Platform

• Ensure Application Id and client secret is selected

• Enter URL of Power Platform environment, for example https://my-dev-env.crm11.dynamics.com

• Enter directory/tenant ID from above into Tenant ID

• Enter application ID from above into Application ID

• Enter secret value from above into Client secret of Application ID

• Enter descriptive name

• Ensure grant access permission is ticked

Repeat the above steps for the other 3 environments, using the details copied from the 3 remaining app registrations.

Summary/Next…

This will get you to the point where the services are connected and you are ready to start the build part of your pipeline. This will be in the next post, followed by releases.

PP Pipelines are a relatively recent addition that exist within the platform itself and allow to export and import solutions between configured environments.

To a degree, a direct comparison is unfair as they appear to be aimed at different audiences, however due to the nature of both existing, it is worth a discussion.

Pipelines

For more information on and how to setup pipelines, visit the following sites from Microsoft

Overview of pipelines in Power Platform

Set up pipelines in Power Platform

Fundamentally, pipelines export and import solutions, it’s as simple as that. If you require simple exports and imports, with the same behaviour as manual and the account does not matter, I would recommend them. They will be a lot easier to setup than DevOps and will be in an ecosystem you are familiar with (it’s all via Model-Driven Apps), as well as the setup process ensuring strict usage of specific environments and accounts. It will also force you into an order of environments.

On the opposite end, you cannot perform any of the following: linking to work items; approvals; pre-defining environment variable and connection reference values; import as someone who doesn’t own the connections. If you are operating in a team and are trying to achieve full ALM process like coding teams, pipelines are not currently for you, as these are fundamental requirements for that process to happen.

Overall, if Microsoft extend Pipelines to be more feature rich, they could become excellent and a far simpler alternative to ADO. As it stands though, they are more aimed at one audience.

Azure DevOps

As mentioned above, ADO is a far more complex and robust toolset, including releasing. You will have full control of every aspect of connecting to the environment, to what you do within it. This does mean a learning curve and complexity of setting up the releases, however it is fundamentally worth the effort. I will go into more detail on how to set it up in another post, but here are some key benefits:

• Non-interactive users via Azure App Registrations and PP App Users is possible. No license is required and you cannot login – extra security.

• Values in environment variables and connection references can be populated in and used from a configuration file, regardless of who owns the connection the reference will use.

• Approvals prior to each environment (or any stage you choose).

• Automated testing and backups of solutions to git.

• Work items can be updated (read the next post for more info, it’s not the same way as coding).

ADO is nothing special – it is ultimately a wrapper for the Power Platform CLI. This means the more familiar you are with one, the quicker you will become with the other (a very good thing). It would be my one and only choice to achieve true automation within ALM.

Requirements

Power Platform is a software development tool and with any software development project, requirements (functional and non-functional are key). I will start with a controversial statement to many – software is not about developers or IT. It’s not about what code we want to write, what tools we want to use, if we follow scrum or not, it’s about users. Without being able to help people do what they need to do in a simpler, understandable way, it is just a hobby.

With that out of the way, let’s look at requirements. For this, you need a dedicated product/project manager who understands non-technical user needs and what is technically possible. They can draw up change requests, proof of concepts, technical research, etc in tools such as Azure DevOps which by the time it reaches the engineering team, are fully defined and ready to plan and implement. At this stage of my career, I believe developers drawing up their own requirements will not end up with the best software – there will always be technical bias that cannot be challenged by a user due to lack of knowledge.

Engineering / Infrastructure

These teams are 2 sides of the same coin – infrastructure look after the environments, security and licensing; engineering oversee customisation of Dynamics and process creation. All elements have to be done by the nature of the platform, but too many in the hands of one team (or person) is running a very high risk of becoming unsustainable.

Let’s use some examples. All control with engineering focussed staff – they want to get things done and do it quickly. They may use System Administrator roles, not use teams, choose a Dynamics license instead of Power Apps per-user, not have multiple environments to build, test and live – you can see how quickly this will unravel and become a security and cost risk. Infrastructure focussed staff – they will want to ensure security and affordability, but this may make changes slower, using inefficient tools, not release managed solutions – usability will become poor.

Both teams have to exist, specialise in their areas and hold each other accountable. It isn’t about throwing tasks over the wall, but complementing each other to have high quality development, released in a minimised risk way. It is vital for the leads to help team members understand both sides and that each are heavily intertwined with the other.

Testing

Developers cannot reliably test their changes in a full and robust way. We can write unit tests, run flows, check the interface, but QA staff are as specialist in their own area as developers are in theirs. Testing isn’t just running a script (manual or automated) over and over again – that just proves what works – you have to prove what doesn’t work. A combination of manual smoke tests, automated regression and performance, UAT by the organisation are all highly important and if you don’t do them all, you haven’t tested.

Things can also go the other way – too much of 1 thing. Do you do unit tests and mocked integration and real integration and front end and… and… and… which make your builds take 30 minutes to run? It’s too much. Testing needs focus and a reason, just like development needs a reason – it’s all about the users.

We’ll aim to go into this in more detail in the future with a QA lead sharing their ideas.

Releasing

This is a big technical topic that has partially been covered in the previous post about what is Power Platform? To repeat:

• Always have a minimum of 3, if not 4 environments – Dev, Test (QA and UAT), Live.

• Only use unmanaged solutions in dev, nowhere else – really, absolutely, nowhere else.

• Use managed everywhere else – Test, Live, the Moon. You should not be making any changes outside dev.

To add some detail, I would recommend a 5th environment – Prototyping. This is a mimic of dev to allow for proof of concept work, which is still properly planned via your Product Manager, but may not go into full development after demo. If it doesn’t, the changes are reverted, but if it does, the unmanaged solution is copied to dev and continued from there. If staff want to do training, experiment, etc then use trial or developer environments – never let anyone into your non-default environments unless there is a specific need and only for fully defined change requests.

Define your solutions in a structured way that works for you and stick with it. Never create new solutions as you go along – this isn’t a .net project, releasing cannot operate in the same way as code, but even if it could – would you create a new project or class file every time? Of course not. I like to define around business usage, say emails, document management, etc rather than technical item (flows, apps, JS, etc) as you will eventually have dependencies between customisations and will have to include mixed types. It will also make it easier to find your customisations.

To release solutions, always ensure you have connection references within them. If you don’t, you will not be able to retain what accounts are used and fundamentally breaks the premise of solutions.

Use automation. When you import a solution, the owner becomes the person importing and connections the references use have to be owned by that user. This will very quickly become a major issue if that person leaves – the flows will stop, the connections will break and your system will stop working. It may sound extreme, but I’ve seen it happen. Power Platform has a new built-in pipelines option, but I wouldn’t use this as it simply automates a manual import. Azure DevOps is the only robust answer, as you can then use Azure App Registrations which are non-interactive users and therefore will never expire and have increased security. I will be writing 2 full posts soon about Pipelines vs DevOps and how to build a DevOps release.

Conclusion…

All of this ensures consistency between environments and therefore a reliable system the users can trust and developers can support.

• Power Apps – Canvas

• Power Apps – Model Driven

• Power Automate

• Power BI

• Power Pages (formerly Apps Portals)

• Power Virtual Agents

• Dynamics 365

• Dataverse

Trends

There’s always been trends in I.T. from the useful to the fads, Power Platform is no different. The tools were created 6 years ago, with the longest experience around 4 years, but usually 1-2 and primarily canvas Power apps. This is fine, but now we’re going through the explosion of companies jumping on it (presumably as the new thing to make quick money from), there seems to be a dangerous lack of consideration of the platform being more than Power Apps, as well as other topics below.

This is the primary focus of my blog, as I want to spread useful knowledge I’ve picked up in my own job and from colleagues. I love the tools and think they are incredibly powerful, with a lot of potential, however it is incredibly easy to do things badly with no focus on ALM and governance

Not Only Low Code/Citizen Developers

Although it started as a toolset for “Citizen Developers”, there are more and more aspects that need to be considered and technical options available, which now show it is anything but only that. The sheer number of options available (listed above), provide many different approaches to providing what users need, with some being potential replacements to traditional coding methods such as HTML, CSS, JS, .net, Java etc and some complementary. There is no one size fits all in software development and this couldn’t be truer of Power Platform – embrace what they do, but be cautious.

2 key aspects (which you’ll see repeated quite often) that are now incredibly important for pro developers are ALM and governance. ALM (Application Lifecycle Management) should consider the following:

How and where do you make your changes?
How and where do you release them?
Is this manual or automated?
Who can do it?

It is best practice that you should always use solutions. Solutions are effectively groups of customisations, be it apps, cloud flows, JavaScript files, connection references, variables, many things and come in 2 types – unmanaged and managed. You should always make your changes in an unmanaged solution in a dev environment, then release them as managed into QA (any number that suits your org) and live. Never make changes in any environment other than dev, as you will cause layering where next time you import, the updates will never trump the direct change.

Manual exporting and importing is a useful method of releasing, however this comes with certain risks:

Values from variables have to be removed prior to export (very time consuming).
Owners of customisations become the importing account (risky if not a service account).
System Customiser is required for the account performing this action (risk if on a personal account, as this will give access to nearly every part of that environment).
General human error (it’s a manual process).

Automation is possible either via Power Platform pipelines, or Azure DevOps. Pipelines are excellent, but you cannot run tests or external steps, have limited visibility, owners and permissions are as above (the import still happens as the running user). They show a lot of potential, but for enterprise systems, I would not use these in their current early stages.

Azure DevOps is far more robust, as you have full control, can connect as an Azure App Registration, have any type of approvals or gates, backup the zips, link to work items. You cannot operate in the exact same way as coding ALM, such as Pull Requests, as there’s no code to review, but there are ways to mimic this process in alternate ways effectively. This would be my chosen method of releasing to reduce risk and increase efficiency.

Governance

Governance is the definition and management of the operational side of the platform. The most common and critical areas are licensing, environments, security. Without well defined usages of each of these and control of that, the entire platform and applications/processes within it would become unsupportable in months.

Licensing is important as it is so complex. For example – there are 3 direct ways to build Power Apps and Power Automate (free with A/E3 without non-premium connections, Per App/Flow and Per User), with Power Pages and Virtual Agents being usage based and BI having desktop and service. I wont go into the details here, but a useful starting point is keep it basic – use what you get out of the box and don’t dive into wanting hundreds of Dynamics or Power App licences (again – canvas apps are not the entirety of the platform), as that when the common question will soon appear of it being unaffordable. Build, research and iterate your requirements and solutions, then ask on communities like Reddit and Discord for advice.

Environments are fundamental to professional development in the platform. You will always have a default environment and as per Microsoft’s own best practice (see training below), this should be for non-business critical work only. This is the one and only place where the “citizen developer” idea should be allowed and they should not be able to do anything more than standard flows, apps etc. When you start to build a proper ALM process, you should at least have dev, test and live, but I would argue 4 – dev, QA (internal test team), UAT (wider organisation testing) and live. Each environment should have well defined and limited access, such as own accounts in dev, only test accounts in QA and no engineering access to live. This is where security comes in, where those different accounts can use a mix of out of the box roles and custom.

All of the above should be managed by an infrastructure team separate to engineering, but open to suggestions from anyone, as any good agile workplace should. Infra and engineering will act as 2 sides of the same coin to maintaining a safe and productive system, with one having no more influence than the other.

Training

Questions that comes up more regularly than they should are do I need experience to pass an exam? What jobs can I get after passing an exam? Can I get a pay rise after…I think you can see the pattern. Exams have virtually no impact on jobs – forget about them. If you want to do a certification, it should be for you and you only to measure your experience, personal fulfilment, whatever you want from it. The key aspect is the Microsoft Learn material – it is incredibly well structured, covers many topics and a perfect complement to practicing on the job.

That is the key point – practice. Experience wont grow and exams wont be passed by just doing the material, knowing how it relates to the real world is very different and also fulfilling. This is like any IT role – software developer using code, tester, networks and it shouldn’t be expected to walk into senior roles after a year, this is no different in Power Platform.

Key courses to do are PL-900, 100 and 200 in that order. This will give you a great general knowledge to then apply. You can branch out into specifics such as Azure by doing 400, Power BI or chatbots with 300 and 500, all culminating in an overarching view of the entire ecosystem which you will need to be a tech lead, in PL-600. These are difficult – just like a degree is to learn C# or Java, so take from them what you want and need. Visit this page on Reddit which will give a wider view of the various options.