Version 1.53 converts legacy Payload configuration into ordered Actions during post-install processing. Existing configuration records and mappings are preserved while Actions provide the new sequence and editor experience.

After installing the package, open Apex Jobs in Salesforce Setup and inspect the post-install migration work and any failures. Then open representative Payloads from each Integration.

Confirm that each opens in the Actions workspace and that its Queries, HTTP Request and HTTP Response, Targets or Email processing appear in the expected order. Review credentials, mappings, Dynamic Inputs and Endpoint behaviour before testing.

The migration processes groups of legacy Payloads. A failure can roll back one group while other groups complete successfully. Do not infer that every Payload migrated merely because some show the new UI.

Compare the upgraded configuration with the previous behaviour, then run controlled tests through the actual entry points: manual, Flow, inbound endpoint or Email Service as applicable.

Check request and response content, queried records, Target writes and authentication refresh. Inspect the new Job timeline and verify effects in Salesforce and the test destination.

Legacy type names can remain in stored metadata. The current UI groups old full-callout and webhook patterns under Outbound, and old API push and pull patterns under Inbound.

Capture the package version, affected Payload names or API names, migration Apex Job details and the error. Contact Payloads support with that evidence before making manual changes to the execution model or internal Action records.

Conversion is designed to be repeatable without duplicating already migrated work. Ask support to confirm the recovery procedure for the installed version. Do not invoke an internal migration class or set execution fields merely to make the new UI appear.

An imported legacy configuration is converted as part of its import transaction. A failed conversion can therefore prevent that import from completing.

Create a small CSV Import Payload as part of the upgrade checks. If saving it fails with INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST and CSV Import, inspect the Action object’s Type picklist and capture the package version and error for support. The required Action cannot be created if that value is missing from the installed picklist.

The same check applies if starting an asynchronous run reports that Queued is invalid for Job Status. These missing values were observed in the upgraded documentation demo org. Restoring the released values resolved those metadata errors there; it is not evidence that every upgraded org needs the same repair.

New executions save Action-level evidence. Older Jobs may have saved request, response, query and Target data without an Action snapshot.

The Job UI can reconstruct a view labelled Recorded from that saved data. This makes historical values readable, but it does not establish genuine per-Action timing, status or the original sequence from that earlier run. Do not use a reconstructed timeline as proof of those details.

This historical demo Job illustrates the compatibility view. It is not a fresh runtime verification.

See Navigate the Actions workspace and Install, upgrade and migrate Payloads.