Gdy jako programista czy konsultant Salesforce’a pracujesz z biznesem, masz większy wpływ na projekt, niż wtedy, gdy Twoim partnerem projektowym jest dział IT. Od Ciebie zależy nie tylko ostateczny kształt powstającego rozwiązania, ale również to, jak potoczy się realizacja. Jednym z ciekawszych i trudniejszych obszarów jest budowanie uprawnień.

Twoje doświadczenie i wiedza na temat Salesforce mają tu kluczowe znaczenie. Gdy wiesz, jakie są możliwości Platformy, ale także jej ograniczenia, możesz zaproponować klientowi  rzetelne rozwiązanie: takie, które odpowie na jego potrzeby i zmieści się w jego budżecie. W końcu Salesforce oferuje ciekawe możliwości bez potrzeby budowania skomplikowanych, customowych rozwiązań – im lepiej poznasz Platformę, tym łatwiej będzie Ci wyłowić perełki – także wtedy, gdy osiądziesz na projektowej mieliźnie, co w końcu się zdarza. 🙂

Typowe wyzwania w obszarze uprawnień

Na co powinieneś być przygotowany i jak zwykle my sobie z tym radzimy? Oto kilka przykładów.

  1. Obsługiwanie zastępstw.
    Zdarza się, że podczas nieobecności osoby odpowiedzialnej za konkretny obszar sprzedaży czy obsługi, zastępcy chcą mieć szybki i łatwy dostęp do jej klientów. Zmiana właściciela może jednak doprowadzić do zmian w procesach. Rozwiązaniem może być automatyczne przypisywanie terytoriów (z jednym terytorium per handlowiec) lub użycie Account Teams.
  2. Ograniczenie widoczności plików dla konkretnych osób.
    Domyślne ustawienie widoczności pliku to “dla wszystkich z dostępem do rekordu” zaczyna być problematyczne, gdy mowa np. o plikach z ofertami, zawierającymi wrażliwe dane finansowe. Rozwiązaniem jest automatyczne przełączanie File Sharing na Private dla określonej kategorii plików. Trzeba jednak pamiętać, że wówczas pliki będą widoczne tylko dla właściciela (nie działa tutaj hierarchia!).
  3. Raportowanie po wszystkich kontach dla użytkowników Partner Community.
    Włączenie pełnej widoczności kont dla użytkowników Salesforce Community daje teoretycznie duże możliwości raportowe. W praktyce okazuje się bowiem, że ze względów bezpieczeństwa Salesforce nie pozwala raportować użytkownikom External przy włączonej widoczności kont innej niż Private. Rozwiązaniem jest ustawienie widoku Private (plus Sharing Rules).
  4. Ustawienie widoczności dla managerów liniowych.
    W niektórych firmach hierarchia ról nie zawsze odzwierciedla hierarchię managerów liniowych. Dla przykładu: gdy pracujesz w zespole projektowym, Twoim przełożonym w hierarchii jest szef projektu. Ale takie kwestie, jak choćby urlopy czy wynagrodzenie, akceptuje manager liniowy, który nie jest opiekunem projektowym. Jak rozwiązać problem dostępu do Twoich wniosków urlopowych czy wynagrodzeń? Sposobem na to jest skorzystanie z opcji Manager Groups, a następnie dodawanie uprawnień do rekordów poprzez Manual/Apex Sharing.
  5. Ustawienie zakresu widoczności rekordu na podstawie np. statusu.
    Czasami nie chcemy, żeby użytkownicy widzieli wrażliwe dane klientów, których nie obsługują, ale powinni mieć dostęp do publicznych informacji na ich temat, np. NIPu czy adresu. Rozwiązaniem jest duplikacja rekordów i wyświetlanie tylko publicznej wersji.

 

Co odradzać klientowi?

Choć Twoja satysfakcja z pisania zaawansowanych rozwiązań jest oczywiście ważna, to mają one zadowolić przede wszystkim klienta i użytkowników konkretnego systemu. Krótko mówiąc: system ma działać, być przyjazny w obsłudze i łatwy w utrzymaniu. Ogromne znaczenie ma więc słuchanie klienta, rozumienie jego potrzeb i sugerowanie mu najlepszego wyjścia. Czasem oznacza to konieczność wyjaśnienia klientowi, że jego pomysł na rozwiązanie konkretnego problemu niekoniecznie sprawdzi się w praktyce. Do tego może oznaczać wzrost kosztów projektu. Dlatego warto uświadomić klientowi, że jeżeli na coś się nie zgadzasz, robisz to w trosce o komfort korzystania z systemu.

Jakie rozwiązania odradzać klientowi? Oto kilka przykładów.

  • Zawężanie widoku – np. “Chcę widzieć tylko status na cudzych zgłoszeniach”.
    Wymóg trudny do zrealizowania – patrz rozwiązanie piąte z poprzedniego akapitu – zupełnie nieskalowalny dla dużych organizacji. Salesforce nie daje na to gotowego rozwiązania.
  • Ograniczenie możliwości wpisywania informacji zależnie od momentu w życiu – np.”Chcę wpisać konkretne dane tylko podczas tworzenia konta klienta”.
    Można, da się, są przecież reguły walidacji, ale bardzo cierpi na tym UX.
  • Zmiana modelu aktywności – np. “Wszystkie aktywności są sterowane dostępem do rekordów, chyba że…
    Wywołuje to utrudnienia podczas integracji Lightning Sync i Lightning for Outlook.
  • Widoczność różnych pól zależnie od statusu – np. “Chcę widzieć inne pola zależnie od etapu”.
    Złotą odpowiedzą jest Sales Path. Problemy zaczynają się, gdy wyświetlać powinno się więcej niż 5 pól pod statusem.
  • Zwiększenie możliwości udostępniania – np. “Chcę rozszerzyć Account/Opportunity Teams o dostępy do customowych, powiązanych obiektów”.
    To już nieaktualne – kiedyś było niemożliwym rozszerzanie uprawnień w oparciu o Account/Opportunity Memberów, ponieważ nie dało się pisać w oparciu o nich automatyzacji – od miesiąca jest to już możliwe 😉

 

Jak podejść do projektowania uprawnień?

Jak podejść do projektowania uprawnień? Jak zbudować ten model, aby uniknąć zaskoczeń? Dobrze sprawdza się metoda od ogółu do szczegółu.
Na początek upewnij się, czy wiesz, jakie są techniczne możliwości – jako programista lub konsultant Salesforce’a – kontroli dostępu do danych, na różnych poziomach, czyli CRUD i FLS. Mając tę wiedzę, czyli bazę, możesz skutecznie zarządzać uprawnieniami na etapie konkretnego projektu.

Gdy już go zaczynasz, ustal podstawowe CRUD różnych grup biznesowych i określ hierarchię ról. Dzięki temu już na starcie prac będzie jasne, z jakich elementów korzysta klient, a konkretnie – kto będzie z czym pracował. Dodatkowo, ustal też potrzeby związane z Organization Wide Defaults, pamiętając od początku, że jeśli uprawnienia będą zbyt szerokie, potem nie będziemy w stanie ich ograniczyć.

Jak zrobić to dobrze? Drogą wywiadu, dedukcji i naturalnej podejrzliwości szukać osób z najmniejszymi uprawnieniami i w oparciu o nich budować OWD. Dopiero kolejnym etapem powinno być budowanie rozszerzeń za pomocą Sharing Rules i Record Types.

Bądź ostrożny przy projektowaniu Record Level Security dla standardowych obiektów typu Activity, Files czy Approvals!

Co jest niesamowicie istotne – Salesforce się rozwija, musisz więc być na bieżąco ze wszystkimi zmianami. Trailheady, zwłaszcza te z informacjami o kolejnych release, zawierają mnóstwo praktycznych informacji o nowych rozwiązaniach, podanych w bardzo przystępnej formie.

I najważniejsza, już wspomniana zasada – słuchaj klienta, nie przedkładaj własnej wygody nad jego komfort i zadawaj pytania, także sobie! To nie żart! Uważaj na słowa klucze. Jakie to słowa? Ta wiedza przyjdzie z czasem 🙂

 

Zapraszam do obejrzenia mojego wystąpienia z SForce – Poland Salesforce Meetup.

Opowiadałam  jak sprawnie manewrować pomiędzy budżetem, uprawnieniami SF i oczekiwaniami odbiorcy, by dostarczyć klientowi jak najlepsze rozwiązanie.

Autor

  • Anna Wałach
  • Solution Architect
  • Od ponad 4 lat pracuje z Salesforcem, pomagając wdrażać rozwiązania Sales i Service Cloud. Uwielbia zagadnienie optymalizacji Salesforce’a pod proces biznesowy i procesu biznesowego pod Salesforce’a.

Podobał Ci się mój artykuł?

Jeśli tak, zapraszam Cię do grona najlepiej poinformowanych czytelników bloga. Dołącz do naszego newslettera, a nie ominą Cię żadne nowości.