What are the different types of record types in Appian?

A record type in Appian is a design object that represents and manages business data, such as Customers, Employees, Orders, or Support Tickets. Record types are the foundation of Appian Data Fabric. They let developers connect data from different sources, create relationships, apply security, and access business information inside Appian applications.

By data source, Appian has three traditional record type categories: database-backed (entity-backed), service-backed (web service), and process-backed. It also supports Salesforce-backed records, built-in system record types, and specialized record types.

The examples below follow one telecom customer support scenario.

1. Database-backed (entity-backed)

A database-backed record type connects to a relational database table or view.

A customer named John calls support because his internet isn’t working, and the agent asks for his registered phone number. His information already sits in a database table called CUSTOMER:

As the developer, you create a Customer record type and connect it to that table. When the agent enters John’s phone number, Appian queries the record type and shows his name, customer ID, phone number, and internet plan. The agent never touches the database directly.

1. It connects to database tables or views.
2. It supports Data Sync through Optimized Data Access.
3. It supports record relationships and record-level security in supported configurations.
4. Eligible database table-backed records can be created, updated, and deleted with record smart services.
5. Database views can’t be written to with Write Records or Delete Records.

This type fits customer management, employee records, orders, complaints, and other database-driven applications.

2. Service-backed (web service)

A service-backed record type retrieves data from an external system through a web service or API.

John says he paid his bill yesterday and his internet is still down, so the agent needs to verify the payment. The billing data isn’t in Appian’s database. It lives in a separate billing application that exposes a REST API returning:

You build four things:

1. A connected system that configures the connection to the billing application.
2. An integration object that calls the billing API.
3. An expression rule that returns the API data in the required structure.
4. A billing record type that uses the expression rule as its data source.

Now the agent can open John’s account and see that his $80 payment went through, without logging in to the billing application.

1. It connects to external applications through APIs.
2. It can use Optimized Data Access to sync the external data.
3. It can use Direct Data Access as a legacy configuration.
4. Synced web service record types retrieve up to 1,000 rows by default.
5. Larger datasets can sync using sequential, cursor or token, or URL-based batching.

This type fits external payment systems, billing applications, SAP, third-party CRM systems, and REST APIs.

3. Process-backed

A process-backed record type uses an Appian process model as its data source. Instead of reading from a database or API, it exposes information tied to process instances.

After checking the payment, the agent raises a network complaint, which starts a process model called Internet Complaint Resolution. The agent creates the complaint, a network engineer gets an investigation task, the engineer looks into the connection, the issue is resolved, and John gets a notification. The process has these instances:

With a legacy process-backed record type, authorized users can see the process ID, start time, process initiator, and configured process data for those instances.

1. It uses an Appian process model as the data source.
2. It gives access to process instance information.
3. It doesn’t support Data Sync.
4. It’s considered a legacy record type in modern Appian versions.
5. Process instance data may be unavailable after archival or deletion.

For new applications, it’s generally better to keep permanent complaint information in a database-backed record type and use process models to run the workflow. Process-backed records are mainly for maintaining existing legacy applications.

4. Salesforce-backed

A Salesforce-backed record type connects to data stored in Salesforce through a Salesforce connected system. Appian offers Salesforce as a dedicated data source shortcut.

While helping John, the agent notices his plan is expiring soon. The sales team tracks subscriptions and renewals in Salesforce. Instead of opening Salesforce, the agent can use a Salesforce-backed record type to see this inside Appian:

1. Customer: John
2. Current subscription: Unlimited Internet
3. Renewal date: November 15
4. Renewal opportunity: Open

That assumes those details exist in the connected Salesforce objects.

1. It connects to supported Salesforce objects.
2. It uses a Salesforce connected system.
3. It supports Optimized Data Access.
4. Direct Data Access creates a legacy configuration.

This type fits Salesforce CRM integration, sales leads, customer accounts, and renewal opportunities.

5. New data model

The New Data Model option lets developers create a database-backed record type from scratch. It doesn’t connect to an existing table, because Appian can generate the table itself.

Say the telecom company is launching a Support Ticket application and has no table for tickets. Instead of writing SQL by hand, the developer picks New Data Model and defines these fields:

Appian generates the table and creates a synced record type. When John calls, the agent creates a ticket through an Appian form, and the details are saved through the application’s configured record actions or smart services.

1. It creates a new database-backed record type.
2. Appian generates the table and its fields.
3. It needs a supported database and permission to create the table automatically.
4. The generated record type uses Data Sync.

This type fits new applications where the required tables don’t exist yet.

Built-in and specialized record types

The built-in User record type gives access to user profile information. If John’s complaint is assigned to an engineer with the Appian username engineer.a, the application can show the engineer’s name and email next to the complaint.

The built-in Document record type provides metadata about Appian documents managed through record types. If John uploads a screenshot of his connection error, an application using record-based document management can show the file name, size, and upload date through the related Document record type. It’s accessed through related record types and can’t be queried directly.

A records-backed record type transforms existing synced record data for process insights in Process HQ. The telecom company has separate event histories for internet complaints and billing complaints, and a records-backed record type can combine them into a common structure so analysts can see where resolution gets delayed. It’s for process insights data preparation, not ordinary application interfaces.

Quick comparison