Thoughts on upcoming "Access previous values for rules in trigger filters and actions (via formula)"

1

Roadmap link: Fibery

Before going into it, I will note that a lot of this is already possible using a “{Field} Change” database that creates a new entity any time a field changes with the value of the new field. It also solves the issue this feature would be solving. My guess is that this feature is to make it more discoverable.

The ideal world (in my mind) is the ability to add a field type “Field Change Tracking” (which then asks which fields you’d like tracked), or in the advanced field settings add an “Add change tracking”. This would then auto make the database, populate all past changes from the activity log, add another formula field for “Previous {Field Name}”, and add the needed automations for the tracking to auto populate going forward. Since these “Macros” or “Field templates” aren’t really a thing in Fibery yet, I’ll suggest a different route as well (less powerful or flexible than a dedicated database):

From my understanding of the this, (I might be completely off), it sends the previous value of the triggering field into the function, making it possible to pull the value for filters and actions.

Why not treat it like a formula as opposed to a rule? As in, Field.[Previous Value]. Then in the no-code filters, it’s found by pressing on the little arrow, and then it’s in there as “Previous Value” of the field.

This opens a lot more doors and use cases.

You can make a view showing all entities that transitioned from one value to another. Since it’s retrievable via formula.
One thing can trigger the rule, but it’s not the thing in the condition.

Isn’t the data already there in the activity log? Just a matter of fetching the right thing?

This also opens (down the road) the ability to do stuff like Field.[Last Modified] and Field.[Last Modified By] or even Field.[Activity Log] to get the collection of changes.

This would achieve the same functionality, but be a lot more flexible and have more avaliable use cases.

Curious to hear your thoughts!
Please let me know if there’s something unclear, I’m happy to clarify!

Thanks!
Ron

2

This is not a good workaround in general that demands a lot of work to setup and maintain.

In this feature we rely on historical data we already have in Fibery. The problem here is that historical data is slow and opening it up for views and other queries will kill performance, so we are not gonna do it unfortunately

3

Thanks for quick response!

It’s been working very well on my end! It’s not to enforce rules, but just for stage duration analytics. I can see how for rules it might break if the state changes very fast though since it needs both an automation and a formula to find the previous value…

Ahh okay I didn’t know. Makes sense. Thanks for the explanation!! :heart:

4

This problem will be solved in better Workflow feature we have in plans for 2026

1 Like