Public funding platform: recipient feedback module built end to end on legacy Microsoft Dynamics

Client background and market position

The client is a European public body that administers national grant and public funding programmes. Its platform holds the full record for each programme: applications, supporting documents, eligibility decisions, and payment calculations. Because public money depends on that record, every change carries financial and reputational risk.

The platform runs on a Microsoft Dynamics version and portal layer that Microsoft has since superseded. New work therefore had to add value on the current stack without assuming a rewrite.

Operational and technical bottlenecks

• Payments depend on many automated data feeds. Several upstream data sources feed each payment calculation. A single logic fault produces incorrect disbursements of public funds, which makes payments the highest-risk area of the platform and the hardest to change safely.

• Debugging crosses front end, back end, and database in one trace. The platform contains deeply nested, monolithic legacy assemblies built up over years of policy changes. Each fault required deep trace analysis across all three layers before a fix could be safely introduced.

• Requirements and platform capability did not map cleanly onto each other. Much of Dynamics and its portals is configured instead of coded. The main constraint on new features was reconciling what the business asked for with what the platform could express.

• Notification volume outgrew out-of-the-box tooling. The platform sends more transactional email and portal messaging than standard Dynamics notification handling supports. A custom layer with its own placeholder resolution had to exist before any new notification could be configured.

Everything new was built inside the platform the client already runs, using the layers Dynamics itself provides: JavaScript and templating on the portal pages, C# behind them, and SQL Server underneath. The client took on no new product, no new licence, and nothing extra for its team to learn on a system it may replace later. Requirements were agreed with the client’s internal teams before any code was written.

What was built, and what it solves

• Day-to-day support straight from the live system. Bugs and small changes arrive directly from production, where a fault blocks real applicants. Each one is triaged by severity and either fixed or routed onward, in coordination with the client’s internal teams and other delivery partners.

• A recipient feedback and data-collection module, built from scratch. The client had no structured way to collect feedback from funding recipients. The data model, questions, responses, and reports were built directly in the platform, so collected data sits alongside the client’s other records.

• Rules that decide who receives a data request and when. A request sent to the wrong group produces unusable answers and can expose data to people who should not see it. Configurable logic now controls availability windows and participant eligibility, and checks both before the page loads.

• New application pages that catch errors early. Incomplete applications used to reach caseworkers before anyone could assess them. The pages now check mandatory fields as the applicant fills them in, and the back end repeats the check, so incomplete submissions stop at the source.

• Automated, milestone-based lifecycle notifications. Following up on unfinished submissions by hand does not scale at the platform’s volume. The system now sends notifications automatically at defined points in each submission’s lifecycle.