Run a Payload manually
Manual runs are the quickest way to test a Payload while you are building it.
Open the Payload, run it from the record page, then review the Job that Payloads creates. The Job shows the values Payloads used at runtime, the request it sent, the response it received, and any Salesforce records it attempted to create or update.
For a deeper guide to the Job record itself, see Understand Job records.
When to use a manual run
Use a manual run when you want to:
test an Outbound Payload before putting it into Flow
test an Outbound webhook-style Payload with realistic runtime inputs
test an Inbound Payload that returns Salesforce data by supplying endpoint, header, and parameter values
replay a failed or suspicious Job after changing configuration
confirm a Credential Payload refresh flow in a controlled way
For Inbound Payloads that write Salesforce data and Email Handler Payloads, test through the route that will call them in production. That gives you a better Job because it captures the real inbound request or email.
Before you start
Check the Payload configuration before running it.
The Endpoint, Method, content types, Credential, and Timeout should match the system you are testing.
Required Dynamic Inputs should have clear names.
Data Queries should be limited to the records the Payload needs.
Body, Header, Parameter, Modifier, and Data Target mappings should be complete enough for the run you are testing.
Use demo-safe values. Do not run a Payload against a production endpoint unless the external system is expecting the request.
Run the Payload
Open the Payload record and select Run Payload.
Payloads opens a runner modal. The fields shown depend on the Payload type.
Outbound, outbound webhook-style, and Credential Payloads show the configured Endpoint, Method, Timeout, and any Dynamic Inputs.
Inbound Payloads that return Salesforce data show the Endpoint selection, Parameters, and Headers so you can simulate the inbound request.
Enter the values the Payload needs for this test, then select Run Payload in the modal.
The runner modal lets you supply the runtime values that would usually come from Flow, Apex, a button, or another process.
What happens after the run
Payloads runs the Payload immediately from the UI.
If the run creates a Job, Payloads opens that Job record. The Job status tells you whether the run completed or failed. The rest of the Job shows the runtime evidence: inputs, query output, outbound request data, inbound response data, target results, response status, error message, and metrics.
After a manual run, the Job is the source of truth for what Payloads actually did.
Replay from a Job
You can also start from a Job and select Replay Job.
For most Payload types, Payloads opens the runner modal with values from the existing Job already populated. This is useful when you want to adjust configuration and run the same scenario again.
For Email Handler Jobs, replay reprocesses the captured email content so you can test target mapping without waiting for another email.
What to check
After the run, check the Job in this order:
Confirm the Payload, Status, Firing Mode, Endpoint, Response Status Code, and Response Status.
Check Dynamic Inputs if the Payload used runtime values.
Check Data Query output before changing field mappings.
Check the outbound Body, Headers, Parameters, and Modifiers before blaming the external API.
Check the inbound Body, Headers, and Data Target results before changing response mapping.
Open Metrics if the run was slow or close to Salesforce limits.
If the Job failed, use Troubleshoot failed Jobs.