Configuration pouvant être déléguée à des clients internes ou externes
L’application Domain Separation est conçue pour permettre ServiceNow® aux fournisseurs de services de configurer les services qu’ils proposent à leurs clients. Il n’est pas conçu pour permettre à ses clients d’administrer ces services eux-mêmes, à l’exception de quelques domaines détaillés dans cette rubrique.
Vue d'ensemble
Les clients SP peuvent gérer en toute sécurité les données contenues dans leur domaine qui n’ont aucune incidence sur la gestion des licences ou d’autres clients. Par exemple, un client peut créer des rapports ou gérer des éléments de configuration en toute sécurité, mais il ne peut pas le faire en toute sécurité pour personnaliser des champs, des choix, des règles métier et d’autres processus lorsqu’ils peuvent impacter d’autres clients sur la même instance.
Les ServiceNow rôles administratifs du système de base et leurs contrôles d’accès sur la ServiceNow plateforme sont conçus pour une seule équipe d’administrateurs par instance. Par exemple, le rôle domain_admin est accordé à l’une des ressources du SP pour gérer tous les paramètres de domaine de l’instance et créer de nouveaux domaines. Pour toutes les tâches d’administration spécifiques au domaine, les fournisseurs de services doivent créer de nouveaux rôles « administrateur client » et des contrôles d’accès selon les besoins pour accorder un accès spécifique à ses clients.
L’image suivante est une vue d’ensemble des fonctions d’administration courantes dans diverses catégories de ce qu’un client peut faire en toute sécurité.
Autoriser l’accès
- Gestion des données CI dans la CMDB
- Création de rapport
- Mises à jour des données utilisateur existantes ou des nouveaux utilisateurs sans rôles
- Met à jour les enregistrements de données de base existants tels que département, groupe, emplacement, centre de coûts ou les nouveaux groupes sans rôle, ainsi que les nouveaux départements/centres de coûts/emplacements.
Procéder avec prudence
- Éléments de catalogue : pour créer des éléments de catalogue spécifiques au client qui peuvent être mis à jour par le client, deux options peuvent être utilisées conjointement : Domain separation pour les éléments de catalogue (Domain Separation et Service Catalog) permet au propriétaire de l’instance de créer des éléments dans le domaine du client. Le propriétaire de l’instance peut créer un rôle pour permettre aux clients de mettre à jour les champs fiables tels que le prix, la description et les images. Le générateur de catalogue (nouveau dans la version Quebec) donne à l’équipe d’administration du SP la possibilité de créer des modèles d’éléments qui peuvent être distribués en toute sécurité aux clients pour créer de nouveaux éléments dans leur domaine à partir d’une expérience d’interface utilisateur prescriptive.
- Gestion des utilisateurs/groupes : vous pouvez créer en toute sécurité un rôle « administrateur client » qui peut créer et modifier des enregistrements utilisateur, mais l’ajout et la suppression de rôles peuvent affecter la sécurité et la gestion des licences. Le système de base ne permet pas de subdiviser les rôles qu’un client peut accorder en toute sécurité. Il en va de même pour la création et la modification de groupes. Bien que le groupe lui-même puisse être modifié, l’ajout ou la soustraction des rôles doit être contrôlé.
- Flow Designer : ServiceNow Concepteur de flux outil de création utilisé pour créer un processus (workflow) pour les tables. Le rôle flow_designer donne aux clients un accès sans script aux flux de build. Ils peuvent lire et cloner tous les flux dans les domaines situés au-dessus d’eux dans la hiérarchie. Ils peuvent créer et modifier des flux dans leur domaine. Cependant, cela ne peut pas se faire en vase clos. Toute personne susceptible d’influer sur les processus doit être ajoutée à l’équipe d’administration globale pour la gouvernance afin que les processus ne s’annulent pas les uns les autres ou n’entraînent pas d’autres conflits.
Ne pas donner accès
- Structure d’un champ de choix : les valeurs de champ de choix sont stockées dans la table sys_choice et regroupées en fonction de la table, du domaine et de la langue.
Par exemple, le champ État d’une tâche est disponible pour toutes les tables qui étendent une tâche. Cela signifie que chaque table peut avoir ses propres valeurs, ces valeurs peuvent être multipliées par domaine et les valeurs de domaine peuvent être multipliées par langue.
Toutes les valeurs d’État dans toutes les tables, domaines et langues sont considérées comme les valeurs du champ État .
- Mode de fonctionnement des modifications apportées aux champs de choix : lorsqu’un champ de choix est mis à jour, une charge utile est créée avec toutes les valeurs de ce champ (tables, domaines, langues). Lorsque vous installez cette charge utile sur une instance, toutes les valeurs existantes pour le champ sont supprimées et les nouvelles valeurs sont chargées. Cela garantit qu’il n’y a pas d’entrées en double ou de valeurs restantes qui ne sont plus valides.
Pour cette raison, il est impossible de donner à un client dans une instance séparée par domaine la possibilité de mettre à jour directement les champs de choix, car cela affecterait l’ensemble de l’instance. En outre, vous ne pouvez pas mettre à jour les choix directement dans une instance de production, car tous les ensembles de mises à jour importés ayant une incidence sur ce champ remplaceraient les choix existants. Dans certains cas, les champs de choix peuvent entraîner eux-mêmes des processus, qui ne fonctionneraient pas si un client venait à modifier ces champs.
Pour en savoir plus, consultez :
- Exploring user administration
- Créer une règle ACL
- Parcours d’apprentissage du fournisseur de services sur ServiceNow University
- Domain Separation pour les fournisseurs de services
- Concepts des fournisseurs de services
- Prise en charge de Domain Separation par les applications
- Notes de publication de Domain Separation