Configuration pouvant être déléguée à des clients internes ou externes

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 4 minutes de lecture

    • Séparation de domaine est conçue pour permettre ServiceNow® aux fournisseurs de services (SP) de configurer les services qu’ils offrent à leurs clients. Il n’est pas conçu pour permettre à leurs clients d’administrer eux-mêmes ces services, sauf dans quelques domaines que cette rubrique détaille.

    Vue d'ensemble

    Il est sûr pour les clients SP, par eux-mêmes, de gérer les données contenues dans leur domaine qui n’affectent pas les licences ou les autres clients. Par exemple, un client peut créer de nouveaux rapports ou gérer des éléments de configuration en toute sécurité, mais il ne peut pas personnaliser des champs, des choix, des règles métier et d’autres processus dans lesquels ils peuvent avoir un impact sur d’autres clients sur la même instance.

    Les ServiceNow rôles d’administration 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 pour créer de nouveaux domaines. Pour toutes les tâches d’administration spécifiques à un domaine, le SP doit 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 différentes catégories de ce qui peut être fait en toute sécurité pour un client. Niveaux d’accès autorisés pour les clients des fournisseurs de services

    Icône verte Peut donner accès

    Exemples :
    • Gestion des données CI dans la CMDB
    • Création de rapport
    • Mises à jour des données utilisateur existantes ou nouveaux utilisateurs sans rôles
    • Mises à jour des enregistrements de données de base existants tels que département, groupe, emplacement, centre de coûts ou nouveaux groupes sans rôles, et nouveaux départements/centres de coûts/emplacement.

    Icône jaune Procédez avec prudence

    Exemples :
    • É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 ensemble : Séparation de domaine pour les éléments de catalogue (Séparation de domaine et Catalogue de services) 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 des champs sécurisés tels que le prix, la description et les images. Le générateur de catalogue (nouveau dans la version Quebec) donne à l’équipe d’administrateurs 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 : il est prudent de créer un rôle « administrateur client » qui peut créer et modifier des enregistrements d’utilisateurs, mais l’ajout et la suppression de rôles peuvent affecter la sécurité et la gestion des licences. Il n’y a aucun moyen dans le système de base de subdiviser les rôles qui sont sûrs pour qu’un client puisse les accorder. 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 de rôles doit être contrôlé.
    • Flow Designer: ServiceNow Studio de workflow est l’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 version. Ils peuvent lire et cloner tous les flux dans les domaines au-dessus d’eux dans la hiérarchie. Ils peuvent créer et modifier des flux dans leur domaine. Cela ne peut toutefois pas se faire en vase clos. Toute personne susceptible d’affecter le processus doit être ajoutée à l’équipe d’administration globale pour la gouvernance afin que les processus ne s’annulent pas ou ne provoquent pas d’autres conflits.

    Icône rouge Ne pas donner accès

    Comprendre le fonctionnement des champs de choix est utile pour comprendre pourquoi seule l’équipe d’administrateurs SP devrait les gérer.
    • 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 : Table, Domaine et 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 de l’état dans toutes les tables, domaines et langues sont considérées comme les valeurs du champ État .

    • Fonctionnement des changements apportés 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 les ensembles de mises à jour importés qui affectent ce champ remplaceraient les choix existants. Dans certains cas, les champs de choix peuvent piloter les processus eux-mêmes, qui s’interrompraient si un client devait modifier ces champs.

    Pour en savoir plus, consultez :