Forum Discussion
EvanMartinez
6 years agoQrew Elite
Hi Nicola,
I would agree with Mark that it is usually very handy when tracking things like a status change in a record to make a child table for that tracking. That way your new table can have a field to track What the status changed to, when was it changed, and by who and then that history can live in a table nice and accessible to those who need it but out of the users who don't need its way. Then once that table exists with the right field you can use Quick Base Automations and set them up to say every time a record is added or modified and the status field changes add a new record to the Status Tracking table and copy over the change and the time of the change. There is a Quick Base University less that actually goes over this kind of use case that might be helpful to walk you through some of the options and see if it might be the right fit for your need:
Track Data Changes with Automations
I would agree with Mark that it is usually very handy when tracking things like a status change in a record to make a child table for that tracking. That way your new table can have a field to track What the status changed to, when was it changed, and by who and then that history can live in a table nice and accessible to those who need it but out of the users who don't need its way. Then once that table exists with the right field you can use Quick Base Automations and set them up to say every time a record is added or modified and the status field changes add a new record to the Status Tracking table and copy over the change and the time of the change. There is a Quick Base University less that actually goes over this kind of use case that might be helpful to walk you through some of the options and see if it might be the right fit for your need:
Track Data Changes with Automations