Views

Views define how users browse and filter data in model‑driven apps. Well‑designed views help users quickly find information, support consistent reporting, and create a more predictable user experience across DfE CRM solutions. This page sets out guidance on creating clear, consistent and maintainable views.

Public and personal views

There are two main types of views - public and personal.

Public views

  • Created and managed by developers
  • Visible to all users when added to an app
  • Used for core business scenarios
  • Suitable for consistent, standardised layouts

Public views should be used for:

  • Main operational lists
  • Dashboards
  • Subgrids on forms
  • App-wide reporting needs

Personal views

  • Created by individual users to meet their own needs
  • Only visible to the creator unless shared
  • Very useful for ad‑hoc filtering or analysis

Sharing personal views

Users can share personal views with individuals or teams. Although they are not solution components, shared personal views can be useful for:

  • Specialist teams
  • Temporary items
  • Investigation or triage tasks

However, personal views should not be used as a substitute for public views when the requirement is long‑term or intended for a broad group. In those cases, convert the logic into a managed public view.

Personal views are owned by the user who created them, so if that user leaves the organisation the view can no longer be updated and administrators cannot access it. If a view is needed for a specific team or long‑term use, developers should create and manage it using a service account rather than an individual user account.

Use security roles to control visibility

Microsoft allows public view visibility to be restricted by security role if the environment has this feature enabled. Only users with the assigned roles see the view in the selector.

Use this when:

  • Different teams require different standard views
  • A view contains sensitive filtering logic
  • You want to reduce clutter in the view selector

This does not override row-level security - users only see records they have permissions for.

Standardise column layouts

Consistency across views improves usability and reduces confusion.

Best practice:

  • Apply the same column order and naming across similar views
  • For example, all Case views should display consistent columns such as:
    • Case title
    • Case type
    • Contact
    • Organisation
    • Status Reason
    • Owner
    • Created On
  • Avoid reordering columns differently across views unless there is a clear, user‑driven reason

Consistent layouts help users quickly recognise the information they need, particularly when switching between views.

Default sorting and filters

Sorting and filtering have a major impact on how quickly users can work.

Best practice:

  • Sort by the most relevant column for the business process (e.g. Created On descending for triage teams)
  • Apply sensible default filters to remove noise (e.g. Open Cases rather than showing all historic cases)
  • Avoid mixing different default sorting patterns across views of the same table

A predictable pattern reduces the load on users and speeds up task completion.

Configure Quick Find

The Quick Find view determines which fields are searched when users type into the global search for that table.

Best practice:

  • Include fields that users genuinely search for, for example:
    • Case reference
    • Contact name
    • Organisation name
    • Email address
  • Avoid including fields that produce excessive or irrelevant matches
  • Limit the number of searchable fields to less than 10 to maintain performance
  • Ensure that searchable fields align with DfE’s standard data models

Poorly configured Quick Find views often lead to confusion or missed records.

Follow consistent naming conventions

Clear naming makes it easier for users to pick the correct list.

Recommended patterns:

  • All Active Cases
  • My Active Cases
  • All Resolved Cases
  • My Resolved Cases

Recommended patterns:

  • Internal abbreviations
  • Programme‑specific shorthand
  • Overly technical names

Keep views clean and uncluttered

Avoid adding unnecessary columns. Only include columns users need for scanning lists or making decisions.

Best practice:

  • Keep views to 6–10 columns for readability
  • Avoid very wide columns unless essential
  • Do not add rarely used fields
  • Use appropriate column widths to avoid excessive scrolling

Align views to the overall business process

Views should reflect the data people need for specific tasks, such as:

  • Triage
  • Complaints management
  • Application review
  • Quality assurance

Design views collaboratively with end users to make sure they match real‑world workflows.

Further reading

Understand model-driven app views (opens in a new tab) is Microsoft’s primary guidance page for developers working with views.