Why Learn PowerShell for Power Platform Deployment and Administration Actions?

So you’ve got a task you need to perform; It would be super repetitive and inefficient (or is even impossible) using the standard interface D365/PowerApps gives you. How are you going to do it?

Example: I need to ensure that all my 30 Cloud Flows are deactivated before then reactivated every time after I deploy.

• Out of the box - a mind-numbing one-by-one job
• XrmToolbox - there’s a tool for that

At this point, lots of you would probably reach for XrmToolbox and try find a tool that can help. Am I right?. Let’s see how that scales…

XrmToolbox is great, I just need to load the tool, configure all the 15 options correctly and I’ll be golden. Task done!

Now what if this task needs to be repeated every X days, X week, or every time you (or others in the team) deploy to a different environment?

OK, so I’ll create a 5 page guide for people to follow with screenshots and all the info. Done!

So after 3 months of development and improvements, you now have a 25 page set of instructions.

That’s fine. We enjoy 5 hour deployments where we need to concentrate… if we make a mistake and miss or mess up some steps, there’s only 2 hours of extra troubleshooting we need to do to determine what is wrong… I take that back… there must be a better way?

XrmToolbox and other manual steps are wonderful for one off tasks. But as soon as your regular process depends on it (or any other manual steps where a human needs to drive), it’s a liability.

XrmToolbox can also be inflexible, because it’s only easy to complete the tasks that the author of each tool has catered for.

Why?

• Adding overhead to your deployment process is a really bad idea. If it’s slow/dangerous to deploy in order to validate and get feeback on your changes, generally teams will avoid doing it right until the end. Feedback at the ends costs ££££s.
• As the list of instructions gets longer, it’s more likely people will skip/fail them. This means failed tests and/or defects that will appear; maybe even in production. Again this costs ££££s in time.

So what is the alternative?

Just like for many things, automation is the answer!

PowerShell is a Microsoft scripting language that is the standard for automation for system administrators across all of their products. You’ve already got it installed if you are using Windows.

After some one time setup instructions to install a suitable module PowerShell can easily interact with Dataverse.

$c = get-dataverseconnection -interactive
get-dataverserecord -connection $c -entityname process | 
  set-itemproperty -name statuscode -value Inactive |
  set-dataverserecord -connection $c

Now I just need to save this into a script file and it can be executed (along with anything else I add in future) every time we deploy.

Why not use Power Automate or Azure DevOps Pipeline actions etc etc to do this instead?

You absolutely can. However in my experience both of these options are significantly harder to create and maintain as well as being less flexible when compared to a general purpose scripting language… that’s once you’ve got over the initial learning and when doing something non trivial of course.

PowerShell looks hard! - What’s next?

Fair point! But it’s just as simple as PowerFX and the other expression languages you’ve already managed to pick up across the Power Platform.

Over time, I’m going to try and post some content to help you learn how to apply PowerShell to automate the things people are commonly doing manually during deployment.

Of course this is all a shameless plug for my project Rnwood.Dataverse.Data.PowerShell which improves on Microsoft.Xrm.Data.PowerShell - which is not actually provided by MS. Click the link if you want to know why!

Stay tuned!