This points to a mismatch between Appian's process engine persistence timing and record type data source caching/consistency, rather than being a simple "refresh" issue. A few things could be happening together:

1. Process engine execution timing

The subprocess is being called asynchronously, so the parent process does not wait for the subprocess to complete. The subprocess may still be executing and writing to the database while the user interface is already attempting to read the record.

Under high concurrency, this can create a small window where the database write has not yet completed or committed when the interface reads the data.

2. Record type caching / synchronization delay

If the record type is backed by a synced data source, Appian maintains synchronized record data that is updated through a synchronization process rather than necessarily reflecting every database change immediately.

Therefore, even after the subprocess successfully writes to the source table, the updated value may not immediately appear in the record-backed interface. This synchronization delay is a common cause of stale-data complaints and can easily be mistaken for a caching issue.

3. Multi-node / database read consistency

In a clustered Appian environment, if the database architecture uses read replicas or load balancing, a read performed immediately after a write could potentially reach a replica that has not yet received the latest change.

This is a classic read-after-write consistency issue.

Diagnosis steps:

I would diagnose it in the following order:

1. Check whether the record type is synced or unsynced. This is one of the most important things to verify.
2. Check the sync frequency, schedule, and synchronization status for the record type.
3. Check the process execution history and logs to determine exactly when the asynchronous subprocess completed its database write.
4. Run a direct SQL query against the source table and compare the result with what the Appian record shows.
5. If possible, reproduce the issue under high concurrency and compare the timestamps of:
6. Subprocess completion
7. Database update
8. Record synchronization
9. UI refresh/read

This will help isolate whether the issue is at the process, database, record synchronization, or UI layer.

Fix options:

1. If the data needs to be available immediately, consider making the subprocess synchronous so the parent process waits for the database update to complete.
2. If the record type is synced and near-real-time accuracy is required, review the record synchronization strategy or use an unsynced/direct read for that specific use case where appropriate.
3. If synchronization is the issue, consider an appropriate event-based or on-demand synchronization approach, depending on the Appian version and architecture.
4. If database replication is involved, verify that reads are not being directed to a replica that is behind the primary database.

In short: the most likely issue is a race condition between the asynchronous database write and the record read, potentially combined with record synchronization delay. The first step is to determine whether the source database itself has the latest value or whether the stale value exists only in the Appian record layer.