DynamicForm Start free trial
Step 14 of 15 · Architecture and security · topic 2 of 4
Your data lands in normalised relational tablesA Customer screen becomes a CUSTOMER table keyed by FormInstanceID. Its repeating sections become child tables, CUSTOMER_ADDRESS and CUSTOMER_CONTACT, keyed by FormInstanceID and row number. Dropdown values refer to master tables CITY and PRODUCT by code.CUSTOMERFormInstanceIDCustomerNamePANCityCodeProductCodeCUSTOMER_ADDRESSFormInstanceIDRowNoAddressLinePincodeCUSTOMER_CONTACTFormInstanceIDRowNoNameMobileCITYCityCodeCityNameStatePRODUCTProductCodeProductNameScreen“Customer”becomes a table;each repeating sectionbecomes a child tableLists refer to mastertables by code
A Customer screen becomes a table, its repeating sections child tables, and its dropdowns refer to master tables by code.

Your data, properly modelled

Configuration on top. Third normal form underneath.

Building by configuration does not mean storing data in a heap. When a screen is published, the platform creates proper relational tables for it.

  • One table per screen, keyed by the case; one child table per repeating section, keyed by the case and row.
  • Dropdown values stored as codes that refer to master tables, never as repeated text.
  • Transaction data in third normal form on SQL Server, Oracle or MySQL, ready for reporting with plain SQL.
  • A full history of every case kept separately in a document store, so audits never slow down daily work.

Build your first app free

Up to 10 users. 30 days to build, then 30 days live after go-live.

Start free trialTalk to sales

Updated 30 September 2026