'Old' and 'new' field value for Record Rule

As a Builder, when creating a Record Rule on the form, I want the “old” and “new” field values, so I can track changes more easily.

Knack has a feature for “has changed” in Record Rules. When “has changed” is selected, I would like the “field value” to be separated into two options—the old value and the new value. Please see the screenshot below:

The benefit in our particular use-case is to track changes to a record. We often create a separate object e.g. Logs, and insert a connected Log record via Record Rules, on update of some record we would like to track. However, because the field value is limited to the new field value (i.e. after the Record Rules run) our Log cannot capture the current value of the record before it was changed, we can only capture the change. To capture the current value of the record we are forced to use workarounds such as JavaScript or Integromat scenarios, making the workflow harder to maintain.

Tracking changes is a challenge, this kind of option would help :+1:

Agreed. This would be great!

100% agree with this, keeping a record of a previous value can be painful (and I’ve also used Zapier and custom code to solve this in the past). A common use case is sending an email notification to a user to notify them of a change and including both the before and after state.

But I’ve recently started using a native workaround and it’s actually pretty easy.

Knack’s documentation states that field equations are not updated until after record rules are run. This means that you can use a text formula to get the current state of any field and have that pre-change value available when record rules are run.

So, for example, with three fields:

  • Status (the field we want to track)
  • Status Staging (a text formula that holds the value you will save to the previous status field)
  • Previous Status (a text field to store the previous value)

you just need one record rule to keep track of the past state:

The text formula makes this fairly flexible - it should work with most field types, as long as it’s OK to save the previous status as text.

If you need to track the previous value of something as another field type (like a connection) it gets harder, but it’s still possible to extend this approach to do so. Requires multiple connections to the same object, with two mirrored record rules that save the previous state to either field A or B depending on the state of another field that tracks which of A or B currently holds the previous value.