Your organization is launching a new "Customer 360" initiative. They need to unify customer data that currently resides in two separate silos: a legacy on-premises SQL database and a third-party SaaS platform accessed via a REST API.

The business requirements are:

1. Unified View: Support agents must see a single, combined record for each customer.
2. Performance: The application must handle high-volume traffic without lagging, even when fetching data from the external API.
3. Business Intelligence: Management wants to use Process HQ to analyze this customer data and identify bottlenecks in the support lifecycle.

As a senior developer, how would you architect this solution using Appian’s Data Fabric? In your response, please address the following:

How would you use Record Types to bridge these disparate data sources?

What Sync Options would you configure for these records to meet the performance and reporting requirements ?

How does your architectural choice enable the data to be accessed and analyzed within Process HQ?

I would build this on Appian Data Fabric, using Record Types to give agents one data model across the SQL database and the SaaS platform. The architecture covers data integration, performance, and analytics. I would keep those three concerns separate and connect them through Data Fabric.

1. Connect both sources with Record Types

I would create one Record Type for each existing system.

Legacy customer (database-backed). This Record Type reads customer data from the on-premises SQL database. For example:

Appian connects to the database through a supported database connection. On Appian Cloud, that may need a VPN or another supported private connectivity option.

SaaS customer (service-backed). Appian supports REST APIs as the source for service-backed Record Types. I would set up:

1. An HTTP Connected System for authentication and connection details
2. An Integration Object that retrieves customers from the REST API
3. A Record Data Source expression rule that maps the API response into the shape Appian needs
4. A service-backed Record Type with optimized data access

For example, the SaaS system might return:

2. Relate the Record Types

I would join the two Record Types on a shared field such as customerId (Customer.customerId = SaaSCustomer.customerId). Appian relationships connect data from different sources without moving both into one database.

If each customer has one SaaS profile, the relationship is one-to-one. If the SaaS system allows several subscriptions per customer, I would add a Subscription Record Type and use one-to-many.

The identifiers have to match across both systems. If they don’t, I would build a mapping table that links them reliably.

With this in place, an agent opens one customer record and sees John Smith (ID 1001) with his Premium subscription, active status, and email, plus his recent support cases: CASE-101 (billing issue, resolved) and CASE-102 (login issue, in progress). Agents no longer switch between applications.

3. Configure synchronization for performance

Under high-volume traffic, sync is the main performance lever. I would enable optimized data access (data sync) on both Record Types. Appian then serves reads from its own data service, so interfaces don’t query the source system on every load.

SQL database. Incremental sync on a last-modified timestamp keeps routine syncs small. Changes made through the Write Records smart service sync automatically. Changes made directly in the database by other systems need one of the sync options above. I would schedule periodic full syncs to catch hard-deleted records.

SaaS API. I would page through the API in batches instead of pulling the whole customer set in one request. If the API can return changes since a timestamp, I would add a changed-data expression and use incremental sync. If not, I would run full syncs off-peak with a rate limit that respects the provider’s restrictions. Where it matters, I would add event-driven targeted sync to keep key customer updates fresh.

Other performance measures:

1. Query only the fields each interface needs
2. Paginate and filter customer lists
3. Index the SQL source queries where needed
4. Keep API responses lean
5. Monitor sync failures, sync duration, and query performance
6. Stay within the data limits of the capability tier

Sync filters apply to database-backed Record Types only. For service-backed ones, I would filter through the record data source expression and the API’s query parameters.

Sync speeds up reads but does not make the data real time. How fresh the data is depends on the sync strategy.

4. Prepare support data for Process HQ

Data Fabric reports and dashboards can use synced or unsynced Record Types. Process HQ process analysis requires synced Record Types with structured case and event history data. So I would add two more Record Types.

Support Case. One row per support request:

Support Event History. One row per event in a case’s lifecycle:

Support Case and Support Event History have a one-to-many relationship, so Process HQ can analyze the full sequence of activities for each case. If the application is built in Appian, I would configure Record Events to capture the activity history. Appian can generate the event history Record Type and its relationships from that feature.

5. Analyze bottlenecks in Process HQ

After deployment, I would work with the data stewards to make the data available in Process HQ and set up permissions.

In the example case, the ticket was created at 9:00 and assigned at 9:15. It then waited 2 hours 15 minutes before escalation at 11:30 and was resolved at 2:00 PM. Process HQ can measure durations like that across many cases. Management could use it to see:

1. Which activities have the longest waits
2. How often cases are escalated
3. Whether certain subscription types take longer to resolve
4. Which activities or process variations cause delays
5. How durations change after process improvements

Because cases are related to customer and subscription data, the analysis can use customer attributes, not just isolated tickets. Data Fabric supplies the connected business data, and Process HQ uses the prepared event data to show how the support process performs.