Triggered actions and webhooks are two platform capabilities that allow you to listen to an event (such as a record update) and perform some action as a result.
With this release, we have significantly reduced the feature gap between these two capabilities, specifically in relation to standard ‘object modified’ webhooks. Developers should consider Triggered actions the preferred capability and use it in preference to Webhooks in future.
This release includes several improvements:
"Previous" data available in the payload
Developers can now include the "previous" state of a record in the ‘object modified’ data payload, as well as the operation that was performed alongside any additional data requested in the ‘query’ for the triggered action. Developers must include a new ‘previousFields’ option within the action definition.
The previous state of the object allows developers to interpret what changed on a record and implement any required business logic.
For details, review the Call URL Payload section in the documentation.
Support for "record deleted" events
Prior to this release, when a record was deleted and a triggered action was invoked, an empty data payload was sent, which was not useful. If a developer includes the ‘previousFields’ option within their action definition, the payload will now include the values of requested fields in the record, prior to its deletion. The UID field will always be included to identify which record was deleted.
For details, review the Call URL Payload section in the documentation.
SKEDULO_USER_TOKEN
Prior to this release, triggered actions usually contained an API token in the ‘Authorization’ header of ‘call_url’ actions when the destination URL was that of a connected function. This was so that the function could make subsequent requests to Skedulo APIs. This had the drawback that all subsequent requests from the function were performed as the user who created the API token (generally an administrator user). Audit fields, such as ‘CreatedBy’ and ‘LastUpdatedBy’ recorded the user associated with the API token, not the user that initiated the original change.
With this release, for triggered actions from an ‘object_modified’ trigger to a ‘call_url’ action, developers can now include a special template string {{ SKEDULO_USER_TOKEN }} in the header of the action. When that is included, it will be replaced at runtime by the access token of the user who performed the data change that initiated the ‘object_modified’ trigger.
Note that ‘SKEDULO_USER_TOKEN’ is now a reserved key and cannot be used to create a configuration variable.
For details, review the Set user context section in the documentation.
Backwards compatibility
The ‘previousFields’ option must be added to any existing triggered actions before that data is included in the payload. If not, there will be no change to the data payload.
Similarly, developers must update existing triggered actions to reference the new {{ SKEDULO_USER_TOKEN }} header template if they want to change the execution context of the action.
Note that the access token of the initiating user usually has fewer access privileges than API tokens from administrator users. Hence, when migrating to use this feature, the function invoked should make sure that it will work with the new access privileges.
Updated documentation
Please review the updated documentation for more detail: