Appian Community and Appian Academy are being upgraded. From July 24–August 3, the Appian Community will be in read-only mode. During this time, the site will be read-only and user registration will be disabled. 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.
Hi All,
I am able to update one entry of a ticket.
In process model, I have update Form view with populated data; i need to store copy as old version i.e. before submit/save using process model as per below screenshot,
How to achieve this?
Finally, i want to get list of all updates done previously for a given ticket number and show in table grid view.
I guess before submit/save i need to add some node.to insert data before save data
Thanks,
Deepak
Discussion posts and replies are publicly visible
As a best practice, maintain a history table in DB, which records the changes.
yes, I want to maintain historic table but how to design process model ? How to design and write ?
The changes to be done on DB side.
Create triggers on the existing table and insert the values into a new history table.I am not sure about the syntaxes, https://mariadb.com/kb/en/trigger-overview/ should be helpful.
From Appian - You can then simply query the history table
As other users have mentioned, you may wish to use your underlying database to do the heavy lifting of data version management.You may also wish to have a history table that allows you to insert the old copy of the data as a historical copy and update the current data into the current version table. In order to do that you might take several approaches:1) Have two Write to Data store node entries (which may even be parallel flows) that write the old copy and update the current data.3) Use a write to Multiple Data Store node to do both of those jobs in one node. I prefer the first option for any analysts and future maintainers, because it's easy to label two nodes meaningfully, but one node would require a little investigation to understand.From a CDT perspective, it might look like this:Main table:
History Table:
You could then always select data from the history table by recordId and order by dateModified to see the historical changes to a given record in the main table.
It might look like this:
If you feel like you need to do some error checking, you could probably evaluate the success of the first write before performing the second.