Triggered Actions allow configuring actions that are applied to a list or library when an event occurs
(e.g., add, update, or add/update) and a condition evaluates to true.
Triggered Actions are a SharePoint Online exclusive feature.
[[FieldName.isChanged]] placeholder to execute a Triggered Action only if the field value changedTriggered Actions can be found on the “Things in Background” tab. Configure them like a rule to plan
automated executions using a set of powerful action types.
Note: Triggered Actions work only when item versioning is enabled.
Note: Triggered Actions will execute as many times as updates were made to the item.
In the History tab you can view the execution history.
The “Export history” button allows exporting the history to a .txt file.
By default, all Background Features executions (Aggregation, Metadata Inheritance, Calculated Expressions, Scheduled Actions, and Triggered Actions) do not activate triggered action execution.
There is an option “Execute triggered actions” that allows triggered actions to execute based on the current
calculated value configuration.
Note: This option is visible in the UI only if versioning is enabled.
The recommended best practice is to use “Execute triggered actions” together with a condition on field change
to reduce unnecessary executions.
For this, the [[FieldName.isChanged]] placeholders return true/false for each field.
The HTTP Request trigger type allows you to execute one or more actions when an HTTP request is sent to a specified URL.
code or in the x-trigger-key request header.When the HTTP Request trigger is configured, an HTTP Trigger action is added automatically in the Actions step.
It populates output values from the incoming HTTP request data. These outputs can be used in subsequent actions.
| Output parameter | Type | Description |
|---|---|---|
| RequestHeaders | String | Returns HTTP request headers. To get a header value from the request, use: [[@Actions.HTTP_Trigger.RequestHeaders]]["HeaderName"] |
| RequestBody | String | Returns the original request body. |
| RequestBodyJSON | JSON | Returns the request body in JSON format. |
| RequestFiles | String | Returns an array of file objects included in the request. Properties:
[[@Actions.HTTP_Trigger.RequestFiles]][0].Path[[@Actions.HTTP_Trigger.RequestFiles]][0].Name[[@Actions.HTTP_Trigger.RequestFiles]][0].Size NOTE: If multiple files have the same name, the system ensures unique names when processing them (e.g., document(1).pdf). The unique names are returned in the HTTP Trigger output. |
If your HTTP request includes files, use the Store File action to retrieve and process the files received.
To configure an HTTP request from an external system, refer to the relevant article that provides step-by-step instructions.
Complex background feature configurations can create loops, especially when the “Execute triggered actions” option is enabled for some calculated values.
To address this, a loop detection functionality runs whenever the configuration is saved. You are prevented from saving if a loop is detected, and you are given information about the loop source.
Once there is no loop threat anymore, the configuration can be saved.
If a Triggered Action throws an error continuously (e.g., the list is deleted), the Triggered Action will be deactivated.
To reactivate it, click “Reactivate execution” in the Deployment Maintenance tab
for the selected deployment.
To open History logs, click on your Triggered Action (e.g., “create onboarding tasks”).
If the Triggered Action uses the HTTP Request trigger type, the URL and API key required to trigger it
can be found in the Publish tab under Deployment Maintenance.
NOTE: Further updates to a Triggered Action (except changing its title) will not change the URL and API key parameters on the target site.