Séparation de domaine et Gestion de la durabilité opérationnelle

Gestion de la durabilité opérationnelle prend en charge Séparation de domaine. Séparation de domaine vous permet de séparer les données, les processus et les tâches administratives en groupes logiques appelés domaines. Vous pouvez contrôler plusieurs aspects de cette séparation, notamment les utilisateurs qui peuvent voir les données et y accéder.

Niveau de prise en charge : basique

• Logique métier : garantit que les données parviennent au bon domaine pour les cas d'utilisation du fournisseur de service de l'application.
• L'application prend en charge Séparation de domaine lors de l'exécution. Séparation de domaine inclut la séparation à partir de l'interface utilisateur, des clés de cache, du reporting, des déploiements et des agrégations.
• Le propriétaire de l'instance doit configurer l'application de sorte qu'elle fonctionne sur plusieurs locataires.

Exemple de cas d'utilisation : lorsqu'un fournisseur de service (SP) utilise la messagerie instantanée pour répondre au message d'un locataire-client, le client doit pouvoir afficher la réponse du SP.

Pour en savoir plus sur les niveaux de prise en charge, consultez la rubrique Prise en charge de Séparation de domaine par les applications.

Vue d’ensemble de Séparation de domaine

Séparation de domaine est utile pour les utilisateurs qui :

• Appliquez la ségrégation absolue des données entre les entités d’entreprise (séparation des données).
• Personnalisez les définitions de processus business et les interfaces utilisateur pour chaque domaine (administration déléguée).
• Gérez les processus globaux et le reporting global en une seule instance.

Ces utilisateurs peuvent choisir d’étendre ou de réduire le champ d’application de domaine pour afficher ou masquer les données d’autres domaines.

Remarque :

Les utilisateurs ont toujours accès aux données des domaines qui leur ont été explicitement accordés par la visibilité de domaine.

Comment fonctionne Séparation de domaine dans Gestion de la durabilité opérationnelle

Bien que la Gestion de la durabilité opérationnelle séparation des données soit prise en charge, la séparation de la logique et du processus n’est pas entièrement prise en charge. De nombreux types d’enregistrements sont générés automatiquement dans l’application par le Gestion de la durabilité opérationnelle biais des processus utilisateur. Intégrations avec Gestion des portefeuilles de projets et GRC: Metrics peuvent créer et associer des données automatiquement. Pour les enregistrements générés automatiquement et manuellement, le domaine de l’enregistrement est le même que le domaine de l’utilisateur responsable de la création ou de la génération des enregistrements. Les utilisateurs doivent s’assurer qu’ils créent et génèrent des enregistrements au bon niveau de domaine afin qu’ils soient visibles par le bon ensemble d’utilisateurs.

Par exemple, supposons que vous ayez des domaines qui ressemblent à :

• Global
• HAUT
  • Domaine A
  • Domaine B

Si vous avez des objectifs ESG, des sujets importants et des cibles que vous souhaitez faire évaluer par les utilisateurs dans les domaines A et B, les objectifs ESG, les sujets importants et les cibles doivent être créés manuellement au niveau mondial. Si des objectifs, des sujets importants et des cibles ESG sont créés dans le domaine B, vous ne pourrez pas les utiliser dans le domaine A en raison de l’indexation.

Si vous avez des objectifs ESG, des rubriques importantes et des cibles que vous souhaitez faire évaluer par les utilisateurs dans le domaine principal et le domaine A, vous pouvez créer le risque ou le contrôle dans le domaine A. À moins que les objectifs ESG, les rubriques importantes et les cibles ne se trouvent dans le domaine Global, les utilisateurs ne doivent pas affecter de risques ou de contrôles dans un domaine supérieur aux utilisateurs dans un domaine inférieur. Dans l’exemple donné, si vous avez un objectif ESG dans le domaine Principal, vous ne devez pas l’affecter au responsable de programme dans les domaines A ou B, car ces utilisateurs n’auraient pas accès à cet objectif.

Tables séparées de domaine

Voici la liste des tables séparées par domaine :

• Divulgation
• Résumé de la divulgation
• Résumé de l'activité de l'objectif
• Couleur de la carte thermique
• Définition de mesure composite à citation
• Définition de mesure composite à Objectif
• Définition de mesure composite à cible
• Contrôle à Objectif
• Objectif du contrôle à Objectif
• Citation à Divulgation
• Mesure à Divulgation
• Définition de la mesure à Divulgation
• Entité par rapport à Objectif
• Objectif par rapport à Citation
• Objectif par rapport à Divulgation
• Enjeu de matérialité à Objectif
• Mesure à Citation
• Définition de mesure à Citation
• Définition de mesure à Objectif
• Définition de mesure à Cible
• Mesure à Objectif
• Mesure à Cible
• Politique à Objectif
• Risque à Objectif
• Définition du risque à Objectif
• Enjeu de matérialité

Pour plus d’informations sur ces tables, reportez-vous à la section Composants installés avec Gestion de la durabilité opérationnelle (anciennement Gestion ESG).

Cas d'utilisation

Les données ESG peuvent être séparées des données d’autres départements. Chaque domaine d’activité utilisant l’application Gestion de la durabilité opérationnelle peut avoir des données distinctes qui ne peuvent pas être partagées avec d’autres départements. Par conséquent, chaque département peut avoir ses propres objectifs, cibles, sujets matériels, etc. Lorsqu’il examine un objectif du domaine ESG, l’utilisateur peut choisir d’élargir le périmètre de domaine pour afficher les valeurs du domaine ESG ou de réduire le périmètre de domaine pour afficher uniquement les objectifs qui correspondent au domaine ESG. Par défaut, Séparation de domaine ajoute un champ de domaine aux tables Tâche [task] et Éléments de configuration [cmdb_ci] et à leurs extensions. Vous pouvez étendre Séparation de domaine à toutes les nouvelles tables que vous créez en ajoutant un champ sys_domain à la définition de dictionnaire de la table. Par défaut, le système sépare uniquement les tables de plateforme et d’application de base de référence par domaine, le cas échéant.

Remarque :

ServiceNow® déconseille les tables de plateforme de séparation de domaine, telles que les tables portant le préfixe sys_, telles que les tables Entrée de dictionnaire [sys_dictionary] et Remplacement d’entrée de dictionnaire [sys_dictionary_override], car cela peut produire des résultats inattendus.

Dans ce cas d’utilisation, les scripts clients, les règles métier, les workflows, les processus, etc., peuvent être séparés par domaine. Bien que le comportement proposé avec Séparation de domaine fournisse une prise en charge de la mutualisation, celle-ci est toujours contenue dans une seule instance. Cela signifie que certaines propriétés globales, certaines données globales et certains processus globaux sont partagés entre tous les domaines. Par exemple, l’option « Se souvenir de moi » du système sur la page de connexion est globale et ne peut pas être spécifiée par domaine. Si vous avez besoin d’une séparation complète et totale de toutes les propriétés système et que vous n’avez pas besoin de rapports ou de processus globaux, des instances distinctes sont la meilleure option.

Information associée

• Séparation de domaine pour les fournisseurs de services