Multi-Team-Umgebungen ermöglichen es Unternehmen, zunehmend komplexe Sicherheitskonfigurationen in Blue Prism® zu modellieren, indem die bestehenden rollenbasierten Zugriffskontrollen erweitert werden, um detailliertere Konfigurationen zu erstellen. Mit diesen Funktionen können Unternehmen Blue Prism Assets, wie Geschäftsobjekte und Laufzeitressourcen, besser zwischen mehreren Teams innerhalb einer Blue Prism Umgebung teilen, denn Berechtigungen können nicht nur basierend auf dem Typ des Assets, sondern auch basierend auf der hierarchischen Struktur der Assets zugewiesen werden.

Beispiel: Benutzer, die Mitglieder eines Teams sind, erhalten vollständigen Zugriff auf bestimmte Geschäftsobjekte, können andere Geschäftsobjekte aber nur anzeigen oder ausführen. Dies könnte sinnvoll für Assets sein, die von mehreren Teams verwendet werden.

Dank Multi-Team-Umgebungen unterstützt Blue Prism vielfältige und komplexe Organisationsstrukturen, damit mehrere Teams unabhängig arbeiten und bestimmte Ressourcen in einer zentralen Umgebung gemeinsam nutzen können.

Die nachfolgende Liste zeigt, auf welche Bereiche des Blue Prism Clients sich Multi-Team-Umgebungen auswirken:

• Startseite – Die Daten, die auf der Startseite angezeigt werden, werden nicht durch die Zugriffsrechte gefiltert, die für Gruppen gelten.
• Studio – Hier verwalten Benutzer mit den entsprechenden Berechtigungen die Zugriffsrechte für Prozessgruppen und Objektgruppen.
• Kontrolle – Benutzer erhalten eine benutzerspezifische Anzeige des Kontrollraums, damit sie nur die Prozesse und Ressourcen sehen und verwenden können, die ihrer Rolle entsprechen. Dazu zählt nicht der Bereich „Warteschlangenmanagement“ – Benutzer mit Zugriff auf diesen Bereich können Informationen für jede gewöhnliche Warteschlange in der Umgebung sehen.
• Bei den aktiven Warteschlangen sehen Benutzer nur dann eine Warteschlange, wenn sie eine Ausführungsberechtigung für den Prozess haben, der die Warteschlange verarbeitet, und eine Kontrollberechtigung für alle Zielressourcen dieser Warteschlange.
• Analytik – Die Daten, die auf den Dashboard-Kacheln angezeigt werden, werden nicht durch die Zugriffsrechte gefiltert, die für Gruppen gelten.
• Releases – Nur Elemente, bei denen der Benutzer zugriffsberechtigt ist, können in einen Release oder ein Paket aufgenommen werden.
• System – Die folgenden Bereiche des System-Managers wurden für Multi-Team-Umgebungen aktualisiert:
  • Ressourcen – Hier verwalten Benutzer mit den entsprechenden Berechtigungen Zugriffsrechte für Laufzeitressourcen-Gruppen.
  • Audit (Sitzungslogs) – Prozess-Logs und Objekt-Logs unterliegen den Berechtigungen des angemeldeten Benutzers – der Benutzer kann nur die Logs der Elemente sehen, auf die er gemäß seiner Rolle Zugriff hat. Audit-Logs werden nicht durch die Zugriffsrechte gefiltert, die für Gruppen gelten.

Die Vorgänge „Referenzen finden“, „Anzeigen“ und „Vergleichen“ werden auch aktualisiert, sodass sie nur Objekte zurückgeben, auf die der Benutzer Zugriff hat.

Sicherheit auf Grundlage der hierarchischen Gruppenmitgliedschaft

Wenn keine Berechtigungen auf Gruppenebene definiert sind, haben Benutzer mit Berechtigungen für einen bestimmten Elementtyp (z. B. Prozesse) die gleichen Berechtigungen für jedes Element dieses Typs im System.

Wenn Sie die Berechtigungen für eine Gruppe von Prozessen, Objekten oder Ressourcen beschränken, können die von den Benutzerrollen definierten Berechtigungen konfiguriert werden, um die erforderlichen Zugriffsrechte auf die Elemente in der Gruppe zu vergeben.

Berechtigungen, die auf Gruppenebene gelten, können Benutzern keine Zugriffsrechte gewähren, die über ihre Rolle hinausgehen. Wenn zum Beispiel eine Rolle einen Benutzer dazu berechtigt, Prozesse zu bearbeiten, kann diese Berechtigung für eine Gruppe entfernt werden. Wenn eine Rolle einen Benutzer nicht dazu berechtigt, Prozesse zu löschen, kann diese Berechtigung für diese Rolle nicht auf Gruppenebene erteilt werden.