Configurable administrative workflows
Grant and benefit application platform
A platform where citizens find available grants, complete guided applications and submit supporting information, while staff handle the review process.
Grant and benefit calls differ in who can apply, which questions are asked and what evidence is required. The platform supports those variations through configurable application journeys, with a citizen-facing submission experience and a separate administrative review workflow.
01 / The platform
From an available grant to an application
Citizens use the platform to work through the information required by a particular grant or benefit call. A journey can contain eligibility questions, attachments, conditional fields and several steps before the application is ready to submit.
Staff work on the other side of that process, reviewing applications in an administrative assessment workflow. The two experiences share a process but serve different tasks: entering an application and evaluating it.
02 / Configured forms
Describe grant variations through configuration
Each grant can change eligibility questions, attachments, field rules and step order. A dedicated Angular implementation for every call would duplicate controls and couple administrative changes to frontend releases.
I worked on the configuration-driven frontend, using Angular Formly to map backend field definitions to reusable controls and reactive forms to manage values and validation. I kept step orchestration separate from field rendering so the same engine could support different grant journeys.
New field types still require frontend support. The schema needs a clear set of supported controls and rules, so a configuration change cannot silently produce an incomplete or incorrect form.
03 / Conditional answers
Keep answers consistent when a branch changes
Changing an earlier answer can remove later questions or change their requirements. Visual visibility alone cannot establish whether previously entered values still belong in the submission.
I treated conditional questions and cross-field dependencies as workflow behavior, not just visibility rules. My focus was keeping validation and the submitted answers consistent with the process as users changed earlier responses or moved between steps.
Whether a hidden answer should be retained or cleared depends on the process. Backwards navigation, conditional requirements and backend errors all need to be handled against those same rules.
04 / Shared controls
Share form controls across different workflows
A configurable platform can drift into hundreds of special field exceptions. It can also mistake the staff review workflow for the same interaction as a citizen entering an application.
I reused design-system inputs, error presentation and step indicators, with deliberate extensions for domain-specific fields. I kept the citizen’s input journey distinct from the staff review interface because the two roles work with the same application in different ways.
Domain-specific fields need deliberate extensions. Too many exceptions make the schema hard to understand; unrestricted executable rules make validation and accessibility harder to maintain.
Evidence & further reading