Flow Outcome Metrics Not Populating in Analytics Views After SSO Provider Migration

Architect & Flows
1

We just migrated our SSO identity provider from Okta to Azure AD. The SAML configuration is working - agents can log in, make calls, everything functions normally. But since the migration, our Analytics > Flow Outcome views are completely empty. Zero data.

The weird part is that other analytics views work fine. Queue performance, agent status, conversation details - all populated. It is specifically the Flow Outcome metrics that stopped reporting.

I checked the Architect flows and the Outcome nodes are still configured correctly. The flow execution logs show the outcomes being hit during live calls. The data just is not making it to the analytics pipeline.

Timeline:

  • May 10: Disabled Okta SSO, enabled Azure AD SSO
  • May 10: Flow outcome data stops appearing in analytics
  • May 12: Opened support ticket, no response yet
  • May 14: Still no data

The only change was the SSO provider. No flow modifications, no admin config changes, no API key rotations. We are on US-East-1.

Anyone seen analytics data gaps correlated with an SSO migration? This makes no sense to me.

2

This is a coincidence in timing, not a causal relationship with the SSO migration. SSO authentication has no connection to the analytics data pipeline.

The real cause is almost certainly a Flow Outcome configuration issue that happened to occur around the same time. Check the following:

  1. Go to Admin > Architect > Flow Outcomes and verify each outcome is still in the “Active” state. There was a platform update around May 9th that reset some flow outcomes to “Inactive” status in certain orgs. Inactive outcomes still execute in the flow (the Outcome node fires), but the analytics pipeline ignores inactive outcome events.

  2. Verify the outcome IDs in your Architect flows match the outcome IDs in the admin panel. If someone accidentally deleted and recreated an outcome with the same name, the flow would still reference the old (now deleted) outcome ID. The flow would not show an error because the Outcome node gracefully handles missing outcome IDs at runtime.

To confirm, run this API call:

GET /api/v2/flows/outcomes?sortBy=name&sortOrder=asc

Compare the returned outcome IDs against the IDs referenced in your Architect flow JSON export.

3

Confirming the diagnosis above. We had the exact same symptom on May 11th in our org, also US-East-1. No SSO change on our side, which rules out SSO as the cause.

The platform update on May 9th included a schema migration on the flow outcomes table. Any outcome that had a description field longer than 256 characters was truncated during the migration, and a bug in the migration script set those outcomes to inactive as a side effect.

Genesys published a fix on May 12th that automatically re-activated the affected outcomes, but only for orgs that had not manually edited any outcome after the migration. If you viewed or edited any outcome in the admin UI between May 9-12, the fix would not have applied to your org.

The manual fix is:

# For each affected outcome
curl -X PUT \
  "https://api.mypurecloud.com/api/v2/flows/outcomes/{outcomeId}" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d '{"name": "OutcomeName", "isActive": true}'

After re-activating, analytics data should start flowing again within 15 minutes. Historical data for the gap period is unfortunately lost - the analytics pipeline does not retroactively index events from inactive outcomes.