Data Modeling and Records
From table to user-facing record
A record type sits on top of a data source - typically a database table via a data store, or a web service, or a process-backed source. The record type defines a primary key, a set of fields mapped to source columns, and one or more record views (list, summary, grid, related). Relationships between record types are defined as one-to-many or many-to-one and are what power related-record displays and record-type fields on forms.
Data stores and the CDTs
A data store groups tables and their CDTs (custom data types) and provides the CRUD operations the platform uses. The CDT is the Appian-side representation; the table is the database-side truth. Field names, types, and primary keys must line up, or writes fail at runtime.
Traps to watch for
- Assuming a record field is writable because it appears on a form. Writes require a data store entity configured for write, and the field must be mapped.
- Confusing a record type with a record. The type is the definition; individual rows are records.
- Forgetting that relationships are directional in definition but can be traversed both ways in queries.
- Treating a process variable as persistent data. It is not; persistence requires a write to a data store or process-backed record.
Rule of thumb
If the question is about displaying data, think record views and fields. If it is about changing data, think data store entity, write operation, and CDT mapping. If it is about linking data, think relationship and foreign key.
Worked example
A user reports that saving a form does nothing. The record type reads from a view but has no writable data store entity, so the write silently has nowhere to go. The fix is to add a write-capable entity and map the fields.