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.
We are consuming data from an external view that only returns records where:
BPM_PROCESSING_STATUS IS NULL
BPM_CASEID IS NULL
This external view is built on top of a base table that contains all records.
When a case is created in Appian, we update the base table using a Query Database Smart Service, populating:
BPM_CASEID
BPM_PROCESSING_STATUS
Since we do not have access to define a primary key on the source table/view (due to grant restrictions), we:
The identifier (ROW_NUMBER) is not stable.
ROW_NUMBER
Example:
3000271
3000313
3000341
We need a way to:
Is there a recommended approach in Appian to handle:
Discussion posts and replies are publicly visible
Use a stable source key (UNIQUE_ID/UIN) as the record identifier - ROW_NUMBER() changes on every refresh, which is why sync fails. Appian only needs the key to be unique, non-null, and stable, not a real primary key.Keep all rows in the source and add a status column to mark them processed instead of filtering them out. Use record filters to hide processed rows. This stops records from disappearing, so sync never references missing Ids and avoids Delete Records, which can't run on a materialized view.Enforce UIN uniqueness in the database or stored procedure, not in Appian sync logic.