View this page in the latest version of Appian. Data Access for Record Types Share Share via LinkedIn Reddit Email Copy Link Print On This Page When you create a record type, you'll choose a data access method to determine how the record type accesses your enterprise data: Optimized Data Access Direct Data Access (with features enabled or disabled) The data access method you choose determines the objects needed to connect to the data and what features are available. Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close Compare data access methods Choosing a data access method creates one of three record types: synced, unsynced, or legacy. Use Optimized Data Access (synced) to take advantage of Appian's automatic performance tuning and full access to data fabric features. Use Direct Data Access only when you need immediate access to data changed outside of Appian and syncing isn't an option. Review the comparison table to learn about the different data access methods and their resulting configurations. Data Access Method Resulting Record Type Supported Data Sources Performance Available Features Optimized Data Access Synced record type Databases and web services Automatically optimized by Appian All features Direct Data Access (Features enabled) Unsynced record type MariaDB, MySQL, PostgreSQL, and Snowflake databases Relies on source performance Most features Direct Data Access (Features disabled) Legacy record type Databases, web services, and process models Relies on source performance Basic filtering and security only Optimized data access Optimized Data Access is the recommended configuration for most modern Appian applications. Optimized data access syncs data to Appian's data service, which automatically optimizes performance for complex, high-volume transactional and analytical queries—no manual database administration or tuning required. How optimized data access works Think of syncing your data like caching on your web browser. When you cache web content locally, your site content loads faster. The same applies when you sync your data. Appian only has to execute queries against your synced data instead of the external source, so your record data will load faster. To keep synced data current: Use smart services to write and sync data in real time. Schedule syncs to capture changes from other systems regularly. Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close Why use optimized data access? Optimized Data Access provides the following advantages: Performance: Appian executes queries against the synced data rather than the external source, ensuring consistent speed even for complex queries and interfaces. Full feature availability: The record type can leverage all of Appian's powerful data fabric features, including relationships, smart search, and process analysis in Process HQ. Scalability: You can enable dynamic scaling to ensure your data fabric automatically scales in response to changing query activity and usage patterns. Row considerations for optimized data access The number of rows you can sync per record type depends on your capability tier. Premium tier: There is no set row limit. Advanced tier: You can sync up to 20 million rows per record type. Standard tier: You can sync up to 4 million rows per record type. Note: Query performance depends on your record type data volume, query complexity, and available resources. You must conduct performance testing to ensure your site supports your specific data volume and requirements. If you expect your data volume to exceed your tier's limit, you have two options: configure sync filters to sync only the data you need, or use the Direct Data Access method instead, which has no row limit. For synced record types with no row limit, you should still configure sync filters to remove unnecessary data. Syncing unnecessary data increases resource consumption and can impact query performance. If your capability tier supports syncing more than 4 million rows, your system must also meet specific hardware requirements. Field requirements for optimized data access A record type with Optimized Data Access must meet these field requirements: Primary keys: At least one primary key field is required. For database tables, you can have multiple fields that together create a composite primary key. Field limit: Each record type can have up to 100 fields, including custom record fields. Supported field types: Database columns must use a supported data type. Review the list of unsupported database column types. Character limits: Unique fields have a maximum of 765 characters. Text fields longer than 4,000 characters are truncated. Long text fields: To store up to 64,000 characters, use the Extra Long Text field type. If your field exceeds 64,000 characters, use an unsynced record type instead. API requirements to sync Salesforce data Syncing 1,000 rows uses one API call. Ensure your Salesforce API limit is high enough for your data volume, especially when multiple record types use the same object. If the API limit is not high enough, the sync will fail and the record data will be unavailable. To reduce the number of rows synced, use sync filters. Additional encryption options for synced data Appian Cloud offers transparent data encryption for synced data. This provides an additional layer of protection on top of the automatic disk encryption that secures all data at rest within Appian Cloud environments. Note: Transparent data encryption for synced data is included in Appian's premium capability tier. Direct data access Direct Data Access queries the source directly whenever the data is viewed in Appian, and relies on the source's native performance. When you select Direct Data Access, you can choose whether to enable or disable relationships and related features on the record type. By default, these features are enabled. Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close When to use direct data access Use Direct Data Access (with features enabled or disabled) when you need immediate access to data changed outside of Appian and syncing isn't an option. Once you determine that Direct Data Access is the best choice, choose whether to enable or disable relationships and related features based on your source: Enable relationships and related features: When your data lives in a MariaDB, MySQL, PostgreSQL, or Snowflake database. Disable relationships and related features: When your data lives in a web service, process model, or database other than MariaDB, MySQL, PostgreSQL, or Snowflake. Direct data access with features enabled When your record type uses Direct Data Access to connect directly to a MariaDB, MySQL, PostgreSQL, or Snowflake database, the record type can access features like relationships, record-level security, and real-time custom fields. However, the record type cannot use the following features: Smart search. Process analysis in Process HQ. Sync-time custom record fields. Sync filters or default filters. How direct data access works (features enabled) When you use Direct Data Access and keep relationships and related features enabled, the record type can connect directly to the database without relying on a data store entity (DSE) or custom data type (CDT). When data is queried from the source, Appian automatically applies any joins, transformations, and security rules before displaying the data in your applications. In many cases, these operations will be applied within the query to the source database. Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close Source requirements for direct data access (features enabled) To use Direct Data Access with relationships and related features, the source must be one of the following databases: MariaDB MySQL PostgreSQL Snowflake You can connect to an external database using VPN or PrivateLink. To use VPN, contact Appian Support to enable VPN support in the data service. Field requirements for direct data access (features enabled) A record type with Direct Data Access and relationships and related features enabled must meet these field requirements: Primary key: A single primary key field is required. The table cannot have a composite primary key. Field limit: Each record type can have up to 100 fields, including custom record fields. Supported field types: Database columns must use a supported data type. Review the list of unsupported database column types. Character limits: Unique fields have a maximum of 765 characters. Text fields: Text fields and Extra Long Text fields do not have a character limit. Use Extra Long Text fields to more effectively store and display large volumes of unstructured data. Performance considerations for direct data access (features enabled) When you query across different sources—like querying a synced record type with an unsynced record type, or querying two unsynced record types from different databases—Appian performs a federated query. In a federated query, Appian retrieves data from each source independently, pushing down operations like relationships, filters, paging information, and aggregations to the source system when possible to reduce the overhead of data retrieval. In some cases, Appian is unable to push operations down to the source system, resulting in unbounded source queries. An unbounded query occurs when the initial fetch to a source returns all data before it can apply relationships, filters, or security. If the source of an unsynced record type is large, an unbounded query can result in high latency or even query timeouts. You can use the Query Performance Monitor to determine if a query is unbounded and whether it's impacting your application's performance. Ensure you follow the record type query best practices to optimize your queries. Direct data access with features disabled When your record type uses Direct Data Access to connect to a web service, process model, or a database other than MariaDB, MySQL, PostgreSQL, or Snowflake, it cannot use features like relationships, record-level security, and real-time custom fields. You must disable these features before connecting to these data sources. How direct data access works (features disabled) When you use Direct Data Access and disable relationships and related features, you'll need to create additional objects to connect to and structure your data. The objects you must create depend on whether your data source is a web service or a database other than MariaDB, MySQL, PostgreSQL, or Snowflake. For example, to allow your record type to have direct access to data from an Oracle database, you'd need to create a data store entity (DSE) and custom data type (CDT). Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close Unsupported database column types Appian does not support binary large object (BLOB), spatial, or XML types, or any user-defined types in any record type. For binary types, you may still be able to manually map a field in your record type to that column, but it is not guaranteed to work correctly and may fail completely with a future version of Appian. Additionally, when you use Optimized Data Access or Direct Data Access with features enabled, certain database column types are not compatible with the record type. The following table provides a reference of unsupported database column types. This list may not be comprehensive. Vendor-specific and user-defined types are not supported and may cause record types to not sync or produce other issues. Note: If your table includes LONG or BIGINT columns, the safe range of values is from -2,147,483,647 to 2,147,483,647. Numbers outside that range may not be synced correctly. See the Number (Integer) data type for more information about number values in Appian. Database Vendor Unsupported types IBM DB2 BINARY BLOB DBCLOB GRAPHIC MariaDB and MySQL BLOB BINARY LONGBLOB MEDIUMBLOB MULTILINESTRING MULTIPOINT MULTIPOLYGON POINT POLYGON TINYBLOB VARBINARY YEAR UUID Microsoft SQL Server binary datetimeoffset geography geometry hierarchyid image rowversion sql_variant varbinary Oracle BFILE BINARYDOUBLE BINARYFLOAT BLOB INTERVAL_DAY_TOSECOND INTERVAL_YEAR_TOMONTH ROWID TIMESTAMP_WITH_LOCALTZ TIMESTAMP_WITH_TZ UROWID VARBINARY PostgreSQL BIT BIT_VARYING BOX BYTEA CIDR CIRCLE INET INTERVAL JSON JSONB LINE LSEG MACADDR MACADDR8 MONEY PATH PG_LSN PG_SNAPSHOT POINT POLYGON TSQUERY TSVECTOR TXID_SNAPSHOT UUID XML Snowflake ARRAY BINARY DECFLOAT FILE GEOGRAPHY GEOMETRY MAP OBJECT UUID VARBINARY VARIANT VECTOR Configure the record type's data access You'll choose your data access method when you create a record type or generate multiple record types. If you generate a database table for the record type, the record type will automatically use Optimized Data Access. Change a record type's data access You can change the data access method on existing synced record types or any new unsynced record types that have relationships and related features enabled. When you change the data access method, all field references will remain the same. Caution: Do not change the data access method for legacy record types. This will break field references. Instead, create a new record type that points to the same data source. Change from direct to optimized access To change a record type from Direct Data Access to Optimized Data Access: Open the record type. From the Sync Options page, click Change Data Access. Select the Optimized Data Access method. Click FINISH. Click SAVE. Change from optimized to direct access You can only change a record type from Optimized Data Access to Direct Data Access if it's connected to a MariaDB, MySQL, PostgreSQL, or Snowflake database. To change a record type to Direct Data Access: Open the record type. Remove the following items from the record type since they cannot exist on an unsynced record type: Sync filters. Sync-time custom record fields. Note: If you don't remove these items, they will be automatically removed once you change the data access method. From the Sync Options page, click Change Data Access. Select the Direct Data Access method. Click FINISH. Click SAVE. Feedback Was this page helpful? SHARE FEEDBACK Loading...