Applications have an Event action called “Field Value Changed”. It would be great if the application could send to an LB which field has changed (name). We trigger different actions based on the field, but most of the logic is identical; it is just passing different values. Since the application knows which field changed, it would be nice if it could inform LB which field changed, and on our end, we could implement conditional logic. This will allow us to use a single LB.
There are some benefits and detriments of using the same logic block for multiple different events on the same application - while it is appealing from a maintenance perspective, having many different actions queue the same logic block leads to dependencies and regression potential. Every case is worth considering the architectural impacts if these objects are likely to change in the future, but it’s often best to break logic down into small pieces per-change to prevent maintainability issues in the future.
It is also possible to use a Fetch Original logic block action to find the unmodified version of a record, store work fields on the record that indicate the original or previous value of a field, or potentially refactor logic to look at the current state of the record as opposed to hinging on what changed, though all of these have some drawbacks. Happy to get into some more detail about an individual option if you have questions!
If you are a customer or partner and would like to submit a feature request for passing the field name to the associated logic block, please work with support to create a ticket.
1 Like
We could use “Fetch Original,” but for performance reasons, we avoid fetching data when it is not needed.
1 Like
Definitely understood. That’s one of the reasons I mentioned referencing the current state of the record - an action block or insert/update trigger can understand the entire context of a record and its changes, so it can evaluate field values and whatnot when any combination of fields has changed since the last save. Record management in the UI with event actions is certainly possible but can get exceedingly complex when lots of fields are responsible for modifications to a single target field, for example. This is why we recommend splitting event actions into individual pieces rather than handling multiple within the same logic.