Before Payloads runs in production, review access the same way you would review any integration surface in Salesforce.

Payloads can send data out of Salesforce, receive data from other systems, write Salesforce records, and store authentication configuration. That is exactly why the security model should be deliberate rather than inherited from whichever user happened to build the first Payload.

This checklist focuses on the practical checks that prevent most production issues.

Only users who build or support integrations should have Payloads admin access.

Assign Payloads Admin to builders, admins, and support users who need to create or troubleshoot Integrations, Payloads, Credentials, Endpoints, Transformations, Jobs, and Batch Engine settings.

Do not assign builder access to every business user who benefits from the integration. Most business users should interact with the Salesforce process that triggers Payloads, not with Payloads configuration itself.

Use the packaged permission set as the starting point, then grant business object access separately.

For the detailed permission article, see Set up permissions and access.

Payloads configuration access lets a user define integration behaviour.

Business data access controls which Salesforce records and fields the user or guest user can read or write. Keep those two decisions separate.

For outbound Payloads, review the objects and fields used by Data Queries. For inbound Payloads that write Salesforce data, review the objects and fields used by Data Targets. The integration should only read and write what the business process requires.

If a Payload fails because a field is not accessible, fix the specific object or field access. Do not grant broad access to make the error disappear.

Credential records control how Payloads authenticates with external systems.

Before production use, check:

Credential values should be handled as integration secrets, even when the surrounding Payload configuration is safe to share.

For credential setup, start with Credentials Overview.

Inbound Endpoints are public-facing when they are exposed through Salesforce Sites.

Before sharing an Endpoint URL externally, check:

Inbound security is a combination of Endpoint configuration, Site configuration, and guest user permissions.

For setup details, see Set up inbound endpoints and Sites and Configure Endpoints.

Inbound Payloads that write to Salesforce should be reviewed carefully.

Check each Data Target:

For target behaviour, see Configure Data Targets and Map Data Target fields.

Jobs are useful for support, but they can contain request bodies, response bodies, headers, parameters, and target data.

Set retention rules that keep enough history for troubleshooting without storing integration data longer than needed. Failed Jobs often need a longer retention window than completed Jobs because they support investigation.

For retention setup, see Configure Job retention and cleanup.

Open Billing before go-live and after each package upgrade.

Payloads needs a verified subscription state before runtime execution. If the subscription service stops or fails for any reason, Payloads will cease to operate after 7 days.

For subscription details, see Manage subscription and billing.

Before go-live, confirm: