The situation
An application captures an applicant, their documents, income evidence and a set of checks whose composition depends on the product and the country. The list is not stable: a new jurisdiction adds a document type, a regulator adds a declaration, a product launch adds an income category. Every one of those is today a schema migration, a coordinated API and UI release, and a compliance review of the result.
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 products
- Income sourcesrepeating section
Employment, self-employment, benefits — count varies
- Documentsrepeating section
- Typechoice
Options read from Document types
- Filefile upload
Permitted types and size capped
- Verified ondate
- Declarationssection
Jurisdiction-specific; versioned
- Document typesrecord type
Per jurisdiction; the single list
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.
Start from the forms you already have
Rather than transcribing the existing application by hand, upload a scan or photograph of the paper form and take the proposed schema it produces. Point at the legacy database the same way: pick a table, follow its relationships, preview what would be created. Every proposal is a draft to review, regenerate or discard before anything exists.
What it uses: Schema proposed from a document, or read from an existing database
Model what actually varies
Income sources and documents are repeating sections because their count varies per applicant. Declarations is a section that differs by jurisdiction, so it is versioned with the schema rather than branched in code. The applicant section is defined once and reused across every product.
What it uses: Repeating sections, and reusable sections with per-placement overrides
Point the document list at the system that owns it
Document type is a choice field reading live from the Document types record type, per jurisdiction. A compliance team adding a document type does it in one place, and the form, the validation and the API all see it on the next read. A long list loads as you type rather than being fetched up front.
What it uses: Live option sources, with search-as-you-type over long lists
Publish, and get the surface for free
Publishing produces the REST URL space, the form and the table together, plus a schema and presentation description for that version — which is what keeps the broker portal and the internal screens in step with the model rather than merely close to it.
What it uses: One definition produces the API, the screens and the validation rules
Rehearse the next rule change instead of scheduling a window
When the regulator adds a field, edit the working draft and analyze it against the live version first: which changes are breaking, which need data migrated, which operations are untouched. A breaking change produces a migration plan with a column map to review, and rows that will not convert are set aside individually rather than stopping the run.
What it uses: Impact analysis before publish, and a reviewable migration plan
Keep the old version live while applications move
The superseded version stays active until its data has moved; archiving it is refused while rows still depend on it. The rollback plan is therefore a version that is still there, not a restore from backup — and in-flight applications are unaffected by the change.
What it uses: Versions activated and deactivated without deletion
Require a second pair of eyes on the live change
Changes to the jurisdiction reference data wait for an approver before they take effect, or for a chosen time, or both. Requests move through pending and then published, rejected or canceled, and draft and published states are kept separately so work in progress is never what the API serves.
What it uses: Publishing on approval or on a schedule, with 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.
- 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)
- ways a field can be presented
- 43ways a field can be presentedCounted from egav/backend/app/api/v1/egav/schemas/ui_configuration.py — WidgetType
What changes
A rule change becomes a reviewed configuration change with a version history behind it, and the compliance surface stops growing a bespoke integration each time. What used to be a release train and a maintenance window is a draft, an impact report and a publish.
Written for Teams with data that keeps changing shape.