Making the best design decisions in your Power Platform projects – three simple steps

Microsoft Power Platform is a powerful business application platform, which offers businesses effortless application building and data insights. Power Platform adoption has been increasing rapidly since its launch in 2017. Organisations leverage Power Platform to build robust, scalable, and secure business solutions.

For any business requirement, there are always multiple ways of delivering a solution, which will range in quality. Which of these solutions is the best solution – both now and into the future?

As an example, from a recent project, imagine this. The business requirement was to show information from a parent account to a user looking at a contact. Possible solutions to this requirement include:

• Ask the user to retype the account information into fields in the contact
• Create automation to copy the account information into fields in the contact
• Create a personal view showing all relevant fields and share this view to all relevant users
• Create a system view showing all relevant fields
• Add mapping between the fields in the account and fields in the contact;
• Add a quick view form which displays fields from the account to the contact

All of these six do meet the stated requirement of showing information from a parent account to a user looking at a contact.

How do you, if you are technical developer, decide which is the best solution, or, if you are a project manager, support your technical team to make the best decision from these options? These decisions can rarely be made well by simply showing your client contact what they look like.

If you are a D365 technical person, you have probably already ruled out some of the options.  I’d love to know which options you rule out and why – please tell me by email.

In the project from where I took this example, the technical team had implemented option two! The client was happy with this solution – until I demonstrated the problems encountered when the account fields were updated. In this example, the account fields in question could change frequently, but the automation was only triggered on create of the contact.

The technique that I encourage my technical team is to use the diagram below and to list the pros and cons from multiple perspectives.

I have taken some ideas from Edward de Bono’s ‘Six Thinking Hats’ and I ask the team member(s) to think about each possible solution, and specifically the pros and cons of each possible solution, while wearing these hats:

The hat of themselves, or a member of the technical team today

The hat of the user who will be using solution developed
The hat of someone who is depending on reports that pull data from this functionality
The hat of a technical team member who joins the team after all current team members have left and has to support the functionality

For more complex requirements, I encourage brainstorming with several team members.

Once you have the list of pros and cons from all possible solutions, including how long it will take to develop, test and document and how it will support both an end user, someone using the data, and someone supporting the feature much later on, there is usually one obvious, best solution.

When an approach similar to this is not done, there is often rework when issues arise, for example when a parent record is updated, or a record changes ownership, or new functionality that affects the current solution is requested.

In summary, the three simple steps to ensure you make the best design decisions in your Power Platform projects are: