Call Logging and Retry Worker Guide

Overview

The Retry Worker is a dedicated server that caches and re-attempts calls that fail to log in the client’s CRM. Typically, the cause for failure is within the CRM environment. When attempts are made to re-log by, they are assigned to the user who made the call, but the activity is created by the API user.

Description

The retry worker runs every minute and selects records that have failed within the exponential backoff interval from that time. Initially, it will log as a “generic” call, and then on the second pass, it will log fully with the details. It will re-attempt to log each failed call 10 times, increasing the amount of time between each subsequent attempt. Additionally, it attempts to log as the user before logging as the integration account, so some calls that fail will still log the “Created By” as the original user.

Here is the order of operations for calls logging and fields updating for an OUTBOUND call:

1. Agent clicks Dial.
2. Blank “DialSource Automated Call” task is inserted on parent record.
3. User completes call and clicks Disposition.
4. Blank Task is updated to reflect call information and Disposition.
5. “Last Disposition,” “Datetime of Last Disposition,” “Total Call Count,” and “Last Call Campaign Name” fields on parent record are updated by a Task trigger installed as part of the managed package.

Here is the order of operations for calls logging and fields updating for an INBOUND call:

1. Agent accepts the Inbound offer.
   • 1a. If applicable, Agent links Inbound call to the appropriate record.
2. Blank “DialSource Inbound Call” task is inserted on parent record.
   • 2a. If the call was not linked, the subject will be “DialSource Unlinked Inbound Call” and will not have a related record until the Agent links the call.
3. User completes call and clicks Disposition.
4. Blank Task is updated to reflect call information and Disposition.
5. “Last Disposition,” “Datetime of Last Disposition,” “Total Call Count,” and “Last Call Campaign Name” fields on parent record are updated by a Task trigger installed as part of the managed package.

Troubleshooting

Calls can fail to log at Step 2 or Step 4. If the call fails at Step 2, the retry worker will need to run twice - once to insert the original Task, then again to update the Task to reflect the call information. If the logging fails at Step 4, the retry worker will only need to log the updates to the Task.

The call logging under the retry worker will cause the fields to update and any subsequent automation to fire when the call is successfully logged. Since the call is logged under the API User’s credentials, any automation running based on the “last modified by” field may experience disruption. For instance, it may send out emails or assign follow-up Tasks to the API User instead of the user who made the call. If this occurs frequently, please contact the Support team to determine the reason for the errors. Submitting a bug report via the Report Issue button immediately after a call fails to log will enable the bug report to capture any CRM errors that were generated.

If the issue is local to your CRM instance, Support will be able to advise on what changes need to be made.   Our internal call failure lookup has been updated for the new task worker as of October 7, 2024. It will now show the status of all records queried, not just failed records. It will also show the entire retry history for a call so we will be able to see each failed logging attempt and the error.

Here are some common causes of calls failing to log:

• Expired CRM session 
• Field level access on the Task object.
• Org runs out of API calls relative to the 24-hour rolling limit.

You can also contract our Professional Services team to optimize your automation.