Appian Community and Appian Academy are being upgraded. As a part of the upgrade, Appian Community is currently in read-only mode, and user registration is disabled until August 3. We apologize for any inconvenience this may cause, but a more secure, stable, and performant Community experience is coming soon!
The new Appian Community launches August 3, followed by Appian Academy on August 7. During the migration, Appian Community Edition, Appian Academy, Documentation, Certifications, Instructor-led Customer Training, Partner Sales Training & Accreditation, and Forum (for Appian Partners and Customers only) will remain available.
Hello everyone,
In the recent update (version 26.1), we received a feature that allows us to create sync-enabled record types using a view as the data source.
However, the Sync smart service is not working with this type of record. Is this an Appian limitation? If yes, how is a sync-enabled record useful in this case? I am aggregating some information in a view and displaying it on the site, and I need up-to-date data. Therefore, I cannot rely on incremental or manual sync. Could you please suggest an appropriate approach?
Discussion posts and replies are publicly visible
Well, depending on your use case, a synced record might be the best fit. Or not. In your case disabling sync might be the way to go.
Sync Records smart service syncs by record id, but views have no change-tracking, so view-backed synced records only support full sync (not incremental).Don't use a sync-enabled record for always-fresh data. Use a non-synced record type on the view instead(it queries the view live every time, giving you real-time data). Sync trades freshness for performance, which is the opposite of what you need.
Thanks for the reply Stefan Helzle After checking the log files, we found that we were using ROW_NUMBER() to generate a unique key in the view. This was producing a 32-bit BIGINT(21), which we were using as the primary key for the sync record. However, the generated key of type BIGINT (21) was not supported by the record type. After converting the key to text, the issue was resolved.
Thanks for the reply Shubham Aware After checking the log files, we found that we were using ROW_NUMBER() to generate a unique key in the view. This was producing a 32-bit BIGINT(21), which we were using as the primary key for the sync record. However, the generated key of type BIGINT (21) was not supported by the record type. After converting the key to text, the issue was resolved.