Greeting fellows D365 and Power Platform master chefs!
I don’t know how about you, but when I open my kitchen cupboard, I would always like to have my favourite ingredients/products for cooking… or snacking in there. The same applies to when I start a new project. Starting a new project can be both, exciting and daunting.
Exciting, cause probably you only just finished your other project delivery and you are ready for a new challenge, new customer or to apply your new learnings.
Yet, it can also be daunting, with thoughts of building new client relationships, understanding their business, and crafting solutions that truly meet their needs.
But whether you're bubbling with excitement or harbouring a hint of doubt, I've found that setting the stage for success is a crucial step.
After years of working on D365 project deliveries, I've collected invaluable insights from fellow consultants and architects. Today, I want to share with you my "Top 10 Ingredients" that help me with a successful D365 project kick-off. Let's dive in! 😊
1. Chrome profiles
What is your preferred web browser? Personally, I use Chrome as my default web browser. So, the very first thing I would ever do on a project is to set up a new, separate web Chrome profile.
With each profile, I can keep customer-related information, such as bookmarks, history, and passwords, separate and easily accessible. In these profiles, I create dedicated folders for each environment, containing links to solutions, apps, and settings. What's more, I also bookmark a direct link to the specific table (entity) I work with most, saving precious time navigating through solutions.
My Tip:
To access a specific table’s link, open the app designer and choose entities from the Components. Then, right-click on any entity and select “Edit”. This will launch a new window with the entity details. From there, bookmark the URL and save it in the relevant environment folder.
2. Environments
Environment strategy is a very wide subject. However, the key few learnings I gathered over the last few years are as follows:
Always deploy environments by using an unnamed account, such as d365admin@customer.com
As a minimum, have at least 4-5 environments. Typically, I would setup: Dev, SIT (System Integration Testing), UAT (User Acceptance Testing), Training, and Live.
The number of environments should be determined by various factors, such as project size and available storage. Larger projects may require multiple Dev environments for parallel development before consolidating into the main Dev environment.
On some occasions, there would be no separate SIT and UAT environments. However, it is good to separate them as UAT represents testing whether an application meets the business need whereas SIT represents the testing of an application to ensure it meets its engineering specifications.
While some projects may not require separate SIT and UAT environments, it's beneficial to distinguish them. UAT evaluates if the application meets business needs, while SIT ensures it adheres to engineering specifications.
The Training environment is used for users’ training, but I also tend to use it as a go-live “rehearsal” once UAT is completed.
If data migration is in scope, Training environment can also be used to test the migration – either sampled data or a full set. Uploading actual Account or Contact records can help users during the training to bring the context of a new system while working with familiar customer names.
For much bigger data migration, a separate environment is recommended for the test migration.
Where possible, plan and set up all the environments up front. That minimises the risk that you will reach the overall storage capacity at a critical point of delivery and you will be blocked till your customer purchases additional storage to allow you set up a new environment.
The environment setup needs to be discussed with the customer at the very early stages of any new engagement. Sometimes, it will be a solution/technical solution architect's responsibility. However, on smaller projects, I had to take this task on as a consultant.
Pipelines
Again - a very wide subject with multiple options available. However, whatever you decide to do, set your pipelines as soon as all the solutions are created and before the build starts.
I experienced it a few times that there was an ambition to have the automated deployment, but every time that didn’t happen at the beginning of a project, no one down the line had time to do it… resulting in all the deployments being done manually. Personally, I don’t mind manual deployments – the hours I spent trying to troubleshoot some of the deployments in the past were invaluable lessons for me to understand all the quirks and connections that exist in D365, but no one talks about! Obviously, automated deployments won’t save you from errors, but definitely will help you save time on doing each step manually, especially when there are multiple solutions.
3. Solutions
For simple projects, I used to use a single solution and all the components in it, including tables, flows and workflows. However, the bigger the projects you are working on, the more potential issues you might encounter during a deployment. Therefore, I found it quite useful to separate my build into separate solutions. For example:
Metadata (includes all the tables, with respective fields, views and forms; also BPFs, ARC rules, etc.),
Automation - classic (workflows, plugins),
Automation - flows (Power Automate),
Web resources (JavaScript, CSS, Images, Web API).
4. XrmToolBox
XrmToolBox is an absolute must for me for any D365 project! As much as I enjoy creating Power Automate flows, I would definitely not be able to create a fetch xml query without use of it.
If you know the tool inside out – congrats, you are a seasoned pro. If you don’t – don’t worry, it took me a while to get introduced to it
So what exactly is it? It is a a community-driven tool that assists Dynamics 365/Power Platform administrators and developers in their daily tasks. It provides a collection of tools and features to simplify and enhance the customization, configuration, and development processes within D365 and PP. XrmToolBox is an open-source project, and its extensibility allows developers to create and contribute their own tools.
My key piece of advise is to configure it as soon as possible once you start on a project… few times too many I was quite engaged in the build process when I realised I need to use XrmToolBox, but I haven’t setup it up yet! So it delayed my progress at the time… and sometimes by the time I had it done, I forget why I needed it for!
5. Custom model driven apps vs. native apps
One of the key elements when deciding on D365 implementation is if using the native apps or custom model driven apps is a better approach. There are some advantages and disadvantages for both:
Custom apps let’s you build your navigation from scratch and add only the components you need, including only specific tables, views, dashboards or business process flows. They provide a unique tailored experience and different versions of customs apps within a single organisation can be used by different teams or group of user. However, they do require more ongoing maintenance. Additionally, some features can not be supported within them as yet. For example, if your customer has the Customer Service license, they cannot benefit form using the Smart Assist functionality as it is only currently limited to be used in the Customer Service Workspace.
Native apps like Customer Service Workspace or Sales Hub provide a fully ready and operational app to use. They also come with additional features that are only specific to them and cannot be configured in a standard model driven app. You can still customise them to better fit your customer needs. However, there might be some hesitation around using them as they are subject to regular updates. Therefore, if your customer require a tighter control over their apps and do not require specific features, model driven apps can be a better fit for them.
6. UX & UI
There are limited controls when it comes to changing UI of the apps, but take the advantage of what you can change. One of the things you can change in the environments are e.g. navigation bar colours and ability to add a logo.
My common practice is to have each of the environment in a different colour – Dev in green, UAT in orange, Training in blue. For the production environment, I would usually discuss with the customer what colour it should have or use the company main colour. You can use tools like the Colour Picker (Chrome extension) to go to a company website a grab a colour from their logo in RGB. You can also download a logo to use, but it is better to ask the customer for a copy as they usually have a good quality copy.
When it comes to the UX, there are also limitations what can be controlled, but there are few things to have in mind. For more details, visit my blog https://www.ppcookbook.com/post/template-how-to-write-a-recipe-post-1
7. Level Up
Every time you would setup a new Chrome profile, do not forget to add the Level Up Chrome extension (or alternative is Dynamics 365 Power Pane, both have fairly similar functionality).
Level Up Chrome Extension for Power Platform and D365 is a tool that helps you perform common tasks faster and easier when working with Dynamics 365 or Power Apps. Some of the features of this extension are:
God Mode
Allows you to see all the fields on a form, even the hidden ones. You can also edit the fields and save the changes.
Record Properties
Shows you the created on, created by, modified on, modified by, and owner of the current record. You can also copy the information to the clipboard.
Logical Names
Shows you the logical names of the fields on the form.
Show Option Set Values
Shows the option set values of the fields on the form. You can also copy the values to the clipboard.
Show Entity Metadata
Shows the metadata of the current entity, such as the entity name, display name, primary field, primary image, and attributes. You can also copy the metadata to the clipboard.
These are only few on the most used by me options, but there is much more! For those who do not want to create separate Chrome profiles and the individual bookmarks within it, the entire “Navigation” tab can be a good alternative. From there, you can easily navigate to solutions, mailbox, advanced find, Power Platform admin. (It would still require at least 3 clicks while e.g. opening a specific solution from bookmarks would be only 2!)
8. Security roles
When I first started working on D365 projects, I would leave the security setup to do as last. Nothing more wrong and I learnt it quickly that better is to work on the security roles in parallel to all of the work. From my experience, 50% or more of the post-go-live teething issues that users experience is due to the incorrect user permissions in the security roles. There were few different reasons why it happened, but the most common scenarios included customer not knowing exactly what is required for the security setup and the testing being performed using either admin role or one of the out-of-the-box entities.
Therefore, my key advice is – start as soon as possible. Discuss with the customer how the security roles work in D365 and cover not only the privileges and levels for the entities. Also define miscellaneous privileges like e.g. who can and cannot export to excel, create user dashboard or bulk edit.
All the security roles in scope should be updated as soon as e.g. you create a new custom entity or new BPF.
Of course, it is still possible that something can be missed during all the testing and there still might be a user or 2 who will experience some issues, but in those cases – XrmToolBox and XXX to the rescue!
9. Naming convention
Consistency is a key across the board, especially when it comes to the naming convention for fields, relationship names, flows or workflows. There is not really a bad or a good approach, but it is important that if there are multiple consultants and developers working on a single platform, the follow the same naming convention. That includes a lower/upper case in names, but also following the same format.
For example, agree that flows or workflows will be called: Entity – Trigger – Outcome (Case – On status change – Notify owner).
10. Checklist
I absolutely love checklists and they should become your best friend as well during any project. My standard checklist is a go-live checklist I setup it as soon I start any dev work. If there are multiple consultants/developers on your team, best is to setup one for everyone, e.g. OneNote on Teams channel. There multiple reasons for it.
First all of all, you might think that if there are months and months or years before go-live, you have plenty of time to worry about it. However, it’s quite opposite, the longer the project will take, the bigger risk that something will be forgotten or if someone leave the project team, it won’t be passed on handover.
One of the examples can be audit. Let’s say that there is a single requirement that requires to enable audit for certain entities. However, it is quite common not have the audit enabled across all the environments, especially on DEV, to save on storage usage. Someone in your team works on that requirement at the beginning of a project and then leaves few months before the project goes live. Who will remember to enable the audit? Possibly no one. Then the project goes live and 2 months down the line, the customer wants to check audit and there is nothing to check. I wish I made up that story, but it did actually happen on one of my projects and someone else took the blame. Since then, go-live checklist is a must for me. I like learning from my own mistakes, but even better from someone else’s 😊
Audit is just an example, but there are so many other settings in the settings in the environment that are sometimes changed from default to something else and they do not carry during a deployment. Anything like that, needs to be tracked and the cross-referenced during deployments, not even necessarily go-live, but deployments to other environments. That includes making sure that SLAs are not deactivated, all the environment variables are updated or flows are on.
Conclusion
There are definitely many more practices we can think about when starting on a new project, but I would say that it is a good start to incorporate these ingredients into your D365 implementation.
Remember, the devil is in the details, and meticulous preparation can make all the difference. Stay tuned for more insights and tips in upcoming blogs. Cheers to your next D365 project adventure!
Comments