5.1 Record Types Architecture & Synced Data Sources

Record Types, Sources, and Data Access

A record type models a business entity such as a request, supplier, or invoice. It brings together a data model, relationships, security, views, lists, and actions. It is neither a process instance nor simply a screen. For the Associate Developer exam, follow the path from source data to a usable application: choose a source, identify fields and keys, configure access, then build the experience around the entity.

A record type does not make an external system disappear. The source retains its own availability, credentials, constraints, and update rules. Appian provides a common development model over that data. When data sync is enabled, Appian also keeps a synchronized copy for optimized access. Calling that copy a virtual layer does not mean that no data is copied.

Connect an Existing Source

Create a record type in the application, choose the appropriate source, and establish its connection. For a database source, select the data source and table or view. Review the proposed field names, data types, and primary key. A primary key must identify records reliably; selecting a nonunique display name does not make it unique. For a service source, inspect the integration response and map its data and identifiers as directed by the source configuration.

Preview actual source rows before configuring interfaces. Check nullability, date values, duplicate identifiers, and whether the expected columns are present. A connection test proves connectivity; it does not prove that the selected business entity or key is correct. An invoice record accidentally sourced from invoice lines may display repeated invoice numbers because those numbers are not line identifiers.

Create New Data with Codeless Modeling

For a new application, the record-type creation experience can create a data model and database-backed storage without hand-authoring a CDT and data store first. Define meaningful fields and types, configure the identifier, and review the generated model before saving. A Request might have an identifier, title, submitted date, status, and requester. A related Request Item represents a repeating detail rather than a collection of numbered columns on Request.

Then add relationships, configure record-level security, and generate or build the necessary views and create/update actions. Review every generated object, its inputs, and its security. Generation accelerates setup; it does not validate business requirements. Test an actual create action and confirm that the persisted row can be retrieved through the record type. This distinguishes modeling from merely drawing a form.

Synced and Direct Access

Optimized Data Access, using data sync, queries Appian's synchronized data instead of repeatedly reading the source. Direct Data Access reads the source when the application requests data. Modern unsynced record types with features enabled can support relationships, real-time custom fields, and record-level security; do not confuse them with legacy unsynced record types. Feature availability depends on the selected access method and source.

Choose access according to freshness, source size, supported features, and operational needs. A synchronized supplier directory can reduce repeated source requests. An application requiring immediate visibility of outside changes must deliberately plan synchronization or an appropriate direct-access design. Neither method guarantees a particular response time.

Keep Data Current

Appian smart services that support smart service syncs can synchronize changes made through those services. External SQL updates do not automatically notify Appian. Use the source's supported scheduled full or incremental sync configuration, a manual full sync, or a targeted Sync Records operation as appropriate. Review the specific service documentation instead of assuming every integration or stored procedure automatically refreshes all affected records.

A successful database commit and a successful sync are separate outcomes. For example, a write can succeed while synchronization fails. Retrying the whole business transaction without checking the source can create duplicate data. Check both outcomes and repair synchronization separately when the source write already committed.

Limits and Sync Filters

Current sync limits depend on the environment's capability tier and configuration. Older fixed claims such as four million rows and four gigabytes are not a universal current rule. Inspect the applicable documentation and record type's sync settings when planning capacity. Use sync filters to select the business data that belongs in the model, and keep an archival strategy for historical information.

A sync filter controls what enters the synchronized dataset. Record-level security controls who can see rows within the available dataset. A user-facing status filter changes the requested view. These three purposes must remain distinct. Filtering a list by the current user's department is not a substitute for securing the record type and its data.

Diagnose a Failed Sync

Open Sync History and read the status and error. A Failed status can make record data unavailable, including queries that traverse that relationship. With the appropriate skip-failure option enabled, Failed and Skipped can keep previously available data accessible, but stale. Recovery and retry states have their own behavior; there is no unconditional last-good-data fallback.

Check credentials, connectivity, mapped columns, unique identifiers, capacity, and source values. If a column was renamed outside Appian, repair the mapping or source deliberately, then run the appropriate sync and verify a known changed row. Confirm freshness as well as availability. A green interface displaying yesterday's balance is not proof that the repair succeeded.

Takeaway: Build the entity first, select a supported access method, and treat source persistence, synchronization, and user authorization as separate responsibilities.

Sources checked 2026-10-18: Appian data modeling, sync troubleshooting and current capacity guidance, and record-level security.