Automatyzacja Jira Service Management: jak działają przepływy, SLA i webhooki

Dokumentacja Atlassian nazywa teraz reguły automatyzacji „przepływami” (flows); spotkasz oba terminy i oznaczają to samo. Przepływ możesz utworzyć od zera, z szablonu lub za pomocą Rovo, a po włączeniu jego kroki wykonują się po kolei, od góry do dołu.

Dwa triggery są specyficzne dla pracy serwisowej. 'SLA threshold breached' pozwala wybrać SLA i uruchomić przepływ, gdy zostało naruszone albo gdy zaraz zostanie naruszone. 'Approval required' uruchamia się, gdy zostanie utworzony lub zaktualizowany element roboczy wymagający zatwierdzenia albo gdy dodani zostaną nowi zatwierdzający. Trigger harmonogramu (scheduled) uruchamia przepływ według zegara, co przydaje się do okresowych kontroli, np. wylistowania elementów roboczych, którym grozi naruszenie.

Automatyzacja w Jira Service Management służy głównie temu, by trzy struktury pozostawały aktualne i poprawne:

• Kolejki (queues) to przefiltrowane zestawy elementów roboczych, które dają agentom skupiony widok ich pracy. Filtrują według pól takich jak status, typ pracy, osoba przypisana i priorytet albo według JQL. Agenci nie mogą tworzyć ani edytować kolejek; robią to administratorzy przestrzeni.
• Typy żądań (request types) to formularze, za pomocą których klienci zgłaszają żądania w portalu. Każdy typ żądania jest powiązany z dokładnie jednym typem pracy (work type): typ żądania odpowiada za nazewnictwo i ustawienia portalu, a typ pracy przechowuje workflow i pola. Jeden typ pracy może obsługiwać wiele typów żądań.
• SLA mierzą czas względem celów. Każde SLA ma własne warunki startu, wstrzymania i zatrzymania; wstrzymanie jest opcjonalne i zwykle stosuje się je na czas oczekiwania na odpowiedź klienta, a pomiar kończy się, gdy tylko zostanie spełniony którykolwiek warunek zatrzymania.

W praktyce przepływy ustawiają pola, według których filtrują kolejki i cele SLA. Jeśli przepływ ustawia priorytet lub pole niestandardowe na podstawie typu żądania lub treści wiadomości, właściwa kolejka i właściwy cel SLA automatycznie przejmą element roboczy.

Smart values pozwalają przepływowi wstawiać dane z elementu roboczego do pól, komentarzy, e-maili i treści żądań webowych. {{issue.key}} zwraca klucz, np. PROJ-123. Inne pola działają według tego samego wzorca z użyciem nazwy pola, także pola niestandardowe; jeśli dwa pola mają tę samą nazwę, użyj zamiast niej ID pola niestandardowego.

Interfejs Atlassian mówi teraz 'work item' tam, gdzie wcześniej było 'issue', ale składnia smart values w dokumentacji nadal używa prefiksu issue. Po polach wielowartościowych można iterować składnią #, zamykaną przez {{/}}.

Webhooki działają w obu kierunkach:

• Wychodzące: akcja 'Send web request' wywołuje API innego systemu, gdy przepływ się uruchamia, i może zwrócić dane z odpowiedzi do dalszych kroków. Twój system odbierający musi akceptować żądania z sieci Atlassian.
• Przychodzące: trigger przychodzącego webhooka daje przepływowi własny URL, dzięki czemu system zewnętrzny (chatbot, narzędzie rozliczeniowe, narzędzie monitorujące) może uruchomić przepływ żądaniem HTTP.
• Komunikatory: akcje 'Send Slack message' i 'Send Microsoft Teams message' publikują na kanałach, a w treści wiadomości można używać smart values.

Według stanu na październik 2026 Jira Cloud mierzy użycie automatyzacji dla każdego produktu w skali miesiąca, z limitami zależnymi od planu. Atlassian opisuje sposób liczenia użycia na stronie 'How is your automation usage calculated'; sprawdź ją oraz swoje bieżące użycie, zanim dodasz często uruchamiane przepływy harmonogramowe.

Typowe pierwsze przepływy dla service desku:

• Ustawianie priorytetu, komponentu lub osoby przypisanej przy tworzeniu na podstawie typu żądania i treści zgłoszenia.
• Publikowanie na kanale eskalacji, gdy SLA zaraz zostanie naruszone.
• Przypominanie klientowi, gdy żądanie czeka na jego odpowiedź, a następnie rozwiązanie go z komentarzem po ustalonym czasie.
• Wysyłanie nowych żądań o wysokim priorytecie do systemu zewnętrznego przez 'Send web request'.

TascaLab pracuje na Twojej istniejącej instancji Jira Service Management, bez zmiany platformy, łącząc natywną automatyzację z API, webhookami oraz Make lub n8n tam, gdzie przepływ musi sięgnąć do innych narzędzi. Ticket Routing & Categorization kosztuje jednorazowo 3000 zł; Custom Automation kosztuje od 4650 zł. Każdy projekt obejmuje 30 dni wsparcia po uruchomieniu i podstawową dokumentację, a większość wdrożeń trwa 1–3 tygodnie. Zacznij od bezpłatnej 30-minutowej rozmowy Health Check.