Process Subscription Lifecycle Actions Asynchronously for High-Volume Suspend and Close Operations
Starting in Update 26C, Subscription Management supports asynchronous processing for high-volume lifecycle operations that meet the async threshold criteria. The following actions can now be processed asynchronously:
- Suspend action at the product level
- Close action at the product level
- Close action at the subscription level
When an action qualifies for asynchronous processing, the behavior is aligned with existing asynchronous lifecycle actions. In the UI, users see an additional confirmation dialog informing them that the action will be processed asynchronously. After submission, a confirmation message displays the ESS Job ID.
For REST requests, the response includes a message confirming that the async job was submitted, along with the corresponding ESS process ID. See examples below.
{"result": "The Process Subscription Lifecycle Operations process was submitted with process ID 331583 for the Suspend Product action."}
{"result": "The Process Subscription Lifecycle Operations process was submitted with process ID 450645 for the Close Line action."}
{"result": "The Process Subscription Lifecycle Operations process was submitted with process ID 450666 for the Close Subscription action."}
In addition, starting in 26C, validation failures for Suspend and Resume REST requests now return an HTTP 400 Bad Request status code with the appropriate validation error message. Prior to 26C, these validation failures returned HTTP 200 Success, sometimes with only a generic FAILED message.
- Improves performance and reliability for large-volume suspend and close operations by processing eligible requests asynchronously.
- Reduces the risk of timeout issues for high-volume subscription lifecycle actions.
- Provides better traceability by returning the ESS Job ID for both UI and REST-based submissions.
- Delivers consistent behavior across subscription lifecycle actions that support async processing.
- Improves REST API standards compliance by returning HTTP 400 Bad Request for validation failures instead of HTTP 200 Success.
Steps to enable and configure
You don't need to do anything to enable this feature.
Tips and considerations
- Async processing applies only when the action meets the configured async threshold criteria.
- Users should monitor the submitted ESS job to confirm completion of the suspend or close action.
- REST integrations should be updated to handle async submission responses and capture the ESS process ID.
- REST integrations for Suspend and Resume should now handle HTTP 400 responses for validation failures.
- Do not assume that an async action is completed when the REST response is received; the response confirms job submission only.
- Review any existing integrations that currently treat HTTP 200 responses with error payloads as validation failures.