Screen Pop - Session Variable Persistence

genesyscloud-client-app-sdk’s screen pop is losing session variables after the initial Architect flow. We’re on v90.0.0 - using the Embeddable Client App SDK v2.7.0.

Architect flow: dip to a DB, sets x_custom.caseId to a value, then triggers a screen pop via a clientAppEvent. The client app receives the initial pop, but session.sessionVariables.x_custom.caseId is undefined on subsequent events - like a chat update. It’s almost like the variable isn’t persisting across interactions.

The app’s logic looks something like this:

onSessionEvent(event) {
 if (event.type === 'CHAT_UPDATED') {
 const caseId = session.sessionVariables.x_custom.caseId
 // caseId is consistently undefined here
 console.log("Case ID:", caseId)
 }
}

If it helps, we are trying to retrieve the session variables for the conversation. Wondering if there’s a setting in Architect, or something on the SDK side, we’re missing.

Client app events don’t propagate session variables directly - they’re a one-way broadcast. The Architect flow sets the variable, then the pop happens, but subsequent chat updates aren’t aware of that initial setting. You’ll need to pass x_custom.caseId as data with the chat update event itself.

Data actions can help. Configure one to pull the x_custom.caseId from the session before the chat update triggers. Then, inject it as a custom event parameter when sending the chat message to the client app - something like {"event": "chat:update", "caseId": <session.x_custom.caseId>}. That way, the client app receives the value with each message. It’s not ideal - a session variable really should persist - but it’s a workaround we’ve used for similar issues.

The session variable persistence issue appears to stem from the asynchronous nature of the client app event handling within Genesys Cloud. While the Architect flow successfully sets the x_custom.caseId variable, subsequent events - such as chat updates - do not inherently inherit this state. The previous reply correctly identifies the need to explicitly propagate the variable.

However, reliance on data actions for each chat update event may introduce performance considerations, particularly at scale. We’ve encountered similar scenarios during high-volume contact events, and the repeated data action calls can impact overall system responsiveness.

Consider leveraging the Set Session Variable activity within the Architect flow preceding the client app event. Configure a second Set Session Variable activity after the initial event, using a data action to re-populate the variable from the session. This ensures the variable is explicitly set both before and after the event trigger.

The configuration for the second activity would be as follows: activity type - Set Session Variable, variable name - x_custom.caseId, variable value - ${session.sessionVariables.x_custom.caseId}. This creates a feedback loop, confirming the variable’s value is persisted.

We’ve also implemented a workaround involving a custom data object within the session. The Architect flow initializes a temporary data object with the caseId value. This object is then referenced throughout subsequent events. The data object’s scope is the session, so it’s accessible without repeated data actions. This approach requires careful object management to avoid conflicts.

Thanks - that Data Action approach is spot on. We hit something similar last qtr - the client app wasn’t holding the session var.

Here’s how we tackled it:

1. Data Action Config: Create a Data Action. The goal? Grab x_custom.caseId from the session before the chat update event.
2. Session Variable Access: Inside the Data Action, use this expression to pull the value: {{Session.x_custom.caseId}}.
3. Event Parameter Injection: Map this to a custom event parameter - let’s call it case_id.
4. Chat Update Event Payload: Modify your chat update event to include this new parameter. Here’s an example payload:

{
 "event": "chat.update",
 "payload": {
 "message": "New message content",
 "case_id": "{{Session.x_custom.caseId}}"
 }
}

Important: Ensure your client app is configured to read case_id from the event payload.

Not 100% sure but, double-check the Data Action’s tracePropagation config - it needs to be true for this to work reliably. We saw perf issues when it wasn’t.

Anyone seen this?

clientApp.on('clientAppEvent', (event) => {
 const caseId = event.detail.caseId; 
 sessionStorage.setItem('activeCase', caseId);
 console.log('Containment ID saved: ' + caseId);
});

The data action fix in the earlier reply is one way, but it’s a bit heavy for a screen pop. Better to just bake the caseId directly into the clientAppEvent payload inside Architect. If you pass it as a custom attribute in the event, the SDK catches it immediately. It’s way better for the user experience since the screen pops with the right data instantly. No waiting for a second API call to fetch the variable.

Quick question though - is the session variable the same as a participant attribute? I always mix those up. Either way, storing it in sessionStorage on the client side usually stops the “undefined” glitch when the page refreshes. Keep it simple to keep containment high.