The situation
A funding programme opens a round. The questions differ from last time, the eligibility rules changed, the budget breakdown has a new category, and applications are scored by a panel whose composition is set per round. Applicants need a portal, reviewers need a queue, and the awards have to be published. Today the form is rebuilt each round and the scoring lives in a spreadsheet.
These are illustrative scenarios showing how the products are used, not customer case studies.
Build-versus-buy lens
What this helps you decide
Use the example to find where product configuration ends and custom code begins — and whether the boundary leaves your team with less infrastructure to own.
- Model fit
- Can the record shape evolve without coordinating a migration, API and UI release?
- Workflow fit
- Can approvals, exceptions and deadlines move out of application code without losing control?
- Integration fit
- Can your existing APIs become reusable steps with retries, throttling and visible run history?
- Control fit
- Can your team reconstruct model changes, workflow runs and human decisions later?
What gets modeled
The structure as it would actually be defined — sections that repeat are marked.
- Applicationrecord type
- Applicantsection
Reusable across rounds
- Proposalsection
- Budget linesrepeating section
- Categorychoice
Read live from the round’s categories
- Amountdecimal
- Reviewsrepeating section
- Reviewerchoice
- Scorewhole number
- Conflict declaredtrue/false
- Roundsrecord type
Criteria and categories, versioned per round
How it gets built
In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.
Change the form without rebuilding it
Each round is a version of the schema rather than a new form. The draft is analyzed against the live version before publishing — which changes are breaking, which need data migrated, which operations are untouched — so last round’s applications keep working while this round’s form differs.
What it uses: One working draft per schema, with impact analysis before publish
Keep the previous round alive
The superseded version stays active while its applications are still being assessed, and archiving it is refused while rows depend on it. Two rounds run side by side without one of them being a copy of the code.
What it uses: Versions activated and deactivated without deletion
Let the round own its categories
Budget categories and eligibility lists read live from the round record rather than being typed into the form. Changing a category before the round opens is a data change, and a long list loads as you type instead of being fetched up front.
What it uses: Live option sources with search-as-you-type
Give applicants and reviewers real screens
Publishing produces the applicant form and a reviewer table with server-side paging, typed filters and column selection, and each reviewer keeps their own saved layout. Neither was built.
What it uses: Forms and tables rendered from the schema
Score with the rule the panel actually uses
Assignment covers the shapes a board actually uses. "Three of the five panel members" is a quorum; "the chair plus any two" is a weighted vote where the chair has to be one of the signatures. Both are settings on the decision step, and neither needs its own code path.
What it uses: Approval rules from a named person through to a weighted vote
Handle the conflict and the missing reviewer
A declared conflict routes the application to a different reviewer through a conditional link. Deadline warnings fire while a review is outstanding and escalation moves it on, and a claimed review that is abandoned is released automatically because claims are leased.
What it uses: Conditional links, deadline warnings, escalation and leased claims
Publish the awards on the day, not before
The award list waits for an approver and for the announcement date. A decision still being made sits in the draft, which is held apart from what the API serves. Nothing leaks early because the two are the same row with a flag on it.
What it uses: Publishing on approval and on a schedule, with separate draft and published states
Numbers used above, and where they come from
Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.
- ways to decide who approves
- 7ways to decide who approvesCounted from egav-automation/backend/app/api/v1/automation/schemas/hitl_config_schemas.py — HitlAssignmentPolicy
- field types
- 9field typesCounted from egav/backend/app/api/v1/egav/schemas/entity_type_attribute.py — DataType
- places a choice list can come from
- 5places a choice list can come fromCounted from egav/backend/app/api/v1/egav/schemas/entity_type_attribute.py — OptionSourceType (file is reserved and not counted)
What changes
A new round is a version of the model rather than a rebuild of the form, the scoring rule the panel agreed is the rule the system enforces, and the awards appear when they were meant to rather than when somebody pressed publish.
Written for Teams with data that keeps changing shape.