Retry Support
Declarative Webhooks supports two types of retries: manual retry and automatic retry.
Manual retry
If your call failed (or even if it succeeded) you have the option to retry the call manually. To do that, go to the Call Logs tab in the Declarative Webhooks app, find the Call Log that you want to retry, open it, and click on Retry this Call.
Manual retry for outbound calls
If you are retrying an outbound call, you are asked to decide how to retry.
You are presented with 2 options:
- Make the call using the URL, Headers and Request Body from the Log. If you choose this option, the URL, Headers and Request Body that are stored in the Call Log are going to be used again to make the call. If the data in the record that was initially used has changed, those changes will not be reflected in the retry callout. You can only use this option if the log was not truncated. The log can be truncated if the data stored in it (URL, Headers or Request Body) were too large for the fields at the moment of log creation.
- Rebuild the URL, Headers and Request Body from the main record, then make the call. If you choose this option, the retry logic will create the URL, Header and Request Body again, using the template and the main record(s) that were used initially. This option is not available if any of the conditions below are not met:
- The template does not exist anymore or is inactive
- The template is a Batch template
- The main record does not exist
After clicking Continue, you can preview and edit the callout URL, Method, Header values and Request Body.
Clicking Make Callout will make the call and you can view the results of the call. A new Call Log is generated.
The Call Log created when you use the Retry this Call functionality will have the Initial Log lookup field populated with the log record that you used to initiate the retry.
Manual retry for inbound calls
For inbound calls, the Retry button allows you to rerun the inbound call template actions using the logged URL, headers, and request body.
Before executing the actions, you’ll be presented with a preview of the URL parameters, headers, and request body for review.
After clicking Run Inbound Call Actions, you’ll see the generated response body along with the results of the actions.
Automatic Retry
The automatic retry functionality is available for outbound calls made automatically (from a Process Builder, a Record-Triggered Flow or through Scheduled Callouts).
Callouts made manually (from the Callout Test Page, Buttons implemented on the record or visual flows) do not support automatic retries.
To setup a callout template for automatic retries, go to the desired callout template and you can find the Retry input lower right.
Here, you can choose how many times to retry the callout (up to 5 times) and at what interval between them. You can choose from as low as 5 minutes up to 1 day.
If the callout template has retry functionality set up, when a call is made using this template from a Process Builder, a Record-Triggered Flow or through Scheduled Callouts, the app will automatically schedule the next retry after the period of time that you chose. If the retry fails, the app will schedule the next one and so on, until the number of retries you selected is reached.
Monitoring automatic retries
In the Administration page, the Retry Jobs tab will show you what Retries are currently scheduled to run and at what time.
Additionally, in the Callout Retries tab, you can find a log of all automatic retries, even the ones that executed in the past. You can check the status of a retry and if an error occurred during the attempt. You can also see the log that was generated by this retry, and the Initial log that failed and started this retry.
If you open the Call Log that failed and generated retries, you will find a related list of all the retries that the call has started.
The Call Log created automatically will have the “Initial Log” lookup field populated with the log record that you used to initiate the retry.
Backup mode
Salesforce has a limit of 100 Scheduled Jobs in production orgs, and in case the number of existing Scheduled Jobs is close to this limit, the app will NOT schedule a retry using scheduled jobs, so it doesn’t hit the limit.
However, a Callout Retry record is going to be generated and the backup retry scheduled job will pick it up and the retry is still going to be attempted, but it will be delayed by up to one hour.
The Callout Retries that are passed their scheduled time and they are going to be picked up by the backup job will be displayed in the Retry Jobs subtab in the Administration page with red.
