Nativer Screen Pop im SSCV2 Agent Desktop: Was das PDF verschweigt

Im August 2026 haben wir unser Telefonie-Widget von einem eigenen Seitenpanel auf den nativen Screen Pop des Agent Desktop in SAP Sales and Service Cloud V2 umgestellt. Ein Anruf kommt herein, die Agentin sieht den Anrufer, der richtige Arbeitsbereich öffnet sich, und wenn der Anruf endet, endet auch die Sitzung. Auf dem Papier einfach. Spannend war alles, was der öffentliche Integrationsleitfaden nicht sagt.

Kurzfassung: Die Shell des Agent Desktop parst nur XML, bildet nur die Aktionen NOTIFY und END ab und erkennt eine Sitzung ausschliesslich an ihrer ExternalReferenceID (einer UUID). Ein END beendet die Sitzung intern, entfernt die Sitzungskarte aber nicht. Um eine Karte zu entfernen, senden Sie eine OUTBOUND-Nutzlast ohne Action-Element für die Referenz der Karte und das END unmittelbar danach. Wer dazwischen wartet, lässt einen Reiter offen.

In der ersten Fassung dieses Beitrags stand der Rat «warten, bis die Anrufaktivität auffindbar ist, dann beenden». Messungen an echten Anrufen im September 2026 haben gezeigt, dass das falsch ist; der Abschnitt zum Timing unten ersetzt ihn.

Warum ignoriert der Agent Desktop JSON-Nutzlasten?

Das CTI-Widget läuft in einem Frame im Agent Desktop und spricht mit der Shell über die Browser-Schnittstelle postMessage. SAP beschreibt den Widget-Ansatz im Leitfaden SAP Service Cloud Version 2 integration with Third-Party CTI Providers. Was dort nicht auf der Hand liegt: Die Shell, die wir getestet haben, parst nur XML. Wer denselben Inhalt als JSON schickt, wie es manche Beispiele nahelegen, erlebt nichts. Keine Fehlermeldung, keine Logzeile. Der Adapter glaubt, er sei integriert; die Shell glaubt, niemand habe angerufen.

Diese Stille hat uns einen Nachmittag gekostet, den eine einzige Fehlermeldung auf zehn Minuten verkürzt hätte. Kennt man die Regel, ist der XML-Vertrag stabil und klein. Eine minimale Benachrichtigung für einen eingehenden Anruf sieht so aus:

<payload>
  <Type>CALL</Type>
  <EventType>INBOUND</EventType>
  <Action>NOTIFY</Action>
  <ANI>+41410000000</ANI>
  <ExternalReferenceID>3f2b6c1e-8d4a-4f7e-9a51-2c0d7e9b4a10</ExternalReferenceID>
</payload>

Drei Regeln, die wir an der Shell verifiziert haben:

• Nur NOTIFY und END sind Aktionen. Jeder andere Action-Wert, ACCEPT eingeschlossen, bleibt leer. Das klingt nach einer Einschränkung und ist der Hebel für das Kartenproblem weiter unten.
• EventType wird gross geschrieben und als Sitzungstyp übernommen. Funktionierende Werte sind INBOUND, OUTBOUND, UPDATE_ACTIVITY, TRANSFER, PUSH, CALLENDED und CALL_ERROR.
• ExternalReferenceID muss eine UUID sein. Sie ist der einzige Schlüssel, über den die Shell eine Sitzung wiedererkennt.

Welche ID muss in allen CTI-Nachrichten übereinstimmen?

Die ganze Sitzung hängt an dieser einen ExternalReferenceID. Sie muss in jeder Nachricht zum Anruf identisch sein, ebenso in der Telefonaktivität, die das Widget im CRM anlegt. Erzeugen zwei Komponenten je ihre eigene ID, entsteht das hässlichste Fehlerbild überhaupt: Der sichtbare Teil funktioniert, das Aufräumen nicht, und bis zum Mittag sammeln sich auf dem Desktop der Agentin verwaiste Sitzungen.

ID-Disziplin ist langweilig, und genau deshalb rutscht sie durch. Die UUID einmal beim Eingang des Anrufs erzeugen, an jede Komponente weiterreichen, nie neu erzeugen.

Warum schliessen Screen-Pop-Sitzungskarten nicht?

Hier lässt einen der Leitfaden allein. Der Agent Desktop zeigt zwei verschiedene Dinge, und sie verschwinden auf unterschiedliche Weise:

	Popover	Sitzungskarte
Wo	Neben der minimierten CTI-Leiste	Oberhalb der Reiter, auch bei offener Leiste
Sichtbar	Nur solange die CTI-Leiste minimiert ist; das Öffnen der Leiste schliesst es	Bis die Shell sie über die Referenz-ID herausfiltert
Entfernt durch	Bestätigung aus der Dock-Ansicht	Eine Nutzlast, die in den Sitzungsstart-Block der Shell fällt

Zwei Verhaltensweisen haben uns überrascht. Ein END beendet die Sitzung im internen Zustand der Shell, entfernt die Sitzungskarte aber nicht. Und der Benachrichtigungs-Toast wird bei END nie quittiert. Beides muss das Widget selbst erledigen.

Die Nutzlast, die eine stehende Karte entfernt, ist diese: ohne Action-Element und mit der Referenz der Karte, die noch auf dem Bildschirm steht.

<payload>
  <Type>CALL</Type>
  <EventType>OUTBOUND</EventType>
  <ANI>+41410000000</ANI>
  <ExternalReferenceID>3f2b6c1e-8d4a-4f7e-9a51-2c0d7e9b4a10</ExternalReferenceID>
</payload>

Warum das funktioniert: Die Shell entfernt eine Karte nur innerhalb des Blocks, der einen Sitzungsstart verarbeitet, und überspringt diesen Block bei NOTIFY, END, UPDATE_ACTIVITY, CALLENDED und CALL_ERROR. Wer Action weglässt, kommt hinein. OUTBOUND ist der richtige Ereignistyp, weil die Shell dafür keine Interaktion erzeugt: Es öffnet sich kein neuer Arbeitsbereich-Reiter, der Filter, der die Karte entfernt, läuft aber trotzdem.

Start und END direkt hintereinander senden

Der Haken: Diese Nutzlast startet zugleich eine Sitzung. Das Entfernen der Karte ist ein Nebeneffekt des Blocks, nicht sein Zweck. Das END für dieselbe Referenz muss deshalb unmittelbar folgen.

Wir haben das im September 2026 an echten Anrufen gemessen. Lagen zwischen Start und END mehrere Sekunden (in unserer ersten Version, weil das END darauf wartete, dass die Telefonaktivität angelegt und indexiert war), öffnete die Shell einen Agent-Desktop-Reiter mit laufender Uhr und setzte das grüne Sitzungsabzeichen auf das CTI-Symbol. Das verspätete END holte ihn nicht mehr zurück. Unser ursprünglicher Rat, «warten, bis die Aktivität auffindbar ist, dann beenden», hat genau das erzeugt.

Die Reihenfolge, die funktioniert:

1. Anruf endet: Telefonaktivität im CRM anlegen oder aktualisieren, mit derselben Referenz-ID. Das läuft in seinem eigenen Takt.
2. Karte entfernen: die OUTBOUND-Nutzlast ohne Action für die stehende Referenz senden.
3. Im selben Atemzug das END für diese Referenz senden.
4. Toast und Popover aus dem Widget heraus schliessen, denn die Shell tut es nicht.

Wer gegen eine Blackbox integriert, plant Beobachtung ein, nicht nur Lektüre. Der Vertrag, gegen den man ausliefert, ist der, den man misst.

Wie führt man den nativen Screen Pop ein?

Hinter einem Schalter, pro Mandant. Telefonie ist die eine Integration, bei der jede Agentin jede Regression innert Minuten bemerkt. Wir haben den nativen Modus Mandant für Mandant eingeschaltet, und nur so konnten wir diese Lektionen lernen, ohne dass das Support-Telefon heiss lief. Bevor wir einen Mandanten umstellen, prüfen wir vier Dinge:

• Jede Nutzlast ist XML, kein Codepfad sendet noch JSON.
• Eine UUID pro Anruf, wiederverwendet in jeder Nachricht und in der Telefonaktivität.
• Kartenentfernung und END gehen gemeinsam hinaus, ohne Wartezeit dazwischen.
• Ein Testanruf ein- und ausgehend hinterlässt keine Karte, keinen Toast und keinen offenen Reiter.

Der Shell-Code ändert sich mit den SAP-Releases, deshalb wiederholen wir diesen Testanruf nach jedem Release. Wenn Sie selbst gegen den Agent Desktop entwickeln und Verhalten sehen, das diesem Beitrag widerspricht: Sagen Sie es uns.

Wo das hingehört

Der Screen Pop ist der letzte Schritt einer CTI-Integration, nicht der erste. Die Architektur rundherum (Anruferidentifikation, Telefonaktivitäten, die Seite des Telefonieanbieters) beschreibt unser technischer Leitfaden zur CTI-Integration mit SAP Sales Cloud V2. Das Widget selbst ist als eigene App auf SAP BTP gebaut, und wie wir Sales und Service Cloud V2 im eigenen Unternehmen nutzen, zeigt der Beitrag Wir nutzen SAP Sales Cloud und Service Cloud selbst.

Das oben beschriebene Verhalten des Agent Desktop steht nicht im öffentlichen Integrationsleitfaden; die SAP-Dokumentation zu Service Cloud V2 beschreibt die unterstützte CTI-Schnittstelle. Wir bauen solche Telefonie-Anbindungen auf SAP BTP im Rahmen von Service Cloud V2. Fragen Sie uns zu Ihrem Aufbau.