How it works
From a definition to running software.
This is a real entity definition and what digita platform generates from it. Nothing in between is written by hand.
{ "naming": "SO-{####:fiscal_year}", "is_submittable": true, // docstatus + workflow "states": [draft → confirmed → delivered], "fields": [ { customer, Link→Customer }, { lines, Table[ product, qty, unit_price, line_total ] }, { grand_total, computed } ], "hooks": { computeTotals, checkCreditLimit }}{ "_id": "SO-2026-0042", // naming series "customer": "ACME GmbH", "lines": [ { Aurora Lamp, ×10, 1490.00 }, { Cable Set, ×5, 95.00 } ], "grand_total": 1886.15, // raw (JSON) "status": "confirmed", "docstatus": 1}The definition on the left is salesOrder.entity.json, the shape that powers the ERP. The API answers on the right; the admin form below it formats the money for your language.
Four steps
Define once. Everything else is generated.
Define
An entity is a JSON file
Its fields, links to other entities, child tables, computed values, naming series, permissions, hooks. You read it; so does the platform.
Generate
The engine reads the definition at boot
It serves the REST API, validates links and permissions, and the admin app renders lists, forms, search and history from the same metadata.
Publish
Mark content public
The website renderer serves it as a fast, multilingual site, with sitemap, hreflang and structured data.
Run
Every app deploys to digita cloud
With a test stage and a production stage; the same build is promoted, never rebuilt.
What a definition carries
- Fields and field types
- Links and child tables
- Computed fields and validation hooks
- Naming series
- Workflow states
- Permissions down to the field
- Storage for files
- Translations of every label