Forum Discussion
QuickBaseCoachD
8 years agoQrew Captain
Good point, it now that we have ACTIONS we can set up a log table that way, and not need to struggle though the Webhooks Syntax. So using that method, you just update the date normally and the ACTION will do the logging.
- MichaelKefauve17 years agoQrew MemberI am currently looking at a similar application where I want to track/log changes to a date field. I understand the approach of using an action to update a child table, however, I have 25 different date fields that I want to track. So, that means 25 different child tables, right? Would that be more efficient, or would it be more efficient to create a separate log field for each date field, each with it's own form rule? Also, is there any way to not show the user ID and date of entry in the log field, i.e. just display the list of sequential entries?
- QuickBaseCoachD7 years agoQrew CaptainYou would not need to have 25 child tables as you could have an identifier in the log table to identify the field.
But maybe in your case, yes set up 25 log fields and 25 form rules to populate the log fields.
The there is a formula I can help with to count the # of updates. So you will need 25 formuals. Then you will need 25 more formulas to to parse out the most recent date update.
I think if I had to that somewhat ugly project I would use a child table. you can have I think 20 Automations per table to trap 20 date field changes and 10 Actions to trap the remaining 5.
Otherwise you need to use a webhook to log all 25 when any of them changes and then using an automation delete out the date changes that did not change.
This is just an overview - due to the large # of fields to be tracked its not a trivial project.