Execution hooks and policies
An execution hook is a step that runs around a Source or Target node: before it reads or writes, after it, or when it fails. The execution policy says what happens to the run when the node fails. Both are in the node's Advanced section.
How hooks are set up
A hook has two parts:
- The hook action belongs to the connection. Open Advanced > Execution Hooks > Hook Actions on a node and pick a step to say what it does: run a script, turn off triggers, call a webhook, and so on. Every node on that connection can then use it.
- The node lists which hook actions it runs, under Pre-steps, Post-steps and Error-steps. Up to 10 in each.
| Phase | When it runs |
|---|---|
| Pre-steps | Once, before the node reads or writes its first row. |
| Post-steps | Once, right after the node finishes or fails, for every node that ran. |
| Error-steps | Once, when the node fails, before the run follows the node's execution policy. |
A step can be a pre-step or a post-step, not both. An error-step can be one of the node's pre-steps or post-steps as well, such as a webhook that reports both.
When an error-step fails, the run log records it and the node's own error is what the run reports.
What each connector offers
Each connector offers only the hook actions it runs. The list for each connector is shown when you pick a hook action.
| Connector | Hook actions |
|---|---|
| SQL Server, Oracle | Run script, Saved action, Truncate table, Drop table, Delete query (WHERE), Add index, Turn off triggers, Turn off constraints, Webhook |
| PostgreSQL | Run script, Saved action, Truncate table, Drop table, Delete query (WHERE), Add index, Turn off triggers, Webhook |
| MySQL | Run script, Saved action, Truncate table, Drop table, Delete query (WHERE), Add index, Webhook |
| Snowflake | Run script, Saved action, Truncate table, Drop table, Delete query (WHERE), Webhook |
| Salesforce | Org controls: validation rules, Apex triggers, Apex trigger bypass, flows, duplicate rules, matching rules, entitlement processes |
| SFTP, FTP, FTPS, Amazon S3, Azure Blob Storage, Dropbox, Google Drive, OneDrive, SharePoint | Create directory, Delete directory, Delete file, Rename, Webhook |
| Every other connector | Webhook |
A node whose step uses an action its connector does not offer does not start. The step is marked Not available in the node's Advanced section.
Turn off triggers or constraints
This database hook action turns off the triggers, the constraints, or both, on the tables you list, and puts each one back after the node. It runs as a pre-step only.
- Only what is on is turned off, and only that is turned back on. A trigger that was already off stays off.
- The original state is restored right after the node finishes, including when the node fails. When another node in the same run still needs the same item off, it stays off until that node finishes too.
- On SQL Server, constraints are foreign key and check constraints. A constraint that was trusted is re-checked against every row when it is turned back on, so rows that break it make that restore fail and the run log names the constraint.
- On Oracle, constraints are foreign key and check constraints other than NOT NULL. Each is turned back on with the validation it had.
- On PostgreSQL, user triggers are turned off. Constraints are not offered: turning them off needs a superuser.
- MySQL has no per-trigger switch, so this action is not offered there.
The connection's user needs the right to alter the listed tables.
Salesforce org controls
Org controls turn validation rules, Apex triggers, flows, duplicate rules, matching rules and entitlement processes off or on. With Restore after node finishes ticked, each control is put back to the state it had right after the node finishes, including when the node fails.
Apex triggers are turned off and back on by deploying the trigger with a new status, which takes a short while for each trigger. This works in sandboxes and Developer Edition orgs only: Apex cannot be changed in a production org. The connection's user needs Author Apex and Modify Metadata Through Metadata API Functions (or Modify All Data). Triggers in a managed package cannot be turned off. When the connection cannot turn triggers off, the automation list on the pipeline builder's Review step says so.
When a control cannot be applied
When an org control or Turn off triggers or constraints cannot be applied, the node fails before it reads or writes, and the error names the control and the reason. Common reasons are a missing permission, an item in a managed package, or a change the org does not allow.
To run without the control instead, tick Skip this control if it can't be applied on the hook action. The node then runs, and its result shows a warning that names the skipped control. A restore that fails is shown on the node's result the same way.
What the run shows
Every org control item, and every trigger or constraint a hook action turns off, has its own line on the node's result and in the run log. The line names the item's type, name and id, and what happened to it.
| Result | Meaning |
|---|---|
| Turned off, Turned on | The item was changed before the node ran. |
| Already off, left as it is | The item was already in the wanted state and was not changed. |
| Skipped | The item could not be applied and the hook action allows skipping. The line gives the reason. |
| Failed | The item could not be applied, so the node failed before it read or wrote. The line gives the reason. |
| Restored | The item is back in the state it had before the node. |
| Restore failed | The item could not be put back. The line gives the reason. |
Skipped, failed and restore failed items are shown as warnings. The others are shown as information.
For an Apex trigger, the line also gives the deployment id and how long the deployment took. The same id appears in the Deployment Status page of Salesforce Setup.
File operations
File operations act on the connection's own storage. On Amazon S3 and Azure Blob Storage, Rename applies to a single file.
Webhooks
A webhook step sends a JSON POST with the run id, the node and the phase. An error-step's body also carries the node's error message.
Execution policy
On failure says what the run does when the node fails:
| Setting | What happens |
|---|---|
| End Run (Stop) | The run stops and reports a failure. |
| Exit Immediately (Fail Fast) | The run stops and reports a failure. |
| Continue (Skip Node) | The node and the steps after it are skipped, and the run goes on. |
Salesforce Behavior
A Salesforce Target also has Salesforce Behavior, for Insert, Update, Upsert and Delete:
| Setting | What it does |
|---|---|
| Retry failed records | Sends rows Salesforce rejected again, up to the number you set (1 to 10). |
| Reprocess on lock errors | Sends rows rejected with UNABLE_TO_LOCK_ROW again, waiting longer before each attempt. |
| Lock-aware processing | Groups rows by their parent records and runs Bulk jobs one at a time. |
Each row's final result is what the node reports. Merge, Publish, Unpublish and Data Cloud ingest run without these settings.
Email deliverability is set in Salesforce Setup, on the Deliverability page. A deliverability value saved on a node before it moved there stops the run; clear it in the node's Salesforce Behavior section.