Audit Trail

I've been involved with building this sort of thing manually within Appian - not always but definitely sometimes capturing field-level changes. For me it's usually been the case that we use a master audit log table, which has specific columns indicating the acting user and date of change, a record ID field and a record type ID field, where the type ID tells us which data type / table it's acting on, and the record ID field tells us which actual row. Then to store record-specific details or field-level change details, or in other cases just a note about the nature of the audit log entry being made, there's a large text field in which we store JSON text, controlled by expression rules we write in Appian. This gives us the ability to have some flexibility in the usage for a fixed table structure, and tweak the granularity of detail we store when needed. For viewing the log data later, a different expression rule decodes the JSON data and usually keys off which record type ID that row has, etc. This method takes some manual work to set up obviously, but the benefit is you have total control over how it acts and is 100% Appian out-of-box.

I've been involved with building this sort of thing manually within Appian - not always but definitely sometimes capturing field-level changes. For me it's usually been the case that we use a master audit log table, which has specific columns indicating the acting user and date of change, a record ID field and a record type ID field, where the type ID tells us which data type / table it's acting on, and the record ID field tells us which actual row. Then to store record-specific details or field-level change details, or in other cases just a note about the nature of the audit log entry being made, there's a large text field in which we store JSON text, controlled by expression rules we write in Appian. This gives us the ability to have some flexibility in the usage for a fixed table structure, and tweak the granularity of detail we store when needed. For viewing the log data later, a different expression rule decodes the JSON data and usually keys off which record type ID that row has, etc. This method takes some manual work to set up obviously, but the benefit is you have total control over how it acts and is 100% Appian out-of-box.

My fear with doing it through Appian is that a developer can forget to implement the rule when they make a new process to update a table. This can create costly discrepancies between historical data and current data, especially if the historical data is being consumed by an external report. If you do it with triggers you never have to worry about that (but you could potentially have performance issues).

Yes, this is certainly a cost / risk inherent in implementing it the way I suggest.