Role
Tworzenie użytkowników, przypisywanie ról i zarządzanie zespołami.
Strona „Zarządzanie rolami: zarządzanie użytkownikami i zespołami" dotyczy obszaru funkcjonalnego oznaczonego jako URL. Istniejące treści są uzupełnione o rzeczywisty przebieg, wymagania wstępne oraz znane ograniczenia. W tenancie istnieją dokładnie dwie role: administrator i pracownik. Nie istnieją granularne uprawnienia modułowe. Zespoły służą wyłącznie do grupowania i nie generują automatycznego przypisywania rozmów ani zadań.
W tenancie istnieją dokładnie dwie role: administrator i pracownik. Administrator zarządza użytkownikami i ustawieniami centralnymi; pracownicy działają w ramach zatwierdzonych obszarów. System z granularnymi uprawnieniami modułowymi nie istnieje. Dlatego zarządzanie rolami nie może być opisane w sposób sugerujący, że poszczególne elementy menu można dowolnie włączać dla każdej osoby.
Zespoły służą do organizacyjnego grupowania. Nie generują one automatycznego przypisywania rozmów ani logiki kolejek. W przypadku przekazywania (handover) również nie ma automatycznego dystrybucji zespołów. Odpowiedzialności należy więc organizować poprzez rzeczywisty proces pracy oraz widoczną skrzynkę odbiorczą na żywo.
Przy tworzeniu lub modyfikacji użytkownika tenanta należy starannie kontrolować adres e-mail, wybraną rolę oraz przypisanie do tenanta. Zmiana roli może zmienić dostęp do możliwości administracyjnych. Po wprowadzeniu zmiany osoba dotknięta zmianą powinna się ponownie zalogować i sprawdzić, czy widoczny jest oczekiwany obszar.
Wiele tenantów jest oddzielanych po stronie serwera. Użytkownik z dostępem do wielu tenantów musi świadomie wybrać aktywnego tenanta. Zespoły i role tenanta nie mogą być rozumiane jako globalne uprawnienia dla innych tenantów. W przypadku błędnej widoczności należy zawsze sprawdzić razem aktywny wybór tenanta i rolę.
Dla strony „Zarządzanie rolami: zarządzanie zalogowanymi osobami i zespołami" wynika stąd: zaimplementowany krótki tekst jest rozszerzany na wiarygodną instrukcję, bez obiecywania funkcji poza potwierdzonym stanem produktu. Kluczowe pozostają zweryfikowane źródła faktów oraz widoczna odpowiedzialność między tenantem a Zentor. W przypadku odstępstw należy zawsze podawać dokładnie ten sam URL, dotkniętego tenanta oraz obserwowany krok.
Przy pracy z „rolami" każdy krok należy najpierw przetestować za pomocą kontrolowanego przypadku testowego. Kluczowe jest, aby widoczne ustawienie, rzeczywisty stan systemu oraz oczekiwany wynik się zgadzały. W przypadku odstępstw przy analizie pomagają dokładna godzina, dotknięty tenant, użyty kanał oraz niezmieniona wiadomość o błędzie. Dane logowania, tokeny oraz treści osobiste nie mogą być przenoszone do zrzutów ekranu ani tekstów wsparcia.