Hello All ,
we have a database view , using that we created a record ( disable data sync) as Appian record is not allowing view with enable sync option.
facing performance issues with this Appian record picker, please can someone help with the following questions :
Question 1 : how can we implement a minimum character requirement for the search input in the record picker (pickerFieldRecords) to reduce the number of database queries ?
Question 2 : how can we limit the initial load to a smaller subset (i.e. only load 20 result based on user filter) of records to prevent performance bottlenecks ?
Question 3 : is there a way to implement Appian caches record data in memory with disabled data sync record type ?
Thanks!
Discussion posts and replies are publicly visible
If you truly want to leverage a synced record type, one valid approach is to define a Web Service (Integration) as the data source instead of querying the database view directly. This allows you to take full advantage of the capabilities provided by synced records, such as:
Improved performance through Appian’s in-memory caching for synced data.
Full support for pickerFieldRecords with optimized search and filtering behavior.
pickerFieldRecords
Ability to control data synchronization frequency, including on-demand syncs via a related action or process.
To implement this:
Create an Integration object that calls a web service (which returns the view data).
Use that Integration as the source of a Synced Record Type.
Map and configure fields accordingly for use in your record picker or interfaces.
This way, you avoid the performance pitfalls of live queries against complex database views and gain the full benefits of Appian’s data sync architecture.
That said, it’s important to note that the current approach (using a non-synced record type based on a view) is not inherently wrong. In fact, if the view performs well and the volume of data is manageable, this solution is perfectly acceptable.
However, if you're experiencing performance issues now — or anticipate scalability concerns in the future — the synced approach via Integration offers more control and flexibility.
Ultimately, the key is to base the decision on a clear understanding of the performance profile of the current view and its expected usage
As data base views are notoriously known for performance issues, I highly recommend to either find a different solution, or optimize the view performance.
Answers to your questions:
Q1: Not
Q2: No
Q3: No
Any functionality based on a slow database view will be slow.
Thanks Alberto Cortés for your prompt response. I like this idea to create web service and leverage all the Record features.
Just to mention one important consideration: When using a synced record type backed by a web service (Integration), the data you get in Appian is not real-time. You only have access to the last synchronized version of the data, which means any updates in the source system won't be reflected in Appian until the next sync occurs (either scheduled or triggered manually).
If real-time data is a strict requirement for your use case, then this approach might not be ideal unless you're able to control the sync frequency or trigger a sync as part of your process.