Custom widget pushes skill_level via Guest API, but Predictive Routing queue drops the message. The webmessaging-sdk version’s 1.2.4. Queue config expects the attribute, yet the score stays null.
Run that through k6 first. The webmessaging-sdk strips unknown keys before the platform API ever sees them. You’ll need to map the custom attribute in the queue’s routing config instead of just dumping it in the widget payload. Verify your token actually grants messaging:write and routing:queue:view. If the score stays null, the PR engine simply isn’t finding a matching attribute rule. Check the queue settings under Predictive Routing → Attributes. Make sure the data type matches exactly. String versus number mismatches kill the score instantly. Add a console log to the widget too. Debug the payload at the edge.
The Guest API route usually bottlenecks the attribute mapping. Try routing the skill_level through the real-time transcription stream instead. The knowledge surfacing engine picks up those metadata tags way faster, which actually improves the AI ROI when agents get the right context before the handoff. You’ll want to inject it directly in the transcription payload template under the customAttributes node.
Does the Predictive Routing queue actually read from the transcription buffer, or is that just for the Agent Assist widget? Sometimes the WFM skill sync gets mixed up with the transcription metadata, and the queue still drops it if the attribute name doesn’t match the exact WEM profile field. Worth checking the mapping table. The attribute usually drops right after the stream init.
Is the attribute actually persisting on the conversation object or just the participant? Predictive routing scores usually pull from the conversation metadata. The guest participant profile often gets ignored by the scoring engine.
Try pushing the attribute directly on the conversation level. The bot framework handles presence sync by updating the user object, but routing engines often skip participant-specific tags unless explicitly mapped.
Doesn’t the queue config reference conversation.attributes? Check the routing profile. Sometimes the SDK drops custom keys if the schema isn’t extended. Schema validation fails hard on unregistered keys.
Make sure the attribute exists in the schema definition. If it’s missing, the API rejects it silently in some SDK versions. The v1.2.4 client might be stripping non-standard fields during the serialization step. Verify the raw request body leaving the client. You’ll see the key missing if the schema filter catches it.
Maybe the DTO needs explicit null handling instead of flipping mapper flags. CXone webhooks often drop optional keys entirely. The serialization logic in this SDK version is strict about type enforcement. Bidirectional status mapping requires the attribute to be defined in both the bot schema and the routing profile. Graph API presence updates don’t trigger routing events. The score calculation runs asynchronously, so a delay of a few seconds is normal. If the score stays null after the update, the attribute isn’t reaching the scoring engine. Check the attribute source in the routing profile.
400 Bad Request: Missing required attribute ‘skill_level’ in scoring engine evaluation.
Are you actually passing the view:conversation scope in your pre-request script before that Guest API call fires? the earlier post’s PATCH suggestion is the only way to force the attribute onto the conversation object itself. The Guest API endpoint just spits out a participant profile that the predictive routing scorer ignores completely unless you bind it to the interaction metadata. Run this Newman collection step to verify the payload sticks.
Make sure you’re not caching the access token across environments, or you’ll hit a 401 when the token expires mid-run. Also, check your environment variables. Newman defaults to the first match, which usually breaks when you switch between sandbox and production.