The moment a Power Platform project goes live is both - a significant milestone and the beginning of a new phase called "hypercare." If you have read the previous 2 parts of my “Beyond Deployment” series, you know that this crucial period involves intense system monitoring and user support. These activities ensure a smooth transition and aim to address any emerging issues promptly. However, to sustain success, some additional activities must be planned.
Ups (spikes and highs)
Supporting the support
The hypercare phase typically lasts approximately 4 to 8 weeks, with the initial period being particularly hectic. Expect spikes in user support tickets due to access and security teething issues, as well as some automation hiccups. During this time, it's crucial to have a dual team approach: the support team handles access issues, while the delivery team tackles any system-related problems. This or an alternative division of the hypercare support team ensures a smooth and prompt resolution of issues.
Even if your transition period approach differs, ensure enough resources are trained to assist end users while the delivery team focuses on system fixes. For example, Product Owners and Super Users can temporarily join the support team to help manage the workload.
Ops (operations)
Mailboxes monitoring
If you’re using server-side sync, regularly monitor mailboxes in the early days to ensure they are configured correctly and error-free. Utilise the out-of-the-box dashboards: Server-Side Synchronization Monitoring (shown below) and Server-Side Synchronization Failures.
These tools help diagnose issues with email, appointment, contact, and task synchronization. Despite being deprecated, these dashboards are still functional, although no longer supported by Microsoft.
More information and server-side sync troubleshooting can be found here:
You can access the dashboards via the classic interface advanced settings (shown below).
Dashboard and charts
Other components that are good to check regularly are the dashboards and charts. It’s a good practice to ensure they render correctly with real data. What looks good with dummy data in DEV and UAT might not always display properly with large data volumes in production, so keep that in mind.
BPFs & record deactivation
It’s quite common that users often forget training details and that leads to incomplete tasks, BPFs (Business Process Flows) or record deactivation is neglected. Either ensure automated deactivation or conduct regular data checks to confirm records are deactivated as intended. You can utilise Advanced Find to find and make any bulk updates.
However, before undertaking bulk update actions, communicate this with the business or record owners. Additionally, if you have found any issues with following the agreed process, ensure that the follow-up reminders are sent. That will help to minimise the issues in the post hypercare... As probably not everything will be so closely checked or monitored.
Oops (addressing issues)
Release Management
In the first blog of the series, I have addressed in detail how to approach the users' support. However, some of the reported issues might result in a need to do a deployment to fix it.
Occasionally, multiple fixes are needed daily. Instead of deploying after each resolved ticket, agree on cut-off times with your team and customer for UAT and production deployments. Frequent deployments can be challenging due to numerous moving parts. Ideally, establish a "release management plan" for the hypercare period and document it for customer approval.
Change requests
In some scenarios, especially when there are not many issues, you can also accommodate small change requests from the customer, such as altering field orders on a form or adding an extra value to an option set field. As long as the appropriate governance is in place to manage these requests effectively, this will positively reflect on your relationship with your customers.
Documentation & comms
The next thing to remember is to update the project documentation to reflect any changes from issue fixes or customer requests. This includes handover documentation, user manuals, process guides, and technical documentation. Also, communicate any system changes to end users to keep them informed.
Lessons learned
One of the very last things I would like to do after a project goes live is to hold a lessons-learned session, also called a retrospective.
This is an excellent opportunity for your team to discuss successes and areas for improvement. One of the very effective methods is the sailboat technique. Also, collect your own learning from different projects and apply it in your future Power Platform adventures.
Final Words
If you've been following my blog, you probably might know that I aim to provide comprehensive guides. However, there might still be aspects I've missed. Are you ready for a challenge?
Contribute your thoughts and ideas for part 4, and I'll compile them into a single blog post, fully crediting you on my blog and LinkedIn.
(Send the contributions via LinkedIn or to ania.powerplatform.cookbook@gmail.com).
Let’s continue this journey together!
Comments