docs: document sandbox mode and skip delays for the workflow test runner

content/send-notifications/testing-workflows.mdx

@@ -20,6 +20,15 @@ Two things to know about workflow test configuration:
 
 After clicking "Run test," you will see a confirmation and a link to see the log to review the output and what was sent. You can learn more about Knock logs and the debugger [here](/send-notifications/debugging-workflows).
 
+### Test run settings
+
+The test runner includes a few settings that control how the workflow executes during a test run:
+
+- **Sandbox mode.** When enabled, all messages sent from the workflow are forced to send in [sandbox mode](/integrations/overview#sandbox-mode). Knock generates and previews the messages without delivering them to the underlying providers, regardless of how sandbox mode is configured on each channel. This is useful for testing a workflow end-to-end without sending real notifications to your recipients.
+- **Skip delays.** When enabled, all [delay steps](/designing-workflows/delay-function) in the workflow are force skipped. The workflow runs straight through without waiting, which lets you verify the full execution path without waiting for delays to elapse.
+
+You can also apply both of these settings when [triggering a workflow via the API](/send-notifications/triggering-workflows/api#controlling-trigger-behavior-with-settings) using the `settings.sandbox_mode` and `settings.skip_delay` properties, which is useful when testing workflows programmatically.
+
 Note that [trigger frequency](/send-notifications/triggering-workflows/overview#controlling-workflow-trigger-frequency) is not enforced during test runs. Settings like "once per recipient" are bypassed — each time you run a test, the workflow will execute for the selected recipient regardless of your frequency setting. To validate trigger frequency as it behaves in production, use the [trigger API](/send-notifications/triggering-workflows/api).
 
 You can also use the workflow test runner to run a test payload for a [source event trigger](/integrations/sources/overview#workflow-triggers). If your workflow is triggered by an event, you will automatically see a JSON payload of the last received event that you can use to run a test. You can edit this payload or click "Fetch the latest event" to get the most recent from your source.

content/send-notifications/triggering-workflows/api.mdx

@@ -24,6 +24,7 @@ Learn more about triggering workflows in [our API reference](/api-reference/work
 | data             | map                   | A map of properties that are required in the templates in this workflow                                     |
 | cancellation_key | string                | A unique identifier to reference the workflow when canceling                                                |
 | tenant           | string                | An optional identifier of the owning tenant object for the notifications generated during this workflow run |
+| settings         | map                   | An optional map of settings that control how this workflow run is executed                                  |
 
 ## Recipient identifiers
 
@@ -207,6 +208,28 @@ tenants to which they belong in your product.
 
 You can read more about [supporting multi-tenancy in our documentation](/concepts/tenants).
 
+## Controlling trigger behavior with settings
+
+You can pass an optional `settings` object in your `trigger` call to control how the workflow run is executed. These settings are useful when testing a workflow, and mirror the options available in the [workflow test runner](/send-notifications/testing-workflows#test-run-settings).
+
+| Property     | Type    | Description                                                                                                  |
+| ------------ | ------- | ------------------------------------------------------------------------------------------------------------ |
+| sandbox_mode | boolean | When `true`, all messages in the workflow run are forced to send in [sandbox mode](/integrations/overview#sandbox-mode), overriding the per-channel configuration. Messages are generated but not delivered to the underlying providers. Defaults to `false`. |
+| skip_delay   | boolean | When `true`, all [delay steps](/designing-workflows/delay-function) in the workflow are force skipped, so the run executes straight through without waiting. Defaults to `false`. |
+
+```json title="Example trigger with settings"
+{
+  "recipients": ["user-1"],
+  "data": {
+    "message": "Life finds a way"
+  },
+  "settings": {
+    "sandbox_mode": true,
+    "skip_delay": true
+  }
+}
+```
+
 ## Frequently asked questions
 
 <AccordionGroup>