← Blog / Integracja SAP i Salesforce

Agentforce i dane z SAP: gdzie agent w CRM się zatrzymuje

Opublikowano: 5 października 2026

Klient pisze na czacie, kiedy dotrze jego zamówienie. Agent w Salesforce widzi szansę sprzedaży zamkniętą trzy tygodnie temu i datę dostawy wpisaną wtedy przez handlowca, więc podaje ją bez wahania, choć SAP od tygodnia ma w zamówieniu inny potwierdzony termin.

Agent odpowiedział z jedynych danych, jakie miał. W firmie, w której zamówienia, ceny i kredyt kupiecki prowadzi SAP, każde pytanie klienta lub handlowca wymaga osobnej decyzji o przepływie danych z ERP: co agent czyta albo zmienia, czy czyta na żywo, czyimi uprawnieniami działa i co robi, gdy SAP nie odpowiada. Poniżej te cztery decyzje na trzech typowych przykładach.

Trzy pytania, trzy różne odpowiedzi

Termin dostawy: odczyt, tylko z którego miejsca

Najprostszy wariant to replika. Status zamówienia, potwierdzone daty z harmonogramu i numer dostawy trafiają z SAP do Salesforce zdarzeniami albo cyklicznie, tak samo jak przy statusie zamówienia dla handlowca, a agent czyta je jak każde inne pole w CRM. Odpowiedź jest szybka i nie zależy od dostępności SAP, ale jest tak aktualna jak ostatnia synchronizacja. Jeśli replikacja działa raz na dobę, agent w opisanej wyżej rozmowie poda termin sprzed zmiany.

Drugi wariant to odczyt na żywo. Salesforce opisuje w materiałach Trailhead o źródłach danych dla agentów dwie drogi do systemów zewnętrznych: obiekty zewnętrzne Salesforce Connect, które pokazują dane z innego systemu bez kopiowania, oraz akcje wywołujące API. Agent dostaje wtedy stan z tej sekundy, ale każda rozmowa generuje wywołanie do SAP, a czas odpowiedzi S/4HANA staje się czasem odpowiedzi agenta.

W praktyce dla terminów dostawy wygrywa replika wzbogacona zdarzeniami o zmianie potwierdzonej daty, z polem „stan na godzinę”, które agent ma w instrukcji przekazywać klientowi. Ten sam przypadek pokazuje problem tożsamości. Agent obsługujący klientów działa w Salesforce jako osobny użytkownik agenta, a nie jako klient. Jeśli akcja pyta SAP o zamówienie po numerze podanym w rozmowie, a nie po koncie klienta zweryfikowanym w sesji, klient może zapytać o cudze zamówienie i dostać odpowiedź.

Cena i rabat: symulacja, a nie cennik

Cena dla konkretnego klienta wynika w SAP z procedury cenowej, rekordów warunków, umów rabatowych i ilości. Kopia cennika w Salesforce tego nie odtworzy, więc agent, który ma podać cenę, potrzebuje wywołania symulacji zamówienia sprzedaży w S/4HANA. Według dokumentacji SAP symulacja zwraca wycenę, dostępność i wynik kontroli kredytowej bez zapisywania dokumentu, więc formalnie jest odczytem.

Agent wspierający handlowca działa inaczej niż agent dla klientów. Salesforce pisze w module Trailhead o agentach dla pracowników, że taki agent jest zalogowany jako osoba, której pomaga, i ma jej uprawnienia. Po stronie Salesforce to rozwiązuje sprawę, po stronie SAP nie. Wywołanie trafia do S/4HANA przez warstwę integracyjną zwykle jako jeden użytkownik techniczny, więc SAP nie wie, który handlowiec pyta i jaki ma zakres. Przeniesienie tożsamości użytkownika aż do SAP jest możliwe, ale wymaga konfiguracji w trzech miejscach, dlatego wiele zespołów zostaje przy użytkowniku technicznym i odtwarza ograniczenia w samej akcji. Rabat ponad to, co daje wycena z SAP, zostaje w procesie akceptacji, a agent może go najwyżej zaproponować.

Blokada kredytowa: tu agent coś zmienia

Zamówienie zablokowane w kontroli kredytowej to pierwszy z tych przypadków, w którym agent zmienia dane w SAP. Status blokady i jej powód da się pobrać, a SAP udostępnia standardowe API „Sales Document with Credit Block”, które pozwala dokument odczytać, sprawdzić, zwolnić albo odrzucić. Technicznie nic nie stoi na przeszkodzie, żeby agent zwolnił zamówienie, gdy handlowiec poprosi.

Przeszkody są organizacyjne: zwolnienie blokady to decyzja o ryzyku kredytowym, przypisana w SAP do konkretnej roli, i nie powinna zależeć od tego, jak przekonująco ktoś napisał prośbę do agenta. Rozsądny podział wygląda tak: agent sprawdza status, wyjaśnia powód blokady, zbiera brakujące informacje i zakłada prośbę dla kontrolera kredytowego, który zwalnia zamówienie w SAP albo w aplikacji z własnymi uprawnieniami. Szerzej o tym, gdzie agenty AI potrzebują człowieka, piszemy osobno.

Jeśli zwolnienie ma iść przez API, akcja musi czytać treść odpowiedzi SAP, nie sam kod HTTP. W nocie SAP opisującej to API (KBA 3779966) jest przykład: wywołanie zwolnienia dla dokumentu już zwolnionego lub odrzuconego zwraca kod 200 z komunikatem informacyjnym, więc agent, który patrzy tylko na status, zamelduje sukces operacji, która niczego nie zmieniła.

Jak akcja agenta dociera do SAP

Akcja Agentforce to opakowanie dla mechanizmu, który wykonuje pracę. Trailhead wymienia jako podstawę akcji autolaunched Flow, klasy Apex, szablony promptów i API wystawione przez MuleSoft, a od wydania Spring '25, według bloga Salesforce dla deweloperów, akcję można też utworzyć bezpośrednio z usługi zewnętrznej (External Services) zarejestrowanej na podstawie specyfikacji OpenAPI. Flow i Apex są deterministyczne: model wybiera, którą akcję uruchomić i z jakimi parametrami, a dalej wykonuje się zawsze ta sama logika.

Połączenie z systemem zewnętrznym opiera się na Named Credentials. Dokumentacja Salesforce rozdziela adres usługi od danych uwierzytelniających w External Credential, a dostęp do nich nadaje przez zestawy uprawnień. Do wyboru jest jedna tożsamość dla wszystkich wywołań albo tożsamość per użytkownik. Dla agenta obsługującego klientów praktycznie zawsze będzie to pierwsza opcja, dla agenta handlowca warto przynajmniej rozważyć drugą.

Między Salesforce a S/4HANA zwykle stoi warstwa integracyjna, u klientów SAP często SAP Integration Suite, a w części firm MuleSoft. To w niej powinna być logika, której agent nie powinien znać: mapowanie klienta z Salesforce na partnera handlowego w SAP, zawężenie zakresu danych, limity wywołań i dziennik, kto o co pytał. Agent dostaje od niej kilka operacji biznesowych, na przykład „status zamówień klienta”, a nie dostęp do całego katalogu API S/4HANA.

Polityka API SAP i agent spoza SAP

Od kwietnia 2026 roku ten projekt ma jeszcze jedno ograniczenie. Polityka API SAP w punkcie 2.2.2 zabrania używania API do interakcji lub integracji z półautonomicznymi lub generatywnymi systemami AI, które planują, wybierają lub wykonują sekwencje wywołań API, chyba że dzieje się to w ramach architektur i ścieżek wskazanych przez SAP. Punkt 3 dodaje, że kontroli nie wolno obchodzić przez usługi pośrednie, bramy ani własny kod, więc sama warstwa pośrednia między Agentforce a SAP nie zmienia oceny.

Agent Agentforce, który wybiera spośród akcji odwzorowanych jeden do jednego na API S/4HANA, wpisuje się w ten opis wprost. Jako dozwoloną drogę SAP wskazuje między innymi MCP Gateway w Integration Suite, dostępny w edycjach Enhanced i Premium, przez który zewnętrzny agent dostaje wybrane API jako narzędzia z osobnymi poświadczeniami. Po drugiej stronie Salesforce opisuje w Trailhead natywnego klienta MCP w Agentforce, w którym administrator rejestruje serwer i wybiera, które narzędzia udostępnić agentowi. Na papierze te dwa elementy do siebie pasują, ale publicznych opisów wdrożeń, które łączą je produkcyjnie z S/4HANA, na razie brakuje.

Nie jest też jasne, jak polityka traktuje typowy dziś układ: agent wybiera jedną z trzech akcji, a każda uruchamia stały, z góry zaprojektowany przepływ w warstwie integracyjnej. Według relacji SAPinsider z wyjaśnień SAP deterministyczna automatyzacja ze z góry ustaloną sekwencją wywołań nie podlega temu ograniczeniu, ale SAP przedstawia swoje wskazówki jako kierunkowe, a tekst polityki od kwietnia się nie zmienił. Zanim agent z dostępem do SAP wyjdzie poza pilotaż, potrzebne jest pisemne potwierdzenie od SAP dla konkretnej architektury, a nie interpretacja zespołu projektowego.

Gdy SAP odpowiada wolno albo wcale

Agent obsługujący klientów pracuje całą dobę, a S/4HANA w wielu firmach ma nocne okna serwisowe i zadania wsadowe, które spowalniają odpowiedzi. Każda akcja odczytu potrzebuje więc zapisanego zachowania na wypadek przekroczenia czasu: odpowiedź z repliki z informacją o godzinie, zwykłe „nie mam teraz dostępu do tej informacji” i przekazanie sprawy człowiekowi. Bez takiej instrukcji model potrafi wypełnić lukę tym, co znalazł w CRM.

Przy działaniach zapisujących wywołanie synchroniczne w trakcie rozmowy jest kiepskim pomysłem. Prośba o zwolnienie blokady albo zmianę terminu powinna trafić do kolejki w warstwie integracyjnej, z identyfikatorem pozwalającym bezpiecznie ponowić operację, a klient lub handlowiec dostaje potwierdzenie przyjęcia, nie wykonania. Wynik wraca do Salesforce zdarzeniem i dopiero wtedy agent może o nim poinformować.

FAQ

#Agentforce #SAP #API #Architektura #Order-to-Cash