The admin UI’s locking the pacing multiplier at 0.8x the second screen recording gets enabled on the outbound campaign. It’s running on the 2024-11-12 release, US-East tenant, standard predictive setup. We pushed the campaign to 1.3x pacing yesterday and everything tracked fine. Abandonment held at 0.8%. Then compliance requested desktop capture for the new QA audit. Toggled screen recording on in the campaign settings. Multiplier dropped instantly. Console is throwing a TypeError: Cannot read properties of undefined (reading 'recordingSessionId') inside the pacing slider component.
Request hits /v2/outbound/campaigns/{id} and returns a 200, but the pacing value never updates past 0.8. Cleared cache, bounced the browser, spun up a fresh admin profile. Still doing jack all. The predictive dialer keeps routing, but the effective pacing stays throttled. Abandonment jumped to 4.2% within twenty minutes because the system stopped predicting properly. Compliance window closes at 11 AM EST tomorrow, so we can’t just leave recording off.
Architect flow shows the interaction starting, but the recording block never attaches a session ID. Logs show WARN: Screen recording not available for predictive queue type around the time the multiplier locks. We’ve got progressive and preview campaigns running on the same tenant with screen recording enabled and they pace normally. Only predictive is choking.
The API docs don’t mention a hard limit on concurrent screen sessions for predictive queues. Here’s the raw response from the pacing update endpoint when recording is active:
{
"campaignId": "a8f3c912-44b1-4d0e-9a2f-77c810045521",
"pacing": {
"multiplier": 0.8,
"status": "locked",
"reason": "recording_conflict"
},
"abandonmentRate": 0.042,
"timestamp": "2024-12-18T14:32:11Z"
}
The multiplier stays stuck even after disabling recording. Have to bounce the whole campaign to reset it. Losing six hours of dial time each day because of this.