Forum Discussion
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------
- MarkShnier__You5 years ago
Qrew Legend
In brief you would set up a child table for an Audit Log. hen have an Automation fire when the record is edited and certain fields change.
The Action Steps of the Automation will write to the Audit trail table the field name, the old value and the new value and the [Last Modified by].
That is also record many entries where the old value and the new value are the same if you are tracking several fields. So then have a nightly automation to delete the duplicates. Fell free to post back if you get stuck.
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------- DanielJohnson24 years agoQrew TraineeHey Mark,
I inherited an app that had an Audit Log table that was using webhooks to log changes. It wasn't entirely clean. I modified it to log the changes to a record using Pipelines. However, the form view also had a "Milestone" section that had summary fields from the Audit Log table that showed the progress of each record in a section inside its form view. I made new fields in the Audit Log for the Pipelines and when I was about to make the new summary fields, I thought, why not just make a new field in the original table and make a Pipeline that updates that record when changes are made? It seems to be working for our standard case. Can you think of a reason why this wouldn't work? Are there any pros and cons in logging the changes in the original table using Pipelines versus logging the changes in a child table using Pipelines?
Curious for your thoughts.
Thanks,
Daniel
------------------------------
Daniel Johnson
------------------------------- DanielJohnson24 years agoQrew Trainee
To be clear, we've got 2 Pipelines running to log records in the Audit Log, 1 for when new records are created and 1 for when records are updated. Since I want to track a status field, the only way to get something like an If statement in Pipelines is to implement a condition. Each status I want to track has its own field in the parent table in this Pipelines setup, which means each field must also have its own Pipeline, totaling 7 in my case. So, one question is, what's better, a summary field or a Pipeline? Also, what happens if the record progresses normally through the statuses, but because of an error has to backtrack and go through the statuses again? Will the summary field pick up the new changes? Or keep the original data? The Pipeline updates the record, so it would show the updated data, which is I think what I would want. I guess to the point of the original post, to cover those edge cases when a record has to backtrack, is it possible to form a formula text field that just keeps adding lines to text box every time the status field changes? It would be something like:
At [date/time status field changed] the status changed from [previous status] to [current status]. The time between status changes was [duration smart field].
------------------------------
Daniel Johnson
------------------------------