.jpg)
"Sometimes it is the people who no one imagines anything of who do the things that no one can imagine." Just like the Imitation Game movie exclaimed, sometimes it is the unsung heroes who create some stunning solutions with Model-Driven Apps. Let’s take as an example Business Analysts or Developers. They stand between the business vision and the technical excellence required to deliver a brilliant CRM application. Ready to forge the foundations to meet real user needs.
“Can machines think?” Alan Turning proposed in his 1950 paper "Computing Machinery and Intelligence". In our case, we can easily reference that to how can we build good CRM systems that do most of the thinking for our users, with the might of the Power Platform.
Being in the field of CRM operations for almost a decade, I have seen the good, the bad, and the ugly. A few lessons were learned along the way. The most important being, you must get the basics right with a solid data model and a friendly user interface. In this blog post, we'll embark on a code-breaking journey to unravel the bad practices in the context of Model-Driven Apps like Dynamics 365. Each example will be accompanied by insights, sprinkled with quotes from the Imitation Game, to illuminate the path toward better column management.
1) The Enigma of Ambiguous Naming
"Do you know how hard it is to communicate with a computer? Particularly when you speak to it as if it were a human."
Scenario: Using vague names like "ACC Name" or “MD” in records.
Why It's Bad: Ambiguous names or abbreviations lead to user confusion about the column's purpose. No purpose, no party. What is “ACC Name” or “MD” after all?
Tip: Display names and labels play a big role in streamlining UX, training and adoption. Otherwise, you risk incomplete and bad quality entries.
What to do instead: Use clear names in Display Name and Label. For example, “Account Name” instead of "ACC Name".
2) The Codebreaker's (and Copilot’s) Nightmare:
"The real problem is not whether machines think but whether men do."
Scenario: You want to capture an email address. But you have set up the Data type as Single line of text and the Format as Text.
Why It's Bad: There is no validation to check whether your users are inputting “info@adatum.com” or “info email”. Another risk of bad data, leading to a slowly deteriorating database and shaky foundations for using advanced tools like Copilot later.
Tip: There are multiple formats which need validations even when you are using Single Line of Text. For example, these can be seen in Data type as options for Email, Phone number or URL.
What to do instead: Use in Format the Email option so users are reminded to adhere to email formats, and you can reinforce data accuracy and reliability.
3) The Imitation Game Illusion:
"To pull the wool over someone's eyes. It means to deceive them."
Scenario: An arbitrary decision was made to change the Label of a Table column. To make matters worse, this Model-Driven App is connected to a Power Pages site where the same field is labelled as something different too.
Why It's Bad: To the naked eye, a retrospective analysis or update of this configuration is challenging. Even with tools like the Metadata Document Generator in XRMToolBox, you cannot easily find these label discrepancies. Instead, you would have to check manually in each form to confirm.
Tip: Streamlining metadata minimizes tech debt and maintenance effort.
What to do instead: Align the two names so long as it is brief and makes sense for users. Use the tooltip feature by adding a Description to guide the users when they hover over.
4) The Double Agent Dilemma
"The machine is a friend of ours, and I believe it will help us win the war."
Scenario: Your stakeholder asked for a “Yes/no” column to capture decisions. You built that Data type, forgetting you also needed a blank default value.
Why It's Bad: Two simple challenges can quickly turn this configuration into a nightmare. The “Yes/no” field only allows two choices. If the stakeholder wants a “Maybe” choice later, it will be a no-go. Instead, a new column must be created with data migration for existing records. What’s worse, you failed one of the requirements; the “Yes/no” Data type does not allow for a blank default value. Ouch.
Tip: Stakeholders change their mind all the time about requirements. Make your life easier by assuming it will happen!
What to do instead: Build a column with Choice as the Data type. In your Choices, add “Yes” and “No”. Choose “None” as a “Default choice” so the column is blank before input.
5) The Puzzling Flyout
"Are you paying attention? Good. If you're not listening carefully, you will miss things."
Scenario: Your stakeholder asked for 20 columns in the first stage of a sale opportunity’s stage flyout. Wow. That should go down a breeze with users.
Why It's Bad: From both a UI and UX perspective this will look terrible. Too much data to capture from the get-go will switch users off if mandatory. Or, if optional, they will skip to the Next Stage, and so forth.
Tip: Once business requirements are done, take a step back to rethink the design of each stage's flyout. Not every column, mandatory or optional, actually needs to be there.
What to do instead: Leverage business rules. Instead of adding all the deal financials in the flyout, create a locked “Yes/no” column called “Financials added?”. It will by default be a "No". The business rule will tie it to all other financials' columns in the main form which must be completed. Once that is done, the business rule will set the “Financials added?” column to “Yes” and the user can proceed to the Next Stage. Adding a recommendation can explain to users what that is instead of wondering why the flow is stuck. Training initiatives should reinforce the same.
Building solutions is never an ordinary task
Final tips and tricks to help you build stronger, cleaner data as the lifeblood of every organization.
Before capturing requirements, use design thinking (e.g. with tools like Mural) to define the vision, pain points and opportunities.
For business process flows, leave the main form design for last so you know how data and rules should flow.
Use SMEs in early testing to validate the data entry process, better catch issues earlier with strong change management.