Dynamics 365 views are the first thing every user sees and the last thing most implementation teams think about. I have lost count of the projects where the forms were lovingly designed and then the main list was a wall of forty columns nobody asked for. If you want people to actually use the system, getting your Dynamics 365 views right matters more than most of the clever stuff you will build.
This is how I set views up on client projects, and the mistakes I try to talk people out of.
Why Dynamics 365 views decide whether people use the system
A view is a saved query plus a set of columns. That is it. But for a salesperson or a service agent it is the working day, because they start in a list and click into a record from there.
If the list shows the wrong records, they go back to their spreadsheet. If it shows the right records but buries the useful bit on the fifth scroll to the right, they go back to their spreadsheet. I covered the wider adoption problem in my Dynamics 365 user adoption guide, and bad views are near the top of the list of causes.
System views versus personal views
System views are built by an admin or customiser, live in a solution and are shared with everyone who has access to the table. Personal views are built by a user and only they can see them. Both have a place, but they are not equal.
My rule is simple. Anything that more than two people would want belongs in a system view, in source control with the rest of your solution. Personal views are for one off questions, and users should be taught how to build them rather than asking you every time.
Do not let personal views become the real system
I once reviewed an environment where one sales manager had thirty personal views and the rest of the team had no idea they existed. When she went on holiday, nobody could find anything. If a personal view is useful, promote it to a system view and tell everyone.
Designing the default view for each table
The default view is the one that opens when somebody clicks the table in the sitemap. Choose it carefully, because most people will never change it.
For most tables I want the default to be something like "My Active Accounts" rather than "All Accounts". It is a smaller list, it loads faster and it answers the question people actually have when they sit down in the morning, which is "what is mine?".
- Keep the default to 6 to 8 columns that fit on a normal laptop screen without scrolling sideways.
- Put the name or primary identifier first, then status, owner and the one or two dates that drive action.
- Sort by something meaningful, such as next follow up date, not just created on.
- Filter out inactive records by default and let people opt in to seeing them.
Filtering and sorting views that answer real questions
The best views are named after the question they answer. "Opportunities closing this month" is clearer than "Opps View 3". If your view names need a training session to explain, they are wrong.
Use relative date filters wherever you can, such as "this month" or "next 7 days". A view with a hard coded date works perfectly on the day you build it and is useless by the end of the week. I see this one constantly.
Watch out for slow views
Views that filter on related table columns, use "contains" on big text fields, or return huge numbers of records will drag. A list that takes eight seconds to load will be avoided, however good the data is. Filter on indexed columns like status and owner first, and keep the number of columns from related tables low. If things are already slow, my piece on Dynamics 365 performance problems goes into the usual suspects.
Quick find and the search columns people forget
Every table has a Quick Find view, and it controls what users can search by and which columns appear in search results. Most projects leave it on the defaults, which means people type a customer's email address into the search box and get nothing back.
Open the Quick Find view for each of your main tables and add the fields people actually search by. Phone number, email, reference number and postcode are the usual ones. It takes ten minutes and users will think you have fixed the whole system.
Security and views
A view only shows records the user is allowed to see. This sounds obvious, but it catches people out when they test as an admin and everything looks fine. Always check your views using a test user with the real security role, because what you see as a system administrator tells you very little. If roles are a mystery in your organisation, my Dynamics 365 security roles guide is a good place to start.
A simple checklist for Dynamics 365 views
Before you hand a project over, run through this for each major table.
- Is the default view personal to the user, such as "My Active" records?
- Do the columns fit on one screen, and do they match what users actually use?
- Are all the date filters relative rather than fixed?
- Has Quick Find been set up with the search fields people use?
- Have you tested with a real user role, not an admin account?
- Are shared views in the solution rather than sitting in someone's personal list?
Forms get the attention because they look impressive in a demo. Views get used hundreds of times a day. Spend an afternoon on them and your users will notice, even if they never say a word about it. If you want a second pair of eyes on a Dynamics 365 setup, have a look at my Dynamics 365 services and get in touch.
