The Power of Prototyping during your Dynamics 365 Implementation

We are in the middle of a Dynamics 365 project implementation. I am struggling to get a shared understanding of requirements for a Time Entry functionality that my client has asked us to build. What was supposed to be a simple Time Entry entity with description, date and owner is now evolving to be way more complex with many other rules. Ex: Time Entry categories need to drive if fields are displayed, mandatory or read-only on the form. Other categories must have related subcategories, etc.

Until now we used a combination of whiteboarding and Dynamics 365 Forms prototyping to validate requirements. But in this case I needed to come up with something new.
It was important we landed on a solution soon and not be late on tight project deadlines.

This is where I switched to to prototype Forms and logic. I then shared thos prototypes with my client stakeholders during a workshop. The session was a total success and participants thanked me for the preparation work. They finaly felt like we have come to a shared understanding of the User Interface requirement.

Why prototyping

Prototyping during your Dynamics 365 or Power Platform engagement is extremely valuable as it will give you the ability to test your thinking and design ideas with real users.

Prototypes can help you to:
  • Gain insights from real users on how they will use a functionality.
  • Limit design assumptions. If you can’t decide where to put a certain section or sub-grid, test a few versions of the form and see which works best.
  • Identify design flaws before it’s too late. Prototypes enable you to fail early and cheaply; they’ll expose a weak or unsuitable approach before you’ve invested too much time or money.
No matter how much time you spend analysing and write specs, many people find it difficult to truly conceptualize something until they have seen it. Prototypes allow you to iterate, refine, rework and make improvements until you have it ready to implement.

When to Prototype in Dynamics 365 or the Power Platform

  • Prototype to validate Requirements and Solutions: Those will help you make sure stakeholders have a shared understanding of requirements before the start of the project. It will spark ideas and force stakeholders to agree on a shared vision that meet requirements. Ultimately leading to a better solution.
  • Prototype to validate Requirement details and Designs: You may need to use prototypes again during your “Analysis & Design” to validate detailed requirements. Prototypes are great to help you nail acceptance criteria for your User Stories. 

Tools to prototype:

The model-driven form and view designers

The new model-driven FORM DESIGNER provides an improved WYSIWYG authoring experience for designing Form in the Unified Interface. 

“The designer shows a real-time WYSIWYG preview (Unified Interface only) while you author a form. Changes to the form are instantly reflected in the preview, enabling you to see exactly how the form will appear to users when published”.

I sometimes open the designer and start prototyping forms by moving and changing fields, sections and tabs around during workshops. This helps with the following:
  • It empowers stakeholders to feel like they can design forms with you. 
  • They see how easy it is to rename, move or add new fields, sections or tabs. Which brings confidence that future changes are possible and easy to make.
In most scenarios, we will start modelling something quickly during workshops and then users are assigned to get back to me with their input on how the Forms should look like.

For more complex scenarios, I use “” to model screens including complex form logic that require the usage of “Business Rules” or “JavaScript”. I also display sample data on my prototypes to make it look more real and easier for workshop participants to understand.

Below some sample of the same Form rendered with different form rules using “”.
  • Yellow are the new fields 
  • Red are changes to mandatory fields
  • Blue are changes to read-only fields

The creating a time entry from the main navigation and without related records:

  • [Type] field set to “Non Client Related”
  • Show [Non Client Related Category] field
  • Show [Organization field]

Creating a time entry starting from a contact record:

  • [Type] field set to “Client Related”
  • Show [Client Related Category] field
  • Set [Client Related Category] field to “Service Contact”
  • Show [Support Category] field

Creating a time entry from a Case:

  • [Type] field set to “Client Related”
  • [Client Related Category] field set to “Enquiry”

Creating a time entry from an Apppoinment:

  • [Type] field set to “Client Related”
  • [Client Related Category] field set to “Group Attendance”
So in this exemple we created the same Form with 4 differently Form logic. Workhoping those prototypes made it easier for stakeholder to agree on the final rules.


As a bonus, I have included the “” shapes that I use when prototyping Forms and Business Process Flows. To use those shapes, download them from the following locations.

How to add the shapes to your “”:

  1. Open
  2. Click on File --> Open Library from Device… --> Select the XML files and import them.
  3. Et voila… you should be able to see the 2 library available for you to use:

Happy Prototyping 😊