It could be weeks, months or even more than over a year that went by of you working hard and preparing your latest masterpiece… However, you got here – you are at the finishing line – ready to go live! But are you truly ready? If you have been keeping a go live checklist since you started the project (more here), you have nothing to worry about.
Then again, if for some reason it was not previously a priority item, check on my recipe for a go live checklist. Depending on the project you have been working on, it might not be a full list or certain aspects might not be applicable. However, it will be a good starting point for you.
In the article below, I’d like to focus on the more functional aspects of going live and leave the business readiness subject, training, etc. for another time. So, let’s dive in and begin a quality check of our ready-to-serve, freshly out-of-the-DEV-oven Power Platform / D365 app.
Settings, settings, settings…
Email exchange settings
In the early days of my functional consultant career, I made some rookie mistakes, but I’ve learnt from them quickly and I’ve never repeated them again. My favourite one till today is an implementation of the D365 Customer Service module for a customer who is required to automatically convert incoming emails to cases. Everything worked perfectly in the system testing and UAT. However, the go-live was a bit of a different story…
Do you know you can configure a date from which all the emails need to be processed? If yes, congratulations – you can skip to the next point. If not, stay with me.
Open the Power Platform admin centre, navigate to Environments, then open the required one and navigate to Settings. From there, expand Email and click “Server profiles”. Select the default one and click “Edit” as shown below. By default, the date that will be populated in there will be when an environment was created.
Ideally, set the state to “Inactive” when creating the Prod environment and set it to “Active” on the go-live date with the appropriate date.
So, the painful lesson back in the day was that the system was flooded with cases created for emails dated months ago (as the Prod was created a few months back) … It took me a moment to get to the root cause of the problem. Once I realised what the issue was, I used the bulk delete and I made changes to the date. After that, I never forgot to check this again.
System settings
Other settings that are worth checking and making sure they are correct are zone and language via the system settings. Additionally, check if the business requires that the users see the welcome screen or not and update the setting accordingly (by default is set to “yes”). You can also adjust session timeout settings and set a custom Help URL. While you are adjusting all those settings, navigate through all the tabs and make sure everything looks as it should. Keep it in mind that Microsoft is constantly changing things, so don’t take it for granted that you remember all the settings. Check all of them and pay special attention to anything new and what are the defaults. You might have to change the defaults to something else – if you are not sure what they mean, do some research, and seek confirmation from the business to make sure that everything is aligned with what is required.
Users’ settings
Ideally, during the users’ training, you showed how to apply personal settings and change the time zone or the time and date format display and how many records are shown per page.
However, sometimes part of the deployment activities is to apply users’ settings for them. It can be done using the XrmToolBox tool – User Setting Utility. The only thing to remember is that it might not be ideal to use with a very large user base - I had some experiences of the tool crashing. Alternatively, split the users and apply the settings in multiple tranches. You can do it by creating views to limit the number of records to process at once, e.g. do it by business units or teams.
Email configuration
Email config is another setting worth adding to your checklist, assuming that the Outlook and D365 integration is in the scope of the project. You can enable all the mailboxes via the environment settings – that works okay for a smaller user base. Or you can use Mailbox Manager in the XrmToolBox. Also, check the queues.
Additionally, if there is a requirement that the users will be able to use the Outlook for app, check if the option “Automatically add Dynamics 365 App for Outlook to all eligible users” is selected (shown below).
Other checks
Audit
The next point that always lands on my go-live checklist is Audit… The key thing to remember here is that when you are adding a table to your solution, check the box “add table metadata” – that will carry the setting for enabling Audit for the tables. But to be on the safe side, once the solutions are deployed to the Prod environment, go through all the tables that require auditing, and make sure that this little tick box against Audit is ticked.
I found it quite important to check this, especially when I had other consultants working with me on the project or when people were joining /leaving throughout the project delivery. Simply, not everyone is aware of this, and I did not know that myself from day one of being a consultant.
Also, make sure that the actual Audit is enabled for the entire environment, so the Audit history is tracked against the tables.
A couple of extra tips:
XrmToolBox offers a Data Restoration Tool that allows restoration of accidentally deleted records. However, audit needs to be enabled for the specific table to be able to restore a record from that table.
If you are using a managed solution (as you should have) and you find a table that isn’t enabled for Audit as it meant to be, re-import the entire solution again with the setting turned on. Remember, when using the new UI (e.g. makepowerapps.com) and a table is already in the solution, you won’t be able to select “add table metadata”. However, you can still do it via the classic interface. Navigate to fields for a specific entity and use “Add Subcomponents”, then include any additional of the out-of-the-box field. By adding that extra field, you will be able to select the "add table metadata" setting.
Access & security
Teams, security roles and licences
There are multiple approaches to set up teams and add security roles to the users or teams. No matter what approach is applied, sense check that the results are as they should be.
All the users should have a licence, teams, correct business unit and security roles assigned to them. Also, check that Teams are in the correct business unit and have security roles assigned to them if you opted in for that type of configuration.
If you can, request a few users with different security roles to navigate via the app to ensure they are not getting any errors. Even with very thorough testing, sometimes things can be missed.
If the users will report any issues – use XrmToolBox to the rescue. Security Debugger allows you to paste the permissions-related error and it will identify what permissions the user needs. However, before making any changes to the security roles and deploying them live, refer to the requirements to verify that the user indeed needs the permission.
Canvas apps
If you are deploying the stand-alone or embedded canvas apps, make sure that they are shared with users as it is done separately from assigning the security roles.
Check, update, activate, enable, turn on...
Workflows, Power Automate and business rules
Another key element of going live is to review all the workflows, Power Automate flows and business rules to ensure that they are all active. Most of the time, this is the case, but sometimes there are situations where there is an issue with e.g. a Flow connection. Therefore, it needs to be fixed and the Flow turned on manually.
Similarly, there might be some issues with workflows. If there are any issues, they should be listed on the import log. Therefore, always make sure to check the log and if a solution was deployed with warnings, review what they are.
Additionally, if you have not checked that before – make sure that all the automation components are assigned to an Application User/Service Principal and that the user has an admin security role. Otherwise, you are risking that the automation will not work or will stop working if the owner user account gets de-activated at some point after the project completion.
Environment variables
Some of us have a love-hate relationship with the environment variables - I know I do… But I couldn’t leave without them now! So, if you want to make sure that they serve as your friends, make sure you update them on the deployment and verify that they are correct. I am probably slightly over-paranoid about them, and I will always check them twice… However, there is no harm in doing that, so high five if you do too. If not, skip to the next point!
Bulk delete & duplicate detection rules
Other aspects worth adding to your checklists are bulk deletion and duplicate detection rules. Check that they are configured properly and are activated.
System integrations
The integration check includes both, the native integrations like Teams and SharePoint and also any custom ones. For the native ones, make sure all the settings are correct and e.g. SharePoint is linked to the correct site. As a functional consultant, I am usually not too involved in the custom integration in detail. However, I would still verify with another team member that everything was checked and is working in the Prod environment.
D365 modules-specific settings
Depending on the type of project you are working on, there also might be some specific deployment checks that you need to take.
For example, for the D365 Customer Service module, check that all the Knowledge Articles are published, all the SLAs and ARC rules are active, and that the holiday schedule is in.
As for the D365 Sales, it is worth ensuring that all the Price Lists are there, and the fiscal year settings are correct.
These are only examples and will vary from project to project depending on what functionality you are implementing.
Prep, data and test
Deployment itself
Have you also planned and prepared for the deployment itself? If you’ve automated the deployment process, make sure that your pipelines are configured properly. If you are going for the manual deployment, I advise you to document all the steps to follow, including the order of implementing solutions. Also, some deployments – e.g. D365 Marketing (erm… Customer Journeys…) or Power Pages require data migration configuration. The best approach is to detail what needs to be migrated and then verify that all the components were deployed to the target environment.
Ideally, you have tested the deployment to the “Test Deployment” environment. If not, and you still have time, I’d recommend doing it to make sure that there are no missing dependencies that might cause issues and delay the actual go-live. Either produce a list or record what you are doing, so you can always refer to it.
Data migration
The go-lives’ without any data migration are still happening, but they are rare, so more likely migration is in the scope of the project. If you are working on a bigger project, you might have someone else who handles the data migration for you. However, as a functional consultant, I would still support the process.
One of the key things is to review and potentially disable the automation that is triggered on record creation. For example, if you are migrating cases in progress and they already have an appropriate owner assigned to them, you do not want any automation to overwrite the case owner or any other details.
Also, if you are migrating records that in the new system will have associated them with business process flows, make sure that the BPFs are updated to the correct stage. And of course, we have the XrmToolBox to help with that as well! Simply, use the BPF Manager.
Last, but not least, is the data migration volumes. If there was no data migration test done into another environment or only sample data was deployed, there is another check for you to do! Have a look at all the charts and check how they display all the migrated data. Sometimes with the large volumes, the chart design you created won’t be readable, hence not useable. You might not have a chance to fix that issue straight away. Nevertheless, if you discover a problem, make sure you raise it and communicate that to all users to make them aware of it.
Smoke testing
Once all the “behind the scenes” checks are complete, smoke test the system by navigating through the most mission-critical user stories/requirements to ensure everything is operational.
Conclusion
From email exchange settings to system configurations and data migration, each element plays a crucial role in the success of the deployment. And every deployment is an opportunity to learn and grow, refining approaches and techniques with each go live. So, my last tip is to create your log of “lessons learnt” from every deployment and apply your learnings at your next deployment. Or are you already doing this? If yes, please share your ideas, thoughts and experiences, so we can learn from each other. And cheers to crafting flawless deployments, one recipe at a time!