Handlowiec widzi szanse sprzedażowe swoich kolegów i edytuje je bez wiedzy opiekuna klienta. Agent serwisowy ma dostęp do danych finansowych kontraktu, które go nie dotyczą. Specjalista marketingu nadpisuje leady, które sprzedaż już kwalifikowała. To nie są rzadkie scenariusze – to typowe skutki braku przemyślanej struktury uprawnień w CRM.

SugarAI daje do dyspozycji rozbudowany system kontroli dostępu. Pytanie nie brzmi „czy da się to skonfigurować”, tylko „od czego zacząć i jak nie przesadzić”. Ten artykuł przeprowadzi Cię przez logikę systemu i pokaże, jak wygląda sensowna konfiguracja dla trzech typowych działów.

Trzy warstwy kontroli dostępu

Zanim przejdziemy do przykładów, warto zrozumieć, że uprawnienia w SugarAI działają na trzech poziomach, które współpracują ze sobą:

• Role definiują, co użytkownik może robić z danym typem rekordu – czy może go czytać, tworzyć, edytować, usuwać, importować lub eksportować. Rola działa niezależnie od tego, czyj jest rekord.
• Zespoły (Teams) decydują, co użytkownik widzi – czyli do których rekordów w ogóle ma dostęp. Rekord przypisany do Zespołu A jest niewidoczny dla kogoś należącego wyłącznie do Zespołu B, nawet jeśli jego rola daje mu uprawnienia do edycji.
• Uprawnienia na poziomie pól (dostępne w edycji Enterprise) pozwalają ukryć lub zablokować konkretne pola w rekordzie – np. wartość kontraktu widzi menedżer, ale nie handlowiec junior.

Te trzy warstwy działają kumulatywnie. Można mieć rolę z prawem edycji, ale nie widzieć rekordu, bo nie należy się do właściwego zespołu. Można być w odpowiednim zespole i widzieć rekord, ale nie móc zmienić kluczowych pól. Dopiero ich kombinacja daje pełną kontrolę.

Uwaga edycyjna: Uprawnienia na poziomie pól są dostępne tylko w SugarCRM Enterprise. Sell i Serve operują na rolach i zespołach – co w większości przypadków całkowicie wystarczy.

Typowa hierarchia: handlowiec → team leader → dyrektor sprzedaży.

Handlowiec powinien widzieć wyłącznie swoje rekordy – przypisane do niego leady, szanse sprzedażowe i kontakty. Jego rola daje prawo tworzenia i edytowania własnych rekordów, ale nie ich usuwania ani eksportowania. Należy do zespołu swojego regionu lub grupy produktowej.

Team leader należy do tego samego zespołu co jego handlowcy, dzięki czemu widzi wszystkie ich rekordy. Rola daje mu prawo edycji, ale nie usuwania rekordów podwładnych – może korygować dane, nie może ich kasować bez śladu. Ma też dostęp do raportów zespołowych.

Dyrektor sprzedaży należy do zespołu globalnego (lub wszystkich zespołów regionalnych). Rola daje pełne uprawnienia – w tym eksport i dostęp do zagregowanych raportów pipeline’u. W Enterprise: widzi też pole „wartość kontraktu” na poziomie pola, które jest ukryte dla handlowców.

Praktyczna wskazówka: jeśli firma pracuje w kilku regionach, warto stworzyć osobne zespoły per region i jeden zespół „Zarząd Sprzedaży". Dzięki temu dyrektor widzi wszystko, a handlowcy — tylko swój region. Bez tej separacji szybko pojawiają się konflikty o leady między regionami.

Struktura: agent serwisowy → supervisor → kierownik serwisu.

Agent widzi wyłącznie sprawy (Cases) przypisane bezpośrednio do niego lub do kolejki, do której należy. Może edytować statusy, dodawać komentarze i zamykać sprawy w swoim zakresie. Nie ma dostępu do danych finansowych kontraktu klienta ani do modułu szans sprzedażowych.

Supervisor należy do szerszego zespołu serwisowego – widzi sprawy wszystkich agentów w swojej grupie. Może je przejmować, zmieniać przypisanie i śledzić statusy SLA. Jego rola daje uprawnienia do edycji rekordów cudzych spraw, ale nie do usuwania.

Kierownik serwisu ma dostęp do raportów SLA, eskalacji i historii klienta z CRM (powiązanych kontaktów i kontraktów). Może eksportować dane na potrzeby analiz. W Enterprise: widzi pola z warunkami umowy serwisowej, które są ukryte dla agentów.

Kluczowa decyzja projektowa: czy agenci serwisowi powinni widzieć dane sprzedażowe klientów? Zazwyczaj odpowiedź brzmi „częściowo” – widzą historię zakupów i aktywny kontrakt, ale nie pipeline ani wartości prognoz. To realizuje się przez przynależność do odpowiednich zespołów, nie przez zmianę roli.

Struktura: specjalista marketingu → manager marketingu.

Specjalista tworzy i edytuje kampanie, dodaje treści, zarządza listami mailingowymi. Widzi leady wygenerowane przez swoje kampanie. Nie ma dostępu do szans sprzedażowych ani danych finansowych – jego rola nie obejmuje modułu Opportunities.

Manager marketingu ma pełny dostęp do modułów marketingowych: kampanie, leady, raporty ROI. Może przeglądać zagregowane dane o leadach przekazanych do sprzedaży, żeby mierzyć skuteczność działań. Nie ma jednak uprawnień do edycji szans sprzedażowych – separacja między działami jest celowa.

Częsty problem: marketing i sprzedaż pracują na tych samych leadach bez ustalonej granicy odpowiedzialności. Specjalista marketingu aktualizuje dane leadów po wysyłce kampanii - i nieświadomie nadpisuje kwalifikację, którą handlowiec już wprowadził. Rozwiązanie: etap lejka jako trigger zmiany „właściciela" rekordu. Lead w fazie MQL należy do zespołu marketingu, po przekazaniu do sprzedaży - zmienia zespół. Widoczność podąża za przypisaniem.

Sytuacja	Błędna konfiguracja	Dobra konfiguracja
Nowy pracownik do zespołu	Dostaje rolę „Administrator”, bo tak szybciej	Dostaje rolę swojego działu + przypisanie do właściwego zespołu
Dyrektor chce widzieć wszystko	Jeden globalny zespół dla wszystkich	Hierarchia zespołów: regionalne + zespół zarządczy
Różne uprawnienia w tym samym dziale	10 oddzielnych ról dla 10 stanowisk	3 role bazowe + dziedziczenie (rola nadrzędna → podrzędna)
Dane finansowe tylko dla kierownictwa	Ręczne ukrywanie danych poza systemem	Uprawnienia na poziomie pól (Enterprise)
Marketing i sprzedaż na tych samych leadach	Jeden wspólny zespół, każdy edytuje co chce	Zmiana zespołu rekordu przy przekazaniu leada
Odejście pracownika	Konto zostaje aktywne „na wszelki wypadek”	Dezaktywacja konta = automatyczna utrata dostępu do wszystkich rekordów

Typowe błędy przy projektowaniu uprawnień

Nadawanie roli Administratora „dla wygody” to najczęstszy błąd. Admin widzi i może zmienić wszystko – łącznie z konfiguracją systemu. Wystarczy jeden pracownik z tą rolą poza działem IT, żeby narazić integralność danych.

Tworzenie zbyt wielu ról zamiast hierarchii dziedziczonej. Jeśli masz 20 stanowisk w firmie i tworzysz 20 ról, zarządzanie nimi staje się koszmarem przy każdej zmianie w strukturze. Lepiej zbudować 4-5 ról bazowych i rozszerzać je dla konkretnych potrzeb.

Brak separacji zespołów między działami prowadzi do nieplanowanego wycieku danych – handlowiec widzi sprawy serwisowe, agent widzi pipeline sprzedaży.

Ignorowanie uprawnień na poziomie pól przy wrażliwych danych. Samo ukrycie rekordu nie wystarczy, jeśli użytkownik ma dostęp do eksportu – może pobrać dane, których nie powinien widzieć.

Zanim zaczniesz klikać w panelu administracyjnym, odpowiedz na kilka pytań:

• Ile masz działów i czy ich dane powinny być od siebie odseparowane?
• Czy firma działa w kilku regionach lub oddziałach z osobnymi pipeline’ami?
• Które pola zawierają dane wrażliwe (finansowe, prawne), do których dostęp powinien być ograniczony?
• Jak wygląda ścieżka przekazywania rekordów między działami (np. lead z marketingu do sprzedaży)?
• Czy używasz Sugar Sell, Serve czy Enterprise – bo to determinuje dostępne narzędzia?

Odpowiedzi na te pytania wyznaczą strukturę zespołów i ról, zanim jeszcze otworzysz panel konfiguracji. Godzina na papierze przed wdrożeniem oszczędza dziesiątki godzin poprawek.

Jeśli zainteresował Cię ten temat, skontaktuj się z nami. Chętnie odpowiemy na Twoje pytania.