Issue with notifications and calculated fields
We have a problem with notifications and calculated fields that depend on other tables.
The issue we have is the following:
We have two tables, table "A" and table "B", linked together. The table "A" has a field calculated according to the data of some records in table "B".
When we change the data of these records in table "B", the calculated field in table "A" changes value.
We want to make a notification based on this calculated field, but nothing got sent.
It will only be sent if we modify the data of the registry in table "A" and save it. If we do not change the registry of table "A", even if the calculated field does it correctly, the mail is not sent.
Thank you in advance!!
This is known behavior of the platform, and has to due with the order in which things are being done and how things behave. Notifications require what I call a "hard save" to a record in order to trigger. Things that enact a "hard save" are user, data feed/import, or API interaction. Then we have the concept of a "soft save", which is things like related calculation jobs, recalculating a single record, a scheduled app recalculation, etc. Essentially things that occur in the background.
What you are experiencing is that when you save B, it triggers an asynchronous job for the platform to process to update A. This update process applys a "soft save" to A, thus your notification is not triggered, but is when you manually edit and "hard save" A.
To get around this, you will have to introduce some form of a "hard save" on A. An Archer-to-Archer data feed or a custom API utility are the typical approaches, whereby the method finds records where A has changed in this manner, and feeds a value into some field to cause the hard save and thus trigger the notification.
Hi Scott - Could you please help me understand if notifications would be triggered on manual data import too provided the trigger conditions are met
It is my understanding that they do not. They behave the same as the application calculation you can schedule within App Builder, just have finer granularity to the schedule and the ability to selectively filter which records to calculate.
This delineation between hard and soft save has all sorts of implications, and some of them are either long standing behavior, foundational to other features, or both. I do not think we will be modifying this behavior anytime soon, as it would be a sizeable effort on our side as well as a fundamental change in platform behavior on the Admin side.
That said, search RSA Ideas for the RSA Archer Suite" data-type="space to see if something exists and comment/vote it up. If you don't find anything, create it. If there's enough support for the Idea, we could potentially pull it in.