Forum Discussion
- QuickBaseCoachDQrew CaptainWell one thing that you could try to set up a field called date log which is a another text field set to log changes. And then using form rules set up a rule that says when the record is saved and the date field has changed change the date lock to the value in the field Date.
But because this is based on form rules, that means it will not work in grid edit. - ScottScott1Qrew MemberWe are moving more to custom forms, so that should not be too much of an issues.
Sounds promising.
Would the text log field, update with a user and date per normal?
Having an additional field would allow filter in certain reports to just see the current, so that is also beneficial.
Can you please advise what the fom rule would look like? - QuickBaseCoachDQrew CaptainThe form rule would look like
When the record is SAVED
and the [Date field] has changed
Action
Chage the value of the field [[my text field set to log chnages] to the value in the field [Date field]
And yes, a field set to log chnages, does always record who did the update and the date and optionally the time of day. - ArshadKhwajaQrew CommanderMark, does this mean that logging is inly available on text fields?
- QuickBaseCoachDQrew CaptainYou can log any field I suppose. It will get logged using a form rule into a text field, but you can write a number or date field into a text field.
- MCFNeilQrew CaptainA more sure fire way to log data changes is through a Data Change table. Then you just have a button to change the date.
You also wont have to maintain a bunch of different forms with their form rules.
By creating a date change record, you automatically keep track of who, and when. You can add a bonus feature really easy as to the why.
Long term this is the most efficient and cleanest way to track your date changes.
I can explain in more detail how to set this up properly if needed.- ChristinaHermanQrew MemberHi Matthew,
I would like to learn in more detail how to set it up.
thanks for your help.
Christina
- ArshadKhwajaQrew CommanderThanks. I am already using QB Actions. Is this what you are referring to?
- MCFNeilQrew CaptainNo, I'm saying you can make a table called "Date Changes". And use that to keep track of your changes, and who (and why if wanted)
>
Just one Field;
"Date"
A second field would be needed if you had a "Why"
>
Each 'Project' can have many date changes.
>
Summarize Max Record ID
>
Pass new max RID as lookup
>
Summarize Date where max RID = Record ID#
Now you have your log of date changes with time stamps and record owner.
Much cleaner and more scalable if you have multiple dates that need to change. Also gives you much better reporting outputs. (ie. How many times this date has changes, most frequent cause of Date changes, who makes the most changes, etc.) - ArshadKhwajaQrew CommanderGot it. Thanks. Yes I am using the same approach for summering some info. So Understand the concept. Thanks.
- ChristinaHermanQrew MemberHello Matthew,
out of what you wrote above I am not able to reapply it. Could you please send me a more detailed description of how to set this up please.Just one Field;
Thanks a lot,
"Date"
A second field would be needed if you had a "Why"
>
Each 'Project' can have many date changes.
>
Summarize Max Record ID
>
Pass new max RID as lookup
>
Summarize Date where max RID = Record ID#
Now you have your log of date changes with time stamps and record owner.
Christina - QuickBaseCoachDQrew CaptainChristine,
Matthew is suggesting that you create a child table of dates and make your date updates there. Then you will have a very clean audit trail of the date changes.
Post back if you need help with that. - SuscoImplementaQrew TraineeThanks to QuickBase webhooks it's now pretty easy to create history tables where you can log old record values. Let's say you have a helpdesk Ticket table, you can create a TicketHistory table and use webhooks to create a new record whenever a Ticket is modified
- QuickBaseCoachDQrew CaptainGood 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.
- MichaelKefauve1Qrew 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?
- QuickBaseCoachDQrew 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.