Good morning, Conquer Voice users. Today between 8-8:10am Pacific Time, Conquer Voice experienced a brief disruption in logging calls to Salesforce. Our development team has already resolved the issue and all calls from that time period have been queued through our normal re-logging process. Any users who are still on a session that was active during the disruption may continue to see some logging delays. As a result, we advise all users who are on an active dialing session to disconnect their Leg A, refresh their SFDC page, and reconnect to ensure continued accurate logging.
This item applies to Salesforce clients only, Microsoft Dynamics clients were not impacted.
UPDATE 9am Pacific Time: Conquer Development has identified some trailing affects that may still be impacting some users. They are investigating and working to resolve these now. The issue remains specific to Salesforce clients.
UPDATE 9:15am Pacific Time: Conquer Development has resolved all trailing effects and confirmed that new calls are now logging. They recommend users repeat the earlier advised steps to disconnect from the system, refresh their SFDC page, and reconnect. All calls that did not initially log are queued to re-log via our standard retry process. An RCA will be provided once it is complete.
Root Cause Analysis:
At 7:55am Pacific Time, a batch of servers went through a routine restart process, as is standard procedure on a scheduled and as-needed basis. The restart process is typically transparent to agents and regular load balancing amongst the cluster handles all active connections. The restart completed successfully, however, upon restart, the severs were configured for a future release due to human error, which caused issues with immediate call logging through the standard process and calls began to go to the retry worker (again, standard failsafe mechanism). This scenario was quickly and correctly identified by the Conquer Development team and a reboot with the correct configuration was attempted at 8:10am PT. At 8:49am Pacific Time, some calls were still failing to log on initial attempt and an additional reboot was required to allow proper load balancing and the return call logging to the intended, immediate process. This was completed at 9:05am Pacific Time, at which time it was confirmed that logging returned to the normal process.
Please sign in to leave a comment.