Managing Power Platform and Dynamics 365 Deployments – the “developer” knowledge that Functional Consultants and Associates should know

As I continue my learning journey 👩🎓, I was reflecting on what knowledge is considered appropriate to include in the Functional Consultant Associate-level certificates, and what’s been included in certificates identified for “developers”.

In particular, when returning for a deeper-dive into the ‘Work with MS Power Platform Tenants, Environments, Subscriptions and Dynamics 365 Apps‘ Learning pathway that was part of the recent Microsoft ⛅Cloud Skills Challenge, there’s knowledge and best practices here that in my opinion should be included as part of the PL-200 certificate. 📜

I’ve therefore picked out four particular stand-out, related topics to cover in this article:

1️⃣  Placing your Sandbox environment into Administration mode

2️⃣ Taking a Backup before deployment to another environment

3️⃣ Changing the Environment Type from Sandbox to Production

4️⃣ Being able to restore Backups into a Production Environment (if there are issues with your installation – which, of course, there won’t be)

Administering Microsoft Environments for development & customisation work

Whether you’re working in the Microsoft Power Platform or Microsoft Dynamics 365, understanding the functionality that’s available for deploying environment-level developments and customizations is equally as important as learning about application lifecycle management (ALM) best practice and the use of Solutions.

The scenarios where you’d be deploying using these options may be more limited; but to understand them isn’t just about being able to use them where appropriate. It’s also about recognizing when others, such as Power User or Business Units with specific use-cases, may have already done so. 👀

☝ Especially if your Center of Excellence and/or Enablement isn’t fully mature yet (Unless driven from both the top down and bottom up, this can be a long journey to achieve organization-wide).

Or if you haven’t developed other admin and governance best practices, such as an Environment Strategy, Data Loss Prevention (DLP) Policy, and Activity Logs & Analytics. 👌

Placing your Sandbox environment into Administration mode

This was the piece of best practice advice that triggered my ‘wow, I actually didn’t know that; why wasn’t that included as part of the PL-200 modules?’ moment 🤔:

You can set a Sandbox, Production, or Trial (subscription-based) environment in Administration mode, so that only users with System Administrator or System Customizer security roles will be able to sign into that environment. 🤷♀️

Some of the benefits to using Administration mode include:

1. It’s useful when you want to make operational changes and you need to make sure your regular users won’t unintentionally impact your work. Also, vice versa, you don’t want your tailoring / trialing / testing work to affect your (non-admin) end users either.
2. Processes that use code, such as plug-ins or custom workflow assemblies, will continue to be processed by the Microsoft Dataverse platform when Administration mode is enabled. 
3. Background operations, such as asynchronous workflows and server-side synchronizations for appointments, contacts and tasks can, however, be disabled.

System Customizers will need to sign into the environment directly through the URL, however; as whilst it’s in Administration mode, the environment won’t appear to them in the Environments page of the Power Platform admin center.

To set Administration mode:

1. Go to the Power Platform admin center and sign in using Environment Admin or System Administrator role credentials.
2. From the left-side menu, select Environments, and then select a sandbox, production, or trial (subscription-based) environment.
3. On the Details page, select Edit.
4. Under Administration mode, toggle Disabled to Enabled.
5. Optionally, you can set Background operations.
6. Select Save.

Taking a Backup before deployment to another environment

If configurated correctly, all your environments, except Trial environments (standard and subscription-based), will be included in system backups that take place without you having to do anything. 🙆♀️

Whilst undeniably an essential part of your environment admin strategy, there will be occasions when you’ll want to make your own backups separate or in addition to the system ones. For example, before making significant customization changes or applying a version update. 💻

When deciding whether you need to, consider the following factors for both system backups and manual backups:

System backups:

• System backups for Production environments that have been created with a Microsoft Dataverse database and have one or more Dynamics 365 applications installed are retained for up to 28 days. 
• System backups for Production environments that don’t have Dynamics 365 applications deployed in them will be retained for seven days. 
• System backups for Sandbox environments will also be retained for seven days. 
• However, for Managed environments, admins can use PowerShell to change the setting and change / extend the backup retention period to 7, 14, 21 or 28 days. ⏳

Manual backups:

• Whilst automated system backups are useful, you’ll want to make your own backups before making significant customization changes or applying a version update.
• You can back-up Production and Sandbox environments, but you can’t back-up the Default environment.
• The retention periods are the same as for system backups. However as they’re not automatically refreshed, you’ll need to keep a check on the Expiration dates.

• You aren’t limited in the number of manual backups that you can make, and they don’t count against your storage limits.
• In the case of both system and manual backups, you’ll need to restore an environment to the same region in which it was backed up. 🌍

To create a manual backup:

1. Browse to the Power Platform admin center and sign in using administrator credentials.
2. Go to Environments > [select an environment] > Backups > Create.

3. Fill in the information, and then select Create.

There’s no status updates as the backup is processing. When it’s completed, however, the following message is displayed: “The [backup name] backup was successfully created.” 👌

Changing the Environment Type from Sandbox to Production

Once you’ve completed your development / tailoring / trialing work and it’s fully tested in your Sandbox environment, you can make it available to all users in your organisation by changing the environment type to Production.

You do this by:

1. Going to the Power Platform admin center and signing in using Environment Admin or System Administrator role credentials.
2. From the left-side menu, select Environments, and then select your Sandbox environment to change.
3. Select ‘Convert to production’ as shown below.

4.  Select Continue.

5.  And on the confirmation page, select OK.

Now there’s some important caveats here. 👇

1️⃣  The first is where I say “sign in using Environment Admin or System Administrator role credentials”. 

This is based on the assumption that you’ve followed the first best practice option and placed your Sandbox environment into Administration mode before starting your development or customization work.

2️⃣ The second relates to where I say before the steps that you can make your Sandbox environment available to all users in your organization by changing the environment type to Production. 

This actually depends on how you set up the Access rights, such as Security roles, Business units and Maker access to your environments. Also, how those access rights can change depending on the type of environment you’re in (a detailed topic in its own right 🙄).

Being able to restore Backups into a Production Environment

Now here we have to tread carefully, as ‼ you can only restore to Sandbox environments ‼ 🚫

This limitation’s been put in place by Microsoft in order to avoid accidental overwrites of your Production environment.

Which is more than fair! 👍

Besides, it sounds easy enough, though, doesn’t it? After all, we saw above how straight forward it was to change the environment type from Sandbox to Production and vice versa.

We also learnt, however, that the retention periods for Sandbox environments is only 7 days… 🤔

Changing an environment type to Sandbox will immediately reduce the backup retention to align. 😵 If you don’t need backups (aka restore points) older than seven days, then you can safely switch the type. 🙏

If, however, the backup you need to restore from is older than seven days, you’ll need to:

1. keep your current Production environment as is, 
2. restore its older backup version to a different environment of type Sandbox, 
3. change that Sandbox environment to Production, 
4. update the State of the old current Production environment to Inactive.

To restore a system backup:

1. Browse to the Microsoft Power Platform admin center and sign in using administrator credentials. Consider using the less privileged service admin role instead of the global admin role.
2. Go to Environments > [select an environment] > Backups > Restore or manage.

3.  Select the System tab.

4.  Under Select a backup to restore, choose a date and time to select a system backup to restore, and then select Continue.

5.  Select an environment to restore to (overwrite), enter other settings as desired, and then select Restore.

Remember ☝:

• Only Sandbox environments can be restored to.
• Under Edit details, you can change the environment name.

6. Confirm overwrite of the environment.

To restore a manual backup:

1. Browse to the Power Platform admin center and sign in using administrator credentials.
2. Go to Environments > [select an environment] > Backups > Restore or manage.
3. Select the Manual tab.
4. Select a manual backup to restore, and then select Restore.
5. Select whether to include audit logs. Including audit logs can significantly add to the time it takes to restore an environment and by default isn’t done.

6.  Select an environment to restore to (overwrite), and then select Restore.

Remember ☝:

Only sandbox environments can be restored to.

7.  Confirm overwrite of the environment.

In both cases, you’ll still then need to change this Sandbox environment to Production and update the State of the old current Production environment to Inactive. 👌

Exceptions

I did at the beginning of this article equate the importance of understanding the functionality that’s available for deploying environment-level developments and customizations equally regardless of whether you’re working in the Microsoft Power Platform or Microsoft Dynamics 365. 💞

Whilst this is generally true, certain Microsoft Dynamics 365 apps do have App-specific rules that apply to them. ✍

For example:

Dynamics 365 Marketing environments

☝ I’m going to start this section off with the caveat that any or all of the below recommended best practice may, of course, change with the merger of the Dynamics 365 Marketing and Customer Insights apps, resulting in the introduction of Dynamics 365 Customer Insights – Journeys and Customer Insights – Data, and any future synthesis that we might see following this. 👀

• Manual backups don’t include Marketing services (including the Marketing-Insights service) or the data they contain.
• Automatic system backups of Dynamics 365 environments that include those that have the Marketing app installed do include the full organizational database. They don’t, however, include the interaction records (such as email clicks and website visits) or image files (such as those used in emails and marketing pages) stored in the Marketing services.
• When you restore a backup, all organizational data, solutions, apps, and customizations will be present, but no interaction data, insights, or previously uploaded files will be available on the restored system.
• If you need to preserve interaction data and/or images from the target environment, be sure to back up the database for your Marketing services, either to Blob storage to some other storage media. ✅ 

• If you restore data in real-time Marketing, all Consents will return to the state they were in at the time the backup was made. Depending on how many changes to Consents have happened since then, his may result in your Consent data being obsolete.
• To avoid complications, it’s recommended that you export all your Consent data into Excel before starting the restore process, and use it as a reference to reapply any updates after the restore is completed. ✅

Omnichannel for Dynamics 365 Customer Service

Another Microsoft Dynamics 365 app we need to take special care of is Omnichannel for Dynamics 365 Customer Service. 👩⚕️

• Environment lifecycle operations, such as copy and restore of environment, aren’t supported.
• This is because Channel configurations are specific to the environment in which they’re created, so exporting and importing complete configurations as-is won’t work.
• If you do copy such an environment, Omnichannel for Customer Service in the target environment must be uninstalled and provisioned again.

• This is done by selecting Manage from the More commands ellipsis beside Omnichannel for Customer Service, which takes you to the Dynamics 365 Administration Center for Omnichannel.

• The configurations should then be created using the Customer Service admin center app.

In conclusion, I’d strongly recommend double-checking the Microsoft Learn Documentation if you’re planning to carry out installation and environment management on any of the Microsoft Dynamics 365 apps, to make sure you’re up to date with the latest releases and best practices. 👍

Microsoft Learn documentation on Administration Mode can be found at:
https://learn.microsoft.com/en-us/power-platform/admin/admin-mode

Microsoft Learn documentation on Change Environment Type can be found at:
https://learn.microsoft.com/en-us/power-platform/admin/switch-environment

Microsoft Learn documentation on Establishing an Environment Strategy can be found at:
https://learn.microsoft.com/en-us/power-platform/guidance/adoption/environment-strategy

Microsoft Learn documentation on Delete and Environment in Power Platform Admin Centre can be found at:
https://learn.microsoft.com/en-us/power-platform/admin/delete-environment 

About the Author

I’m Sharon. 🤗

I’m a Microsoft Certified and Catalyst Accredited Solution Architect, who works with the customers of an awesome multi-Specialist Inner Circle Microsoft Partner to enable the delivery of their business outcome solutions using Dynamics 365 first party apps, Power Platform, AI and Copilot, and Ecosystem Architecture.

But that’s only been a minute in my career history…

Read more.

References

Smith, S., (2023), ‘Managing Power Platform and Dynamics 365 Deployments’, available at: https://heuristicdev.co.uk/blog-posts/f/managing-power-platform-and-dynamics-365-deployments, [accessed 27th March 2024].