Klient jako uczestnik procesu — zadania BPM z linku w e-mailu
Niektóre kroki procesu może wykonać tylko klient — potwierdzić, zaakceptować, odpowiedzieć. Pokazujemy, jak włączyć klienta do procesu BPM bez wystawiania silnika procesów na świat i bez tokenów w linkach.
Procesy biznesowe rzadko kończą się na granicy firmy. Zanim wyłączymy starą integrację, klient musi potwierdzić, że przeszedł na nową. Zanim zmienimy warunki, klient musi je zaakceptować. Do tej pory takie kroki działały poza procesem: e-mail, odpowiedź, ręczne odhaczenie w systemie, przypomnienie wysłane — albo nie — po dwóch tygodniach.
Wbudowaliśmy klienta w proces BPM jako pełnoprawnego uczestnika. Poniżej wzorzec, który zastosowaliśmy, i decyzje bezpieczeństwa, które za nim stoją.
Przepływ
- Proces dochodzi do kroku, który wymaga klienta. Silnik wywołuje API platformy, a ta wysyła e-mail z linkiem.
- Link prowadzi do strony w panelu klienta. Jeśli klient nie jest zalogowany, przechodzi przez zwykłe logowanie i wraca na tę samą stronę.
- Strona pobiera opis zadania i pola formularza — zdefiniowane w procesie, nie w kodzie interfejsu.
- Klient wysyła formularz. API klienckie przekazuje odpowiedź do silnika procesów, który waliduje pola i zamyka zadanie.
- Jeśli klient nie zareaguje, timer w procesie wysyła przypomnienie i otwiera drugie zadanie z nowym terminem. Po jego upływie proces kończy się statusem „brak potwierdzenia”, a zespół dostaje informację.
Decyzje bezpieczeństwa
W linku nie ma tokenu
Najprostsze rozwiązanie — link z jednorazowym tokenem, który sam w sobie uprawnia do wykonania zadania — jest też najbardziej ryzykowne. E-maile są przekazywane dalej, skanowane przez filtry, które otwierają linki, i zostają w skrzynkach na lata. Nasz link zawiera wyłącznie klucz biznesowy procesu. Sam w sobie niczego nie uprawnia.
Tożsamość pochodzi z sesji, nigdy z parametru
API klienckie bierze identyfikator klienta wyłącznie z sesji zalogowanego użytkownika. Nawet jeśli ktoś podmieni klucz w linku, nie wykona zadania cudzego procesu.
Klient nie rozmawia z silnikiem procesów
Silnik BPM nie jest dostępny dla klientów. Żądania klienta przechodzą przez API klienckie, które z kolei rozmawia z silnikiem tokenem serwisowym. To zachowuje granicę, którą utrzymujemy w całej platformie: API administracyjne i API klienckie są rozdzielone.
Silnik sprawdza własność zadania
Po stronie silnika procesów dodatkowa kontrola: zadanie klienta ma znacznik właściciela, a identyfikator klienta z żądania jest porównywany ze zmienną procesu. Brak instancji lub zadania to odpowiedź 404, cudze zadanie — 403. Dwie niezależne warstwy, z których każda sama wystarczyłaby do zablokowania nadużycia.
Wzorzec ogólny, nie jednorazowy
Zaczęliśmy od jednego konkretnego przypadku — potwierdzenia przed wyłączeniem starej integracji — ale zbudowaliśmy go jako ogólny prymityw: zadanie klienta z dowolnymi polami, przypomnieniem i limitem czasu. Kolejne zastosowania — akceptacja zmian umowy, zgoda na aktualizację, odpowiedź na ankietę — to nowa definicja procesu, bez zmian w kodzie panelu klienta ani API.
Podsumowanie
Klient w procesie BPM to nie egzotyka, tylko brakujący element większości procesów obsługi. Warunek: zaprojektować to tak, jakby link w e-mailu miał trafić w niepowołane ręce — bo prędzej czy później trafi.
Szerszy kontekst: Silnik BPM wpięty w istniejący CRM — w 9 dni.