A custom procedure that updates a related record's date field, based on values fetched from the same table it's updating, works fine as a Custom Menu but crashes with a mutating-trigger error when the same logic runs from a Custom Event fired on record creation. Passing the call through Transaction_SYS.Deferred_Call to move the update into a background job doesn't help, since the target procedure has OUT parameters. What's the correct pattern here?

All FAQ questions / Workflows and automation

Answer

Transaction_SYS.Deferred_Call can't be used directly against a procedure that has OUT parameters — this is a hard requirement of how Deferred_Call's execution mechanism works. Instead, wrap the actual target call (needing OUT parameters like objid_/objversion_) inside a separate intermediate procedure that itself only accepts IN parameters, and call THAT wrapper procedure via Deferred_Call, passing whatever data the wrapper needs bundled into a single IN attribute string. The wrapper procedure then handles calling the real target procedure with its OUT parameters internally, once it's actually executing as a background job rather than inside the original mutating-trigger-sensitive transaction.

Documentation-based answer. Confirm the product and release before applying it. This answer has not been verified in an IFS environment.

← Browse Workflows and automation questions