APPSIn production
Modules: no-code data apps
Not everything is a flow; sometimes it’s a master list.
A supplier list, a contract inventory or an incident log doesn’t need a diagram: it needs a record, a list and a history. That is built with the same designer, without asking IT for a new table.
What it includes
A data application in an afternoon.
The module defines its form, its list and its card presentation, with a category, a functional owner and a technical owner.
Design
- The same form designer used by processes
- Configurable list: columns, search and cards
- Categories, module owner and technical owner
- Version, history and version comparison
Data
- Create, read, update and delete records
- Audit history per record
- Partial save of the form
- Own tables in the product’s data schema
With processes
- Start a process from a module record
- Start a process from one row of a table in the record
- Input and output mapping between the module and the process variables
- The process returns its result to the record that started it
For the user
- Module hub with search and card or table view
- Status badge per module
- Dropdowns that read these same tables
- Same permissions and same company as the rest of the product
Works with
It doesn’t work alone.
These other parts of the product are what make this one work end to end.
Standards and limits
What you can count on.
A module is a data application, not a flow: if there are approvals and deadlines, those live in a process started from the record.
- Same lifecycle as a process
- Design, publish, versions and change reason behave exactly as they do for a process.
- Queryable tables
- Data lands in the product’s own SQL Server tables, not in a closed format.
Bring the spreadsheet you want to stop using.
We’ll show you one of your own processes modeled and running, with your forms and your deadlines.