Most agents don't have a second monitor for a contact-center dashboard. They live in Salesforce — that's where the case, the customer and the next action are. So if your real-time Genesys KPIs only exist in a separate wallboard, they're invisible to the people who could act on them. The fix is to bring the KPI to where work happens.
What "KPIs in Salesforce" actually means
It's worth separating three distinct needs, because they have different designs:
| Need | Audience | Example |
|---|---|---|
| Agent context | The agent on a record | "Your AHT today, your adherence, queue depth on your skill" |
| Supervisor view | Team lead in CRM | "Team service level, longest wait, agents in aux" |
| Operational record | The org | KPI snapshots written to objects for reporting/automation |
Lumping these together is why so many CRM integrations feel bolted-on. Designed separately, each becomes clean.
The trap: a second source of truth
The tempting shortcut is to have Salesforce poll Genesys (or a middle service) and compute its own numbers. Now you have two definitions of "service level" — the contact-center one and the CRM one — and they will disagree, usually in a meeting. You also load the Genesys API with yet another consumer (see rate limits).
The discipline: compute the KPI once, deliver it to Salesforce as a consumer. The CRM displays and acts on the number; it doesn't re-derive it.
A clean pattern
- Compute once, upstream. The reactive engine derives each KPI from the Genesys event stream — one definition, shared by every consumer.
- Push to Salesforce, don't make Salesforce pull. Deliver computed KPIs via the Salesforce connector — Platform Events for live UI signals, records/Custom Metadata for values that drive automation and reporting.
- Render where work happens. Lightning components or record-page widgets show the agent their relevant numbers, and supervisors their team view — fed by the same upstream KPI.
- Drive automation, not just display. Because KPIs land as data, you can trigger flows (e.g. surface a coaching nudge when adherence dips) without a human watching a wallboard.
This is the heart of the CRM & CX connectors: the CRM is a first-class consumer of real-time KPIs, never a competing source.
Watch-outs
- Salesforce limits too. Platform Events and API calls have governor limits — another reason to push computed KPIs at a sensible cadence rather than streaming raw event firehoses into the CRM.
- Right metric, right audience. Don't show an agent the whole org's dashboard; show them what changes their next action.
- Consistency over cleverness. The number in Salesforce must match the number on the wallboard and in Power BI. One definition makes that automatic.
Why it matters
Visibility only creates value when it reaches someone who can act. Putting real-time Genesys KPIs on the agent's record turns a passive metric into a behavioral nudge — and gives supervisors a team view without alt-tabbing away from where they coach.
FAQ
Platform Events or records? Use Platform Events for live, transient UI signals; write to records/Custom Metadata for values that must persist, report or trigger automation. Often you use both.
Won't this hammer Salesforce limits? Not if you push computed KPIs at a controlled cadence instead of streaming raw events. Compute-once upstream keeps both Genesys and Salesforce within budget.
Can supervisors get a team rollup in Salesforce? Yes — the same upstream KPI can be aggregated to a team scope and surfaced on a supervisor home page or app.
Run your service desk in Salesforce? Talk to us about surfacing real-time Genesys KPIs on the agent record — with one definition across every system.