Use Salesforce permission sets to control who can configure and support Payloads.

Payloads configuration can affect external systems, Salesforce data, credentials, and inbound endpoints. Treat access as integration administration, not just access to another Salesforce tab. A user who can change a Payload may be able to change what data is sent to an external API or what records are written when an inbound request arrives.

Assign Payloads Admin to users who configure and support integrations.

Payloads Admin is intended for users who need access to the Payloads app, configuration tabs, record pages, and runtime data.

Users with this permission set may be able to create or change Payloads, Credentials, Endpoints, Transformations, Elements, Data Targets, Target Fields, Batch Engine settings, and Job Analytics records depending on the package version and object permissions.

Use this for integration admins, Salesforce admins responsible for Payloads, and developers supporting no-code integrations. These users should understand the effect of changing API requests, Credentials, response handling, and target writes.

Payloads Admin is the main permission set for users who configure and support Payloads inside Salesforce.

Assign Payloads Site Guest User to the Site Guest User for inbound endpoints.

This permission set is for unauthenticated Site requests that need to reach Payloads endpoint configuration and run the related inbound Payload.

Do not assign this permission set to normal internal users as a substitute for Payloads Admin. It exists for the Site runtime path, not for day-to-day administration.

For Site setup, see Set up inbound endpoints and Sites.

Users who configure integrations need enough access to:

Limit this access to users who understand the impact of changing API requests, response handling, and Salesforce target writes. In smaller teams, this may be the Salesforce admin. In larger teams, it may be a smaller integration-admin group.

Some users may only need to monitor runs and troubleshoot failures.

Those users need access to Home, Jobs, Integrations, Payloads, and related runtime data. If they should not change integration configuration, use your normal Salesforce permission model to keep edit access restricted.

Support users should be able to open Job records and review error messages, request data, response data, Data Query output, Data Target output, and metrics. That is the information they need to tell the difference between an external API issue, a Salesforce data issue, and a mapping issue.

Inbound endpoints run through Salesforce Sites.

The Site Guest User must be able to read the Payloads configuration needed to route and run the inbound request. This includes the Endpoint, related Payload, and related configuration used by that Payload.

Be careful with object and field access for any Salesforce records the inbound Payload reads or writes. Payloads configuration access is only one part of the full security model. The guest user should have enough access for the endpoint to work, but not broad access to unrelated business data.

After assigning permissions, check that:

Review permissions again after each package upgrade, especially when new objects, fields, tabs, or runtime features are added.