Suspend Triggers and Actions during Background Task Updates

No-Code Platform
1

We have a situation where we need to display calculated fields in Text format (9999 mins/hours/days) etc in the list view of a table. Naturally this is time based, so it needs to be updated regularly (daily is fine). But we find that a regular update also trigger all the validations, default settings and integration actions (like sending messages to Outlook) which we really do not need to happen during this update. Also we find that some older records which will fail the current validation for some reason, also fail being updated. Is there a way, similar to Data Transform, which we can run as a scheduled run which will suspend the triggers and actions while we update these display fields? It does not seem that Data Transform was created for this type of daily single field update across all active records in a table.

2

I’m not aware of away to suspend triggers and so forth when making these types of updates.

However another approach to this, on the assumption the data doesn’t need to be persisted and is for list view display purposes would be to:

  • Add the display field as a work field to the underlying table
  • Create a UI type logic block that performs the necessary calculation and sets the value of the display field
  • Attach the UI logic block to the application as a Load Data on List Form event action

I did that in the attached example where I calculate the age of someone based on their birthdate

image
image3303×1684 404 KB

Bug again - if you need to Data Export this data or persist it - this approach does not work. In my experience it has also led to folks who weren’t involved in the development process to think the platform is broken when they export data from these and the fields are empty/missing.

1 Like
3

@ian.p has some good insight into this - populating a field with a temporary value is the best you’ll be able to do without firing table triggers, but that will not update the table records and will not persist through export.

When a logic block uses the Update Records logic action, it will always fire table triggers. Regardless of logic block type (background, transaction) or method of execution (job scheduler, integration, manual), logic that fetches and updates a table record directly will always run associated Pre-Update and Post-Update triggers.
Having said that, there are some development tricks and techniques that can get around the issues you’re seeing. I’ll detail at a high level, but happy to go into more detail for each if desired:

  • Simplest - don’t use update triggers. Does the record at hand need update triggers or only inserts? Obviously this is unlikely to be viable.
  • Cater the logic not to validate certain records:
    • Use the trigger and associated events / notifications / approvals / etc. to first check what is changing on the record. If fields x, y, and z did not change, you might not need to execute some or all validations
    • Can the older records be marked as Archived or otherwise closed out? Generally, if this is old seed or transactional data that is out-of-date, they could be marked as such with workflow or a field value, then your validations can avoid such records. If these records are still in use in any capacity, validations should absolutely fail when attempting to modify those records because they are no longer valid
  • Unlike triggers, Action Blocks do not run when a record is directly updated with a logic block. This can be used to your advantage - certain processes call the action block, which houses your validations, events, etc.; other processes (like this date calculation) update the table directly. If there are no triggers to run because those are configured as an action block, updating records each day won’t cause all of the event and notification overhead
1 Like
4

Thanks Ian. For now this approach would not work as we also do some other processing based on the calculation results, and would use it in some reports etc.

5

Hi Ross. thanks

Great I think given your answer on Action blocks, I had a relook at our problem we see. Both would have been circumvented if we had a switch not to apply any validations:

  1. The first case are actually old records (test records in development test cases) which are incomplete and in some cases refer to Table Lookups which somehow got deleted. We get a message that the TL no longer exists. These are clearly errors outside of either Action or Trigger LBs. Integrity issues it seems.
  2. We have some actions that fire from the Triggers which we would want to not take place if we are just running the calculation update. These we can probably handle by setting some variable during the CalculateLB, and then test for that in the trigger, etc.

But it just makes sense then to identify these old error records and eliminate or fix them somehow. I did fix via online a record or 2 and they then disappear from our errors list that gets reported..

Thanks for your explanation. Typically when you know what to read in the help, it is there. It is just not always simple to know what to look for in Help..