Okay, so we’re seeing something really weird with the custom agent desktop we’re building. Sorry if this is a basic newbie question, I still get confused between “screen pop” and “client app integration” terminology sometimes, but the pop just isn’t happening for some agents. It works fine for most, but then a specific interaction comes through and the UI just sits there doing jack all.
The agent is logged in, the station is active, and we’ve checked the permissions. We’re using the Embeddable Framework and the Client App SDK to handle the event. I tried calling GET /api/v2/stations to make sure the WebRTC user ID is mapping correctly, but that doesn’t seem to be the issue. The console isn’t throwing a hard crash, but we’re seeing this in the logs when the interaction hits the agent:
{
"error": "Interaction not found or access denied",
"code": "NotAuthorized",
"details": "The requested resource is not available for the current session context"
}
We’ve tried refreshing the iframe and re-initializing the SDK, but it’s hit or miss. The interaction shows up in the agent’s queue, they answer it, but the custom page won’t load.
could be a race condition with the iframe loading. we saw this on zoom contact center - inc-4471 was the ticket. the sdk event fires before the dom is actually ready for the pop. try wrapping the logic in a waiter:
await page.waitForSelector('iframe[name="client-app"]');
const frame = page.frameLocator('iframe[name="client-app"]');
await frame.locator('.pop-container').waitFor();
2 Likes
// Check if the integration is actually enabled for the specific user
const checkIntegrations = async () => {
const response = await platformClient.integrations.listClientApps();
const hasPopApp = response.data.some(app => app.name === 'CustomDesktopPop');
console.log('Integration enabled:', hasPopApp);
};
The race condition mentioned in the earlier reply is common, but it’s often a permission mismatch. If the pop only fails for some agents, it’s likely the client app isn’t permitted for those specific users. You can check this via /api/v2/integrations/clientapps to see what’s actually active for the logged-in session.
Small thing: if you’re using a bot flow for the handoff, check the slot filling for the customer_id. If the bot doesn’t fill the required slot before the transfer, the screen pop might not have the data it needs to trigger the UI change. I’ve seen this in other community posts where the interaction arrives but the pop stays blank because the variable is null.
Client App SDK handles the event stream asynchronously, which means the interactionId might be available in the event payload before the actual session handshake is fully established between the browser and the platform. If the pop works for some agents but not others, it’s likely not a global config issue but rather a timing gap or a permission scope problem. There’s a theoretical limit on how quickly the SDK can resolve the conversationId against the active user session. If the agent’s local cache is stale or the network latency on their specific workstation is high, the onConversationStarted event might fire, but the UI fails to map that ID to a valid screen pop URL.
Client App SDK logic should be validated against the actual permitted apps for that user. If the agent isn’t explicitly allowed to use the integration, the event won’t trigger the pop. To verify this, you can hit the /api/v2/integrations/clientapps endpoint for the affected users.
If the permissions are correct, try implementing a retry mechanism for the pop. Instead of a one-time fire, use a small buffer:
let popAttempts = 0;
const maxAttempts = 3;
function attemptPop(data) {
if (popAttempts < maxAttempts) {
const success = window.open(data.url, '_blank');
if (success) {
console.log('Pop successful');
} else {
popAttempts++;
setTimeout(() => attemptPop(data), 500);
}
}
}
One gotcha is that some browsers block the window.open call if it isn’t triggered by a direct user gesture, which can vary based on the agent’s browser security settings.
1 Like
Cause:
The permission mismatch mentioned in the earlier reply is a huge culprit. If the CLIENT APP isn’t assigned to the right ROLE, the pop just won’t trigger for those users.
Solution:
Check the permissions for the affected agents. You can use this endpoint to see what’s actually permitted for them:
GET /api/v2/integrations/clientapps
1 Like