Ask most stakeholders what makes a good case-management system and they will describe the interface: clean screens, easy navigation, a dashboard that looks impressive in a demo. Ask anyone who has actually delivered one of these systems and the answer changes completely. The interface is the last thing that matters. What determines whether the system works is the information architecture underneath it, agreed and stress-tested long before a single screen is designed.

This is not a controversial claim inside delivery teams. It is, however, consistently underweighted by the organisations commissioning these systems, which is precisely why so many case-management programmes struggle after go-live rather than during build.

What information architecture actually means here

In a case-management context, information architecture is the answer to a specific set of questions, none of which involve what a screen looks like:

• What is a "case", precisely, and what other record types relate to it? Companies, contacts, issues, findings, outcomes, documents?

• What are the valid statuses a case can move through, and who can move it between them?

• What permissions does each role have, at what stage, over which records?

• What counts as a complete, auditable record of a decision, and what evidence has to exist to support it?

• What reference data and lookup values are shared across the organisation, and who owns changes to them?

Get these decisions wrong, or leave them ambiguous, and no amount of good interface design will fix the resulting system. Get them right, and the interface becomes a comparatively straightforward exercise.

Why this gets skipped

Information architecture work is slow, unglamorous and produces no visible output that a stakeholder can point to in a demo. Screen design produces something to look at within days. This asymmetry is exactly why so many low-code and Power Platform projects rush toward building screens before the underlying data model, roles and status logic have been properly agreed, and why so many of those same projects then spend the back half of the programme quietly reworking the data model to fix problems that were visible from the start.

Low-code platforms make this risk worse, not better, precisely because they make it so easy to start building. The speed of tools like Power Apps and Dataverse is a genuine advantage, but it removes the natural friction that used to force teams to think through the data model before committing to code. Without deliberate discipline, that friction needs to be reintroduced by the delivery team, not assumed away by the platform.

The pattern in systems that work

Case-management systems that hold up over years, rather than needing a rebuild within eighteen months, tend to share a few practical habits.

Roles, permissions and statuses are agreed before configuration starts, ideally validated against real end-to-end journeys rather than described in the abstract. A "simple case" journey, a "multi-stage review" journey and an "occasional read-only access" journey each expose different assumptions about the data model, and testing all three early catches problems while they are still cheap to fix.

Related records are modelled as relationships, not duplicated fields. Cases, companies, contacts, issues and documents should be connected records that can be queried and reported on together, not the same information copied into multiple places, which is how data quality problems compound over time.

Status is treated as a first-class concept, not an afterthought. What does "under review" actually mean, who can set it, and what has to be true before a case can move to the next status? These rules, once agreed, do most of the heavy lifting that a workflow engine gets credit for.

Reference data has a clear owner. Lookup lists, categories and configuration values drift over time if nobody owns them. A case-management system with no clear owner for its reference data will, within a couple of years, accumulate inconsistent categorisations that quietly undermine every report built on top of it.

What this means in practice for a delivery programme

The practical implication is straightforward, even if it runs against the instinct to show visible progress quickly. Validate the operating model, roles, permissions and data relationships in an early prototype, using genuinely representative scenarios rather than a generic demo dataset. Treat this validation as a gate, not a formality, before extensive configuration begins. It costs time upfront that can feel frustrating when a client wants to see a working screen. It saves considerably more time later, when the alternative is rebuilding a data model that thousands of records now depend on.

The organisations that get the most value out of a case-management investment are rarely the ones with the most polished interface at launch. They are the ones whose information architecture was right before the interface was ever built, because that is the layer that determines whether the system still works, cleanly and reportably, three years after go-live. Contact Us.