Snapshot a State of Things

I can’t figure out how to approach the following scenario. Suppose I have a Thing called “Expense” that stores arbitrary user entries and each entry contains a field called “Label” and a field called “Amount.” How would I store snapshots of a current state of those fields. i.e. a user clicks a button and I store in a list of the current entered Expenses and those 2 associated field values. The user could then go on to add or remove expenses and also edit the label or amount of those expenses, and I would want the snapshot to still reflect the state at it’s own timestamp.

I could easily create a thing called “Snapshot” and create a entry containing a list of Expenses from a RG, but that would not contain the Amounts. Every way I think of it, something is left out.



The other way I thought about doing this is having a snapshot field on the expense, but I still have to pair an amount with a date. How can I store key / value pairs associated with a thing if the keys and values are both arbitrary in content and number?

If your expense values aren’t going to change, there is a database architecture approach called point in time that might be a good option. In a nutshell, things would only be created, never changed or deleted, and your snapshot would be a query of records for a specific time period. Otherwise, duplicating them in another table is probably your best bet.

1 Like

Ok, I think I get what you’re saying. My expense values will change both in number and in content. i.e. a user can add, delete and edit expenses. So, one day there could be 13 expenses and the next there could be 15 where 3 are new, 1 is deleted, only 10 are the same, and of those 10, 4 have new values and 2 have new labels.

But taking what you said about only creating, any time a user “edits” an expense, in the database, I would actually create a new entry pre-loaded with the data points from the “edited” expense, then archive the replaced expense so that it is not active but is still available for my snapshots. My snapshot would need to be linked then to a unique ID not a label, obviously.

Or, maybe you’re saying that when I take a snapshot, I could clone every expense and link the clones to the snapshot leaving the originals to be edited. Maybe both of those would work.

Thinking out loud here, does that sound like I get it? This is new to me.


Does anyone have an opinion about which of these two approaches is better?

Iterating an expense when it’s edited would mean less items created in the database, but cloning all for each snapshot would mean each snapshot has only its own expenses…

Hi Ian,

Sorry, I got busy at work so I couldn’t reply yesterday. There’s another consideration here that I forgot to mention - if you’re not on a paid plan, you don’t have access to API workflows, which are the recommended way to loop through data. That’s important, because it means you won’t be able to take a collection of things and move each one to another thing.
BUT, I did realize there is a 3rd option, and possibly the best for you. You can create a SNAPSHOT thing with a DATA (or whatever name you want to give) field, set its type to “Expense”, and check “This field is a list (multiple entries)”.


You can now do a search for the dataset you want to capture as a snapshot, and save all the data here. Be aware though that lists as fields can handle a limited amount of data, but if your snapshots aren’t going to be more than 30 - 50 items (I’m guessing on that limit), you should be fine.

Hope that helps!

1 Like

Forgive me, I have been away for a couple weeks. I really appreciate you thinking thru this issue with me. I don’t think this 3rd option will work because the expenses that are linked in the field in your Data thing could still be updated and thus won’t necessarily reflect their state at the time the snapshot was saved.

I also hadn’t considered the API restriction, so I appreciate you pointing that out.

Looking at my first understanding of what you said- a user who edits and expense actually creates a new expense cloned from the one they are editing, so that this duplication happens only one at a time in this scenario instead of cloning a batch of them at the time the snapshot is taken. That sounds like it might be preferable as far as taxing the database is concerned.

Glad to help - best wishes for success on your product!


1 Like