Concept : rapports d’audit des exceptions

Workday vous recommande de tester les changements apportés aux processus de gestion dans un locataire de pré production avant de les faire migrer vers votre locataire de production. Après avoir mis à jour un processus de gestion, exécutez le rapport

Audit des exceptions de processus de gestion

pour rechercher toutes les définitions de processus de gestion comportant des erreurs critiques.

Lorsque vous lancez un événement de processus de gestion, Workday vérifie la définition de processus de gestion pour déterminer si une exception persistante existe dans la définition.

Lorsque vous mettez à jour une définition de processus de gestion de manière à créer une erreur dans la définition, Workday :

Renvoie l’exception immédiatement.
Empêche l’exécution du processus de gestion.

Pour offrir une couche de sécurité supplémentaire, Workday exécute un traitement en arrière-plan toutes les heures pour repérer et rendre persistantes toutes les exceptions aux définitions de processus de gestion. Ces exceptions incluent les exceptions causées par des changements en dehors de la définition du processus de gestion elle-même.

Exemple : vous supprimez un groupe de sécurité d’une politique de sécurité de processus de gestion sans retirer le groupe de la définition de processus de gestion correspondante, ce qui génère une exception. Si vous ne modifiez pas la définition de processus de gestion ou exécutez le rapport

Audit des exceptions de processus de gestion

pour repérer l’exception, le traitement en arrière-plan :

Renvoie l’exception.
Vous empêche de lancer le processus de gestion jusqu’à ce que vous ayez corrigé le problème.

Si un processus de gestion est défectueux, Workday envoie automatiquement une tâche

Corriger un processus de gestion

aux administrateurs des processus de gestion et fournit un lien pour corriger la définition du processus de gestion.

Les exceptions de sécurité se produisent généralement lorsqu’une configuration de sécurité valide fait l’objet d’un changement dans la politique de sécurité, ce qui rend certaines affectations d’accès non valides. Les causes possibles sont lorsque vous activez un changement de politique de sécurité en attente pour lequel :

Avant de retirer un groupe de sécurité d’une politique de sécurité de processus de gestion, retirez le groupe des différents processus de gestion dans chaque organisation pour laquelle une version personnalisée est définie. Toutefois :

Si vous ne connaissez pas tous les endroits où vous avez utilisé un groupe de sécurité.
Des processus sont déjà en cours d'exécution.

Vous pouvez toujours modifier la politique. Workday affiche un avertissement indiquant que le changement entraînera une exception.

Le rapport

Audit des exceptions de sécurité

indique tout domaine problématique. Workday explique le problème et la solution pour chaque exception. En règle générale, tout ce que vous avez à faire est de retirer le groupe de sécurité non valide de la politique ou du processus de gestion.

Pour les processus de gestion déjà démarrés, réaffectez l’étape qui est acheminée à un utilisateur non valide ou retirez le processus. Dans les deux cas, modifiez la définition de processus de gestion de cette organisation pour ne spécifier que des groupes de sécurité valides.

Vous pouvez également utiliser le rapport

Audit des exceptions de sécurité

pour rechercher des groupes de sécurité intersectionnels qui incluent des groupes de sécurité fondés sur des organisations fondées sur des types d’organisations qui ne sont pas des organisations réelles.

Lorsque des groupes de sécurité inattendus sont configurés dans la politique de processus de gestion pour ces actions de la politique de sécurité, nous affichons une entrée d’exception de sécurité dans les onglets

Exceptions de politique de sécurité de processus de gestion

et

Exceptions de groupe de sécurité

 :

Approbation ad hoc
Refuser
Refuser (service Web)
Renvoi manuel
Demander une réaffectation

Ainsi, la personne appropriée a accès aux actions autorisées des processus de gestion en validant les groupes de sécurité dans les actions de la politique de sécurité des processus de gestion.

Exécutez le rapport

Audit des exceptions de champs calculés

pour revalider vos champs calculés et répertorier les erreurs. Vous pouvez tester les erreurs et les exceptions à l’aide de la fonction Évaluer une expression, en effectuant l’action appropriée.

Si un protocole de transport d’intégration vous oblige à chiffrer le fichier sortant et que vous choisissez de ne pas chiffrer la sortie, vous pouvez enregistrer le Créateur d’interfaces Entreprise. Toutefois, vous ne pouvez pas l’exécuter tant que l’administrateur de la sécurité n’a pas approuvé l’exception. Une fois que l’administrateur de la sécurité a remplacé cette exigence en :

Affichant le Créateur d’interfaces Entreprise ou le système d’intégration dans le rapport
Audit des exceptions d’intégration
.
Sélectionnant
Commutateur Approuver un transport non chiffré
comme action connexe.

Vous pouvez exécuter le Créateur d’interfaces Entreprise un nombre illimité de fois. Toutefois, si vous modifiez l’EIB plus tard, l’administrateur de la sécurité devra approuver le remplacement.

Vous pouvez également utiliser le rapport

Audit des exceptions d’intégration

pour :

Désignez les EIB qui utilisent les transformations
XmlToCSV
et
XmlToExcel
.
Définissez
CSV
comme
autre format de sortie
.

Pour rechercher les Créateurs d’interfaces Entreprise planifiés qui ne peuvent pas être lancés en raison d’une sécurité insuffisante, accédez au rapport

Audit des exceptions de Créateurs d’interfaces Entreprise futurs planifiés

. Le rapport dresse la liste des EIB qui ne sont pas exécutables par l’utilisateur planificateur. Vous pouvez changer la sécurité de l’utilisateur planificateur ou transférer la propriété à un autre utilisateur. Pour transférer la propriété, sélectionnez

Traitements futurs planifiés

Transférer la propriété

dans le menu des actions connexes de la demande.

Exécutez le rapport

Audit des rôles affectés non pourvus

pour répertorier les rôles non pourvus pour des organisations et d’autres éléments avec affectation de rôles activée. Les rôles marqués

« Masquer si non affectés »

dans la tâche

Mettre à jour des rôles affectables

ne s'affichent pas dans ce rapport.

Il est normal que les organisations inactives aient des rôles non pourvus.

Workday fournit les rapports d’audit personnalisés avec exceptions de rapports suivants :

Custom Report Exception Audit
, qui vous permet de valider les définitions du rapport. Workday affiche le propriétaire du rapport, la gravité de l’erreur et la description ou la solution du problème. Une sortie de rapports vide indique qu’il n’y a aucune erreur dans vos rapports.
Custom Report Exceptions by Owner
, qui affiche les exceptions de rapports personnalisés par propriétaire de rapport. Workday affiche les exceptions qui incluent :
Les rapports avec des propriétaires dont l’emploi a pris fin.
Les rapports activés comme worklets, mais non disponibles dans les tableaux de bord.
Les rapports temporaires dont la date de suppression est dépassée.
Des rapports non partagés.
Ce rapport comporte des éléments marqués comme Ne pas utiliser.
Custom Reports I Peut Run Exception Audit
 , qui affiche les rapports personnalisés que vous pouvez exécuter et qui comportent des exceptions. Workday affiche le propriétaire du rapport, la gravité de l’erreur et la description ou la solution du problème. Une sortie de rapport vide indique qu’il n’y a aucune erreur dans les rapports que vous pouvez exécuter.
Audit des exceptions de rapports personnalisés dans les menus
, qui vous permet de voir les erreurs dans les entrées de la tâche
Mettre à jour des rapports personnalisés dans les menus
. Une sortie de rapports vide indique qu’il n’y a aucune erreur dans vos rapports.

Workday fournit également les rapports Audit des exceptions suivants :