„Daj mi dostęp” przychodzi jako jedno zdanie, a naprawia się za każdym razem inaczej: jednemu brakuje roli w CRM, drugi stracił pole „Odpowiedzialny”, trzeci po prostu nie jest uczestnikiem zadania. Dopóki portal jest mały, uprawnienia rozdaje się na życzenie. Przy pięćdziesięciu pracownikach staje się to osobnym zajęciem, a pytanie „kto właściwie widzi tego deala” przestaje mieć krótką odpowiedź.

Jak działają uprawnienia dostępu w Bitrix24?

Jednego systemu uprawnień w portalu nie ma — są trzy i nie sprowadzają się do siebie nawzajem. CRM działa na modelu ról: rola plus poziom dostępu, ustawiany osobno dla odczytu, edycji, usuwania, eksportu i importu. Zadania nie znają ról; widoczność wynika z udziału — twórca, odpowiedzialny, współwykonawca, obserwator, członek projektu. Grupy, Dysk i strumień aktualności to trzeci model, z własnymi ustawieniami prywatności. „Dać dostęp do deala i do zadania przy nim” w Bitrix24 (Alaio) oznacza więc dwa różne ustawienia w dwóch różnych miejscach — i to pierwszy powód, dla którego dostęp zostaje nadany, a mimo to nie działa.

Jak skonfigurować uprawnienia w CRM?

Macierz mieszka w ustawieniach CRM, w sekcji uprawnień dostępu. Rolę przypisuje się nie tylko osobie, ale też działowi lub grupie — przypisanie do działu to wariant, który przetrwa, bo nowa osoba dziedziczy prawa w chwili, gdy pojawia się w strukturze firmy. Poziomy są znane: brak dostępu, własne, własne i działu, własne i poddziałów, wszystkie. Ustawia się je osobno dla każdej encji, a dla deali i leadów dodatkowo dla każdego etapu — można pozwolić na edycję deala w toku i zamrozić wygranego.

Dwie zasady, które oszczędzają późniejszego bólu. Trzymaj liczbę ról nisko: trzy do pięciu, powiązanych z działami, a nie jedna rola na osobę, inaczej macierz staje się nieczytelna w ciągu roku. I potraktuj kolumnę eksportu jako osobną decyzję: poziom „wszystkie” z włączonym eksportem to droga, którą bazy klientów wychodzą z CRM.

Dlaczego pracownik nie widzi deala albo kontaktu?

W dziewięciu przypadkach na dziesięć rola jest niewinna, a winowajcą jest pole „Odpowiedzialny”. Poziom „własne” znaczy dosłownie „rekordy, w których jestem odpowiedzialny”, więc zmiana osoby odpowiedzialnej natychmiast odbiera dostęp poprzedniemu właścicielowi. Drugi najczęstszy przypadek: encje powiązane mają własne uprawnienia, ktoś widzi deala, ale nie widzi podpiętej firmy, i karta wygląda na w połowie pustą, choć dane są na miejscu. Trzeci: znacznik „dostępne dla wszystkich” na karcie, który otwiera ten jeden rekord z pominięciem całej macierzy.

Sprawdzaj w tej kolejności: jaką rolę ma użytkownik, jaki poziom obowiązuje dla tej konkretnej encji, kto jest odpowiedzialny, w jakim dziale figuruje w strukturze i czy nie jest użytkownikiem ekstranetu. Pierwszy krok, w którym odpowiedź rozmija się z oczekiwaniem, jest przyczyną.

Kto widzi zadanie i jak nadać do niego dostęp?

Zadania nie mają ani ról, ani poziomów. Zadanie widzą: twórca, odpowiedzialny, współwykonawcy, obserwatorzy, członkowie projektu, do którego należy, oraz przełożony — zadania swoich podwładnych. To cała lista. „Nadać uprawnienia do zadania” technicznie się nie da: jedyne wejście prowadzi przez udział, zwykle w roli obserwatora. Klocek Zarządzanie obserwatorami robi to jako krok procesu — dodaje kierownika działu do obserwatorów, gdy deal wchodzi w akceptację, i usuwa go, gdy akceptacja się kończy.

Dlaczego automatyzacja widzi rekord, którego nie widzi człowiek?

Bo działają jako różne tożsamości. Natywne reguły automatyzacji i akcje procesu wykonują się w imieniu użytkownika — osoby, która utworzyła regułę, albo odpowiedzialnego — i trafiają dokładnie na jego ograniczenia: jeśli człowiek nie widzi rekordu, akcja też się nie uda. Aplikacje z Marketu działają inaczej: rozmawiają z portalem tokenem, który administrator wydał przy instalacji, więc aktywności Roboteki czytają i zapisują rekord niezależnie od tego, kto uruchomił proces.

To usuwa całą klasę cichych awarii i przenosi na Ciebie jeden obowiązek: skoro uprawnienia niczego nie zatrzymają, kontrola „czy tej osobie w ogóle wolno” należy do warunku wewnątrz procesu, a nie do macierzy dostępu. Jeśli natomiast proces w ogóle nie ruszył, uprawnienia rzadko są przyczyną — kolejność diagnostyki opisuje dlaczego roboty nie działają, a stronę wywołań zewnętrznych — diagnostyka webhooków.

Jak utrzymywać dostęp aktualny automatycznie?

Samych ról CRM nie da się zautomatyzować: REST API nie udostępnia metod do edycji macierzy uprawnień, więc pozostaje ona ekranem obsługiwanym ręcznie. Zautomatyzować można wszystko, od czego dostęp faktycznie zależy — osobę odpowiedzialną, dział i skład uczestników.

  • Pobierz przełożonego pracownika zwraca bezpośredniego przełożonego z drzewa działów, dzięki czemu krok akceptacji adresuje rolę, a nie nazwisko wpisane na sztywno.
  • Pobierz dział pracownika zwraca dział osoby odpowiedzialnej; jeden szablon rozgałęzia się według jednostki, zamiast mnożyć szablony na każdy zespół.
  • Zmień odpowiedzialnego w powiązanych przenosi odpowiedzialnego na powiązane deale, kontakty i firmy przy przekazaniu klienta, żeby nowy właściciel nie odziedziczył połowy karty.

Co dalej

Zacznij od inwentaryzacji: wypisz role faktycznie używane i ich poziomy dla deali — połowa zwykle okazuje się duplikatami. Potem wyłącz eksport tam, gdzie nie jest potrzebny, i przenieś przypisywanie ról z osób na działy. Na koniec dodaj krok, który utrzymuje odpowiedzialnego w aktualnym stanie, bo na tym jednym polu wisi większość widoczności w CRM. Pozostałe klocki są w katalogu robotów, a szerszy obraz w przewodniku po procesach biznesowych. Jeśli brakuje klocka, którego potrzebujesz — opisz zadanie: Roboteka buduje brakujące aktywności za darmo i wypuszcza je do wspólnej biblioteki.