I have a form that has a member ID and also first and last names...in that same form I need to capture in another field the previous member ID and name should the user change the name or mbr ID in the text/numerical fields.
I'm unsure how to set this up the fields in the same form and if / how to do this in a pipeline or another way.
Qrew Legendnp,
A Pipeline is your easiest solution and most reliable because it will work on Forms as well as Grid Edit or even imported records. Create a fields to hold the previous values, obviously.
Then create a Pipeline to Trigger on Record Updated, specify it should trigger on any of those three fields being changed. Then also specify those three fields to be used in subsequent steps.
Then the second and last step of the pipeline will be Update Record and write the previous values of those fields into your set of three fields you created to hold the previous values. The tricky part which is not that tricky once you know it is the syntax for capturing the previous value.
The easiest way to do that is to first populate those three fields with the selection of the regular field so for example Member ID.
Then look at the box where you put that and there is this symbol that looks like this at the top right corner </>. Click that and observe that it will toggle back-and-forth between the friendly looking label and the somewhat less friendly looking syntax that would look like this
{{a.Member_ID}}
Simply carefully hand edit that field to read like this
{{a.$prev.Member_ID}}
And do the exact same thing with any other fields you want to track the previous value of.
... Having answer the question you've asked, I will point out that it is not really what you need because what happens if the user changes their Member ID or name once again.
The best way to do this really is to have a child table of an audit log and what you would do is do the same kind of thing but instead you will create a child record into a table that you will have created for your membership record called audit trail or something like that. If it's just a few fields your tracking like those three then you can have three fields on the record and you were just write the previous values into those three fields.
The other thing nice about that is it automatically gets date stamped with [Date Created]. If you'd like you could also create a user field and populate who edited the membership record into that field so you know not only when the change was made and what the change was but who made it.
Here is one way to solve it. Clients have a problem when ever the sales department changes the Forecast Close date on their Opportunities. Suddenly $50K disappears from next month and appears a year later. So the question is what was the last date, who changed it and when?
Not identical to your scenario but pretty close. Here is the solution:
You make a child table for the info that needs to be reviewed or revisited when it changes. That way the new info is not really a change, it is actually the last entry.
You make a summary field for the Maximum Record ID of the child table on the parent table. Then create another relationship back to the Parent using that as the Reference Field. The current data is then really a look up field coming through that relationship.
You get some interesting conversations when you can point out who made the "change" at 4:22 PM on Tuesday of last week.
Thank you, I will look into this!
