A federal financial regulator needed to improve internal processes with new IM/IT solutions — including business intelligence and case management portals for pension and approvals workflows. The existing workflow solution was built in-house to support legacy applications, and it had reached the point where maintaining it cost more than replacing it.
The work had to meet demanding constraints: security and compliance requirements for a regulator, accessibility standards for public-facing and internal portals, and business processes that could not pause while the new solutions were built.
The in-house workflow solution had served its purpose, and that was precisely the problem. It had been built to support legacy applications, which meant it was shaped around systems and assumptions that had since moved on. Over the years it had accumulated the usual debts of a bespoke system: knowledge concentrated in a small number of people, changes that were expensive and slow, and a maintenance burden that grew with every year it stayed in place. The point at which maintaining a system costs more than replacing it is rarely announced. It arrives quietly, as the share of effort spent keeping the system running crowds out the effort spent improving it.
For a regulator, that burden carries a particular weight. Pension and approvals work is case-driven, deadline-bound, and consequential: the people and institutions on the other side of those processes are entitled to timely, accurate, auditable handling. A workflow system that is hard to change is not just an IT inconvenience in this context. It is a constraint on the regulator's ability to do its job — to adapt processes when requirements change, to produce reliable reporting on caseloads and decisions, and to demonstrate that every case was handled according to the rules.
The constraints on this engagement were not background conditions. They were the design requirements. A financial regulator operates under security and compliance expectations that leave no room for shortcuts: data security, access controls, and authentication had to be designed in from the start, because a portal that handles regulatory casework cannot be secured after the fact. Accessibility was equally non-negotiable. Public-facing and internal portals had to meet WCAG 2.0 AA standards, which meant accessibility was a build requirement — tested, not asserted — rather than a polish applied at the end.
And the business could not pause. Pension and approvals processes had to keep running while the new solutions were built, which ruled out any approach that required a clean break from the old system. The transition had to be managed: new portals and workflows delivered alongside the legacy system, with a sequenced rollout that let the organization move work across without interrupting it. That constraint shaped the delivery approach as much as any technical requirement.
The stakeholders spanned the regulator's work: pension teams and approvals teams who owned the casework, IT teams who would run the new solutions, security and compliance teams who had to approve them, and the users — internal and external — whose experience would judge them. The engagement had to deliver portals, business intelligence, and a workflow replacement that served all of them, inside the regulator's obligations, while the work continued.
The engagement combined solution architecture, business intelligence, and portal delivery. Requirements were gathered from business users and transformed into logical and physical database designs. The solution architecture was developed around security, compliance, and accessibility — with data security, access controls, and authentication designed in from the start, and portals built to meet WCAG 2.0 AA standards.
Case management portals were built for pension and approvals workflows, with Power Apps supporting the work and Power BI configured to meet business reporting requirements. Azure Logic Apps workflows replaced the in-house workflow solution supporting legacy applications. Azure Functions, Logic Apps, and Power Platform tooling were combined with SharePoint provisioning automation, custom SPFx web parts, and ETL pipelines to move and verify data.
Delivery followed Agile and DevOps practices: sprint planning, continuous delivery, automated testing, continuous monitoring, and performance testing for scalability. Testing strategies covered functional, performance, and accessibility requirements. A data dictionary documented content, structure, and application sub-systems, and an implementation plan sequenced the rollout.
The sequencing was deliberate: requirements and data design first, architecture second, build third. Requirements were gathered from the business users who actually ran the pension and approvals processes — not from documentation of how the processes were supposed to work, but from how they worked in practice, including the exceptions and workarounds that any real process accumulates. Those requirements were transformed into logical and physical database designs, because case management stands or falls on its data model: if the case, the parties, the decisions, and the audit trail are not modelled correctly, every portal and report built on top of them inherits the flaw.
The solution architecture was developed around the constraints, not in spite of them. Data security, access controls, and authentication were designed in from the start. Accessibility to WCAG 2.0 AA was a build requirement, with testing strategies covering functional, performance, and accessibility requirements rather than treating accessibility as a final check. A data dictionary documented content, structure, and application sub-systems, so the solution would be understandable to the people who would maintain it — because a regulator cannot depend on a system only its builders understand.
The build combined several platforms, each chosen for what it did best. Case management portals for pension and approvals workflows were built with Power Apps supporting the work, giving business users purpose-built interfaces over the case data. Power BI was configured to meet business reporting requirements, so decision-makers could see caseloads, status, and outcomes from governed data rather than from hand-assembled reports.
The workflow replacement was a central trade-off. Azure Logic Apps workflows replaced the in-house workflow solution — a deliberate move from bespoke code to a supported, maintainable integration platform. Logic Apps offered the enterprise integration, monitoring, and DevOps fit the regulator needed, where a pure low-code flow tool would have been the wrong weight for the complexity. Azure Functions handled the custom compute. SharePoint provisioning automation, custom SPFx web parts, and ETL pipelines moved and verified data, with the ETL work treated as a first-class concern: data that moves without verification is a liability in a regulated environment.
Delivery followed Agile and DevOps practices throughout: sprint planning, continuous delivery, automated testing, continuous monitoring, and performance testing for scalability. That discipline mattered more than usual here, because the business could not pause — new solutions had to land alongside the legacy system, be proven, and then take over, without a gap. The implementation plan sequenced the rollout so each piece could be validated before the next one depended on it.
The regulator received working case management portals and business intelligence built to its security, compliance, and accessibility requirements — delivered with the DevOps and Agile discipline the environment demanded. Legacy in-house workflows were replaced with supported, maintainable Logic Apps automation. Power BI reporting gave decision-makers data they could act on.
[Quantified process-improvement and delivery metrics to be confirmed by Harjot before publication.]
The most important operational change was the replacement of a system the organization maintained with systems it could run. Case management portals gave pension and approvals teams purpose-built interfaces over their casework, with the processes, data, and audit trail in one place rather than spread across a legacy workflow tool, email, and spreadsheets. The Logic Apps workflows replaced bespoke code with supported automation that could be monitored, maintained, and changed without depending on the small number of people who understood the old system.
Business intelligence changed the reporting picture. Power BI reporting over governed data meant decision-makers could see caseloads, status, and outcomes from a source they could trust, instead of relying on hand-assembled figures whose lineage nobody could explain. The data dictionary, the documented sub-systems, and the ETL verification meant the numbers had a provenance — which, for a regulator, is not a nicety but a requirement.
Accessibility, treated as a build requirement, meant the portals met WCAG 2.0 AA standards as delivered — not as a retrofit, and not as an aspiration. Security, compliance, and authentication designed in from the start meant the solutions could stand up to the scrutiny a regulator's own systems must withstand.
The regulator can now run pension and approvals casework through portals built for the purpose, with workflows that are maintainable and visible. It can change its processes without commissioning bespoke development, because the automation lives on a supported platform with monitoring and DevOps practices around it. It can report on its caseloads from governed data, with an audit trail behind the numbers. And it can do all of this on systems its own teams can maintain, extend, and explain — which is the real test of a delivery in a regulated environment.
The transition itself demonstrated something important: a regulator's core processes can be modernized without pausing them. The sequenced rollout, the validation of each piece before the next depended on it, and the Agile delivery discipline meant the organization moved from legacy to modern without a gap in service.
What carries forward is a maintainable estate and a delivery discipline. The Logic Apps automation, the Power Apps portals, the Power BI reporting, and the documented data model form a platform the regulator can extend as its needs change. The DevOps practices — continuous delivery, automated testing, continuous monitoring, performance testing — remain as the way the organization ships and runs software. And the accessibility and security approach established on this engagement remains as the standard for the next one, because a regulator that has built to WCAG 2.0 AA and designed security in from the start does not go back to bolting either on afterward.
[Additional quantified outcomes — case-processing improvements, workflow replacement scope, reporting adoption — to be confirmed by Harjot before publication.]
This case study is based on Harjot Singh's key-personnel project work. It is marked DRAFT pending Harjot's verification of facts, metrics, and framing before any publication.