Payloads configuration describes what should happen. Runtime is what happens when a user, Flow, Endpoint, email, or batch process actually runs that configuration.

This article explains the main runtime choices: where a run can start, which firing mode to use, what gets written to the Job, and what limits you should check when a Payload is slow or failing.

For the Job record itself, see Understand Job records.

Payloads can run from several places.

The starting point matters because it decides what data Payloads receives at runtime. A Flow usually supplies Dynamic Inputs. An inbound Endpoint supplies request body, headers, and parameters. An Email Handler supplies email content. Batch Engine starts from a queued Job.

Manual runs are useful because they expose the runtime values that other automation would normally provide.

Every meaningful run should leave a Job trail.

The Job is where you inspect:

Do not troubleshoot from configuration alone. If a value looks right on the Payload but wrong in production, the Job shows what Payloads actually used during that run.

Use Immediate when Payloads should run now and the caller needs the result straight away.

Immediate runs execute in the current transaction. If the Payload completes, Payloads writes a completed Job. If the Payload fails before the Job is saved, Payloads attempts to write a failed Job with the error message.

Immediate is a good fit for manual testing and many screen Flow patterns.

Do not use Immediate on the synchronous path of a record-triggered Flow. Salesforce does not allow callouts from that path. If a record-triggered Flow needs an immediate Payload run, place the action on an asynchronous path.

Use Immediate (No Commit) only when you are deliberately chaining work and want Payloads to stage its writes until a later step flushes staged work.

Treat it like Immediate for transaction planning. It still runs in the current execution path, so the same record-triggered Flow callout restriction applies.

Most users should start with Immediate, Queueable Job, or Batch Engine before choosing Immediate No Commit.

Use Queueable Job when the calling process should hand off the work and continue.

Queueable execution is useful when the user or Flow does not need the external response inside the current transaction. Payloads queues Apex work, then the queued process runs the Payload and writes the final Job.

This is usually a better fit than Immediate when the calling transaction is already doing a lot of Salesforce work, or when you want to avoid keeping a screen or automation path waiting on an external API.

Use Batch Engine when work should be queued as Jobs and processed by Payloads' Batch Engine.

Batch Engine runs are created as New Jobs with a Batch Size. The Batch Engine then picks up those Jobs and processes them in controlled batches.

Batch Size must be between 1 and 2000. Smaller batches reduce pressure on Salesforce limits and can make failures easier to isolate. Larger batches can process backlogs faster when the Payload is lightweight and the external system can handle the traffic.

For setup and monitoring, see Configure the Batch Engine.

Batch Engine is for controlled queue processing, not for making every integration faster by default.

Inbound Payloads run when Salesforce receives a request through an Endpoint or an email through Email Services.

For Endpoint-based inbound Payloads, Payloads receives the URL route, HTTP method, body, headers, and parameters. It uses the Endpoint to find the Payload, then records the inbound data on the Job.

For Email Handler Payloads, Payloads receives email content from Salesforce Email Services and maps that content into the Payload's inbound model.

If an inbound run does not create a Job, check routing and access first: Site status, Endpoint URL, method, and Site Guest User permissions. If a Job is created and fails, troubleshoot from the Job data.

Payloads checks the org subscription before runtime work.

If the subscription state is not verified, Payloads blocks runtime execution and asks the user to open the Billing tab. Subscription limits can also block new Payload or Transformation configuration when the current plan does not allow it.

If the subscription service stops or fails for any reason, Payloads will cease to operate after 7 days. Treat subscription warnings as production issues, not cosmetic messages.

For more detail, see Manage subscription and billing.

The Payload Timeout controls how long Payloads waits for an outbound callout.

Set the timeout to match the external API's expected behaviour. A short timeout catches problems quickly but may fail legitimate long-running API calls. A long timeout can keep Salesforce work open for longer than needed.

External systems also have their own limits. If an API rate-limits you, rejects large requests, or takes too long to respond, the Job will usually show the response status, response body, or timeout error. Use that evidence before changing Payload mappings.

Payloads runs inside Salesforce, so Apex limits still matter.

Check Metrics when a run is slow, close to a limit, or processing a large number of records. Metrics can show whether time was spent in callouts, Data Queries, DML, CPU, heap, or row processing.

Metrics help you separate external API latency from Salesforce query, DML, CPU, and heap cost.

If a Payload is close to Salesforce limits, reduce the amount of work per run. Common fixes are tighter Data Query filters, smaller source arrays, smaller Batch Size, fewer Data Target writes, or simpler transformations.

Use Immediate for manual testing and screen-led processes that need a result immediately.

Use Queueable Job when the caller can hand off the work.

Use Batch Engine when you need controlled processing of a backlog or repeated queue.

Use inbound Endpoints when an external system starts the process.

Use Email Handler Payloads when Salesforce Email Services is the source.

When in doubt, start with the simplest runtime path that produces a clear Job, then move to async or batch execution when the process needs it.