Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Vous pouvez configurer les comportements en cascade pour une relation un-à-plusieurs pour préserver l’intégrité des données et automatiser les processus d’entreprise. L’API web et le Kit de développement logiciel (SDK) pour .NET prennent en charge la configuration du comportement en cascade.
Utiliser l’API web pour configurer le comportement en cascade
Lorsque vous utilisez l’API web, vous définissez une relation un-à-plusieurs à l’aide du type d’entité OneToManyRelationshipMetadata. Cette définition inclut le nom de la table d'intersection à créer et la manière dont la relation doit apparaître dans l’application en utilisant le type complexe AssociatedMenuConfiguration, le type complexe Label et le type complexe LocalizedLabel.
Pour plus d’informations, consultez Créer une relation un-à-plusieurs à l’aide de l’API web.
Utiliser le Kit de développement logiciel (SDK) pour .NET pour configurer le comportement en cascade
Lorsque vous utilisez les classes CreateOneToManyRequest ou UpdateRelationshipRequest, incluez une instance de la classe OneToManyRelationshipMetadata dans le corps de la requête. Dans la CascadeConfiguration propriété de cette classe, utilisez la CascadeConfiguration classe.
La classe CascadeConfiguration ou le type complexe CascadeConfiguration contient les propriétés représentant des actions qui peuvent être effectuées sur la table référencée dans la relation un-à-plusieurs. Une des valeurs de l’énumération de type CascadeType peut être attribuée à chaque propriété.
| Value | Étiquette de l’application | Description |
|---|---|---|
| Actif | Cascade active | Effectuer l’action sur tous les enregistrements de table de référencement actifs associés à l’enregistrement de table référencé. |
| Cascade | Tout en cascade | Effectuer l’action sur tous les enregistrements de table de référencement associés à l’enregistrement de table référencé. |
| NoCascade | Sans mise en cascade | Ne rien faire. |
| RemoveLink | Supprimer le lien | Supprimer la valeur de la colonne de référencement pour tous les enregistrements de table de référencement associés à l’enregistrement de table référencé. |
| Restreindre | Restreindre | Empêchez la suppression de l'enregistrement de table référencé lorsqu'il existe des tables qui le référencent. |
| UserOwned | Cascade propriétaire | Effectuer l’action sur tous les enregistrements de table de référencement détenus par le même utilisateur que l’enregistrement de table référencé. |
Enregistrements actifs pris en compte pour l’action en cascade
Les actions en cascade sur les enregistrements actifs incluent uniquement les enregistrements qui ont un code d’état actif. Les codes d’état suivants pour ces tables sont considérés comme actifs pour les actions en cascade. Différentes étiquettes (autres que Active) peuvent être utilisées pour ce code d’état dans différentes tables. Tout code d’état ou d’état personnalisé avec des valeurs autres que celles du tableau suivant n’est pas traité en tant qu’enregistrement actif à des fins en cascade.
| Nom de la table | Code d’état 0 | Code d’état 1 | Code d’état 2 | Code d’état 3 |
|---|---|---|---|---|
| Compte | x | |||
| BulkOperation | x | |||
| BulkOperation | x | |||
| CampaignResponse | x | |||
| Contact | x | |||
| Courriel | x | |||
| Télécopie | x | |||
| Incident | x | |||
| Résolution d'incident | x | |||
| Facture | x | |||
| Prospect | x | |||
| Lettre US | x | |||
| Opportunité | x | |||
| FermetureOpportunité | x | |||
| OrderClose | x | |||
| Appel téléphonique | x | |||
| SalesOrder | x | |||
| Tâche | x | |||
| Toutes les tables personnalisées et activités personnalisées | x | |||
| Citations | x | |||
| Contrat | x | |||
| Rendez-vous | x | |||
| Rendez-vous de service | x | |||
| RecurringAppointmentMaster | x |
Le SDK pour la classe .NET CascadeConfiguration ou l’API web CascadeConfiguration, type complexe contient les propriétés suivantes représentant les actions que vous pouvez effectuer sur la table référencée dans la relation un-à-plusieurs.
| Action | Description | Options valides |
|---|---|---|
| Affecter | Modifiez le propriétaire de l’enregistrement de table référencé et/ou l’unité commerciale. | Actif Cascade NoCascade UserOwned |
| Retirer | Supprimez l’enregistrement de table référencé. Remarque : les options de cette action sont limitées. | Cascade RemoveLink Restreindre |
| Fusionner | Fusionnez l’enregistrement avec un autre enregistrement. Remarque : pour les tables référencées qui peuvent être fusionnées, Cascade est la seule option valide. Dans les autres cas, utilisez NoCascade. | Cascade NoCascade |
| Redéf. parenté | Consultez À propos de l’action Redéfinir la parenté ultérieurement. | Actif Cascade NoCascade UserOwned |
| Partager | Lorsque l’enregistrement de table référencé est partagé avec un autre utilisateur. | Actif Cascade NoCascade UserOwned |
| Annuler le partage | Lorsque le partage est supprimé pour l’enregistrement de table référencé. | Actif Cascade NoCascade UserOwned |
Note
Les actions Assign, Delete, Merge et Reparent ne s’exécutent pas dans les situations suivantes :
- Si l’enregistrement parent d’origine et l’action demandée contiennent les mêmes valeurs. Exemple : Tentative de déclenchement d’une affectation et choix d’un contact qui est déjà propriétaire de l’enregistrement
- Tentative d’exécution d’une action sur un enregistrement parent qui exécute déjà une action en cascade
Note
Lors de l’exécution d’une affectation, tous les workflows ou règles métier actuellement actifs sur les enregistrements sont automatiquement désactivés lorsque la réaffectation se produit. Le nouveau propriétaire de l’enregistrement devra réactiver le workflow ou la règle métier s’il souhaite continuer à l’utiliser.
À propos de l’action Attribuer
Lorsque vous mettez à jour l’enregistrement parent, l’action d’attribution permet de répercuter en cascade le propriétaire, la division propriétaire ou les successeurs du propriétaire et de la division sur tous les enregistrements enfants.
La propriété de l’enregistrement autorisé entre les divisions n’est pas activée
Lorsque l’autorisation de propriété d’enregistrement entre les unités commerciales n’est pas activée, vous ne pouvez pas mettre à jour explicitement la colonne de l’unité commerciale propriétaire lors de la modification du propriétaire de l’enregistrement. La liste suivante montre les comportements en cascade lorsque vous mettez à jour le propriétaire de l’enregistrement du parent.
Si vous mettez à jour le propriétaire :
- Comportement d’affectation en cascade par défaut (tout en cascade)
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- La division de l’enregistrement est mise à jour vers la division du nouveau propriétaire
- Le propriétaire des enregistrements enfants est mis à jour vers le nouveau propriétaire
- La division des enregistrements enfants est mise à jour vers la division du nouveau propriétaire
- Affectation en cascade définie sur Aucun
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- La division de l’enregistrement est mise à jour vers la division du nouveau propriétaire
- Le propriétaire des enregistrements enfants ne met pas à jour (aucune cascade)
- L'unité commerciale des enregistrements enfant ne se met pas à jour automatiquement (absence de cascade).
La propriété de l’enregistrement autorisé entre les divisions est activée
Quand autoriser la propriété d'enregistrement entre les unités commerciales est activé, vous pouvez mettre à jour explicitement la colonne de l'unité commerciale propriétaire lors du changement de propriétaire de l'enregistrement. Ce qui suit répertorie les comportements en cascade lorsque le propriétaire et/ou la division de l’enregistrement parent est mis à jour.
Définissez AlwaysMoveRecordToOwnerBusinessUnit dans les paramètres de base de données d’environnement ou à l’aide de l’outil OrgDBOrgSettings pour Microsoft Dynamics CRM.
Si vous mettez à jour le propriétaire :
AlwaysMoveRecordToOwnerBusinessUnit = true (par défaut)
- Comportement d’affectation en cascade par défaut (tout en cascade)
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- La division de l’enregistrement est mise à jour vers la division du nouveau propriétaire
- Le propriétaire des enregistrements enfants est mis à jour vers le nouveau propriétaire
- La division des enregistrements enfants est mise à jour vers la division du nouveau propriétaire
- Affectation en cascade définie sur Aucun
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- La division de l’enregistrement est mise à jour vers la division du nouveau propriétaire
- Le propriétaire des enregistrements enfants ne met pas à jour (aucune cascade)
- L'unité commerciale des enregistrements enfant ne se met pas à jour automatiquement (absence de cascade).
- Comportement d’affectation en cascade par défaut (tout en cascade)
Si vous mettez à jour la division :
AlwaysMoveRecordToOwnerBusinessUnit = true (par défaut)
- Comportement d’affectation en cascade par défaut (tout en cascade)
- Le propriétaire de l’enregistrement ne met pas à jour
- La division de l’enregistrement est mise à jour vers la nouvelle division
- Le propriétaire des enregistrements enfants n’est pas mis à jour
- La division des enregistrements enfants est mise à jour vers la nouvelle division
- Affectation en cascade définie sur Aucun
- Le propriétaire de l’enregistrement ne met pas à jour
- La division de l’enregistrement est mise à jour vers la nouvelle division
- Le propriétaire des enregistrements enfants n’est pas mis à jour
- La division des enregistrements enfants n’est pas mise à jour
- Comportement d’affectation en cascade par défaut (tout en cascade)
Si vous mettez à jour le propriétaire et la division :
AlwaysMoveRecordToOwnerBusinessUnit = true (par défaut)
- Comportement d’affectation en cascade par défaut (tout en cascade)
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- Mettre à jour l’unité commerciale d’enregistrement vers une nouvelle unité commerciale
- Le propriétaire des enregistrements enfants est mis à jour vers le nouveau propriétaire
- La division des enregistrements enfants est mise à jour vers la nouvelle division
- Affectation en cascade définie sur Aucun
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- Mettre à jour l’unité commerciale d’enregistrement vers une nouvelle unité commerciale
- Le propriétaire des enregistrements enfants n’est pas mis à jour
- Ne mettez pas à jour l’unité commerciale des enregistrements enfants
- Comportement d’affectation en cascade par défaut (tout en cascade)
Modifier les comportements en cascade à l’aide de OrgDBSettings AlwaysMoveRecordToOwnerBusinessUnit
Si vous définissez AlwaysMoveRecordToOwnerBusinessUnit sur false, l’unité commerciale des enregistrements appartenant à l’utilisateur n’est pas déplacée vers l’unité commerciale du nouvel utilisateur.
Définissez AlwaysMoveRecordToOwnerBusinessUnit dans les paramètres de base de données d’environnement ou à l’aide de l’outil OrgDBOrgSettings pour Microsoft Dynamics CRM.
Si vous mettez à jour le propriétaire :
AlwaysMoveRecordToOwnerBusinessUnit = faux
- Comportement d’affectation en cascade par défaut (tout en cascade)
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- Ne mettez pas à jour l’unité commerciale d’enregistrement
- Le propriétaire des enregistrements enfants est mis à jour vers le nouveau propriétaire
- Ne mettez pas à jour l’unité commerciale des enregistrements enfants
- Affectation en cascade définie sur Aucun
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- Ne mettez pas à jour l’unité commerciale d’enregistrement
- Le propriétaire des enregistrements enfants n’est pas mis à jour
- Ne mettez pas à jour l’unité commerciale des enregistrements enfants
- Comportement d’affectation en cascade par défaut (tout en cascade)
Si vous mettez à jour la division :
AlwaysMoveRecordToOwnerBusinessUnit = faux
- Comportement d’affectation en cascade par défaut (tout en cascade)
- Le propriétaire de l’enregistrement ne met pas à jour
- La division de l’enregistrement est mise à jour vers la nouvelle division
- Le propriétaire des enregistrements enfants n’est pas mis à jour
- La division des enregistrements enfants est mise à jour vers la nouvelle division
- Affectation en cascade définie sur Aucun
- Le propriétaire de l’enregistrement ne met pas à jour
- La division de l’enregistrement est mise à jour vers la nouvelle division
- Le propriétaire des enregistrements enfants n’est pas mis à jour
- La division des enregistrements enfants n’est pas mise à jour
- Comportement d’affectation en cascade par défaut (tout en cascade)
Si vous mettez à jour le propriétaire et la division :
AlwaysMoveRecordToOwnerBusinessUnit = faux
- Comportement d’affectation en cascade par défaut (tout en cascade)
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- Mettre à jour l’unité commerciale d’enregistrement vers une nouvelle unité commerciale
- Le propriétaire des enregistrements enfants est mis à jour vers le nouveau propriétaire
- La division des enregistrements enfants est mise à jour vers la nouvelle division
- Affectation en cascade définie sur Aucun
- Le propriétaire de l’enregistrement est mis à jour vers le nouveau propriétaire
- Mettre à jour l’unité commerciale d’enregistrement vers une nouvelle unité commerciale
- Le propriétaire des enregistrements enfants n’est pas mis à jour
- Ne mettez pas à jour l’unité commerciale des enregistrements enfants
- Comportement d’affectation en cascade par défaut (tout en cascade)
Note
Lorsque AlwaysMoveRecordToOwnerBusinessUnit = false
Privilèges requis :
- Le privilège du propriétaire de l’enregistrement parent est validé. Lorsque vous mettez à jour le propriétaire ou l’unité commerciale, la validation vérifie que le propriétaire a le privilège pour l’unité commerciale avant d’autoriser les mises à jour.
- Toutefois, le privilège de propriétaire du dossier pour les dossiers enfants n’est pas validé. Si vous avez mis à jour la division de l’enregistrement parent et la division est répercutée en cascade sur les enregistrements enfants, le propriétaire des enregistrements enfants peut perdre l’accès à son enregistrement.
Exemple 1 :
Un enregistrement parent appartient au propriétaire 1 dans l’unité commerciale A et il a des enregistrements enfants appartenant au propriétaire 2 dans l’unité commerciale B. Le propriétaire 1 est affecté à un rôle de sécurité des unités commerciales A et B et peut donc accéder aux enregistrements enfants. Lorsque vous mettez à jour l’enregistrement parent en propriétaire 3, le propriétaire des enregistrements enfants passe également au propriétaire 3, mais les enregistrements enfants appartiennent toujours à l’unité commerciale B. Le propriétaire 3 n’a pas accès à ces enregistrements enfants, sauf si le propriétaire a un rôle de sécurité dans l’unité commerciale B.
Exemple 2 :
Un enregistrement parent appartient au propriétaire 1 dans l’unité commerciale A et il a des enregistrements enfants appartenant au propriétaire 2 dans l’unité commerciale B. Le propriétaire 1 est affecté à un rôle de sécurité des unités commerciales A, B et C, et peut donc accéder aux enregistrements enfants. Lorsque la division propriétaire en modifiée en division C, la division des enregistrements enfants est modifiée en division C. Le propriétaire 2 de ces enregistrements enfants n’aura pas accès à ses enregistrements à moins qu’il reçoive un rôle de sécurité de la division C.
À propos de l’action Redéfinir la parenté
L’action réparente est similaire à l’action de partage, mais elle traite des droits d’accès hérités au lieu de droits d’accès explicites. L’action réparente se produit lorsque vous modifiez la valeur de la colonne de référencement dans une relation parentale. Lorsqu'une action de changement de parenté se produit, l'étendue souhaitée des droits d'accès hérités peut changer pour ReadAccess, WriteAccess, DeleteAccess, AssignAccess, ShareAccess, AppendAccess et AppendToAccess pour les tables associées. Elle ne changera pas pour CreateAccess. Les actions de mise en cascade associées à l’action de redéfinition de la parenté correspondent aux modifications des droits d’accès en lecture indiqués ci-dessus pour l’enregistrement de table et tous les enregistrements de tables associés à cet enregistrement.
À propos de l’action Fusionner
Une action de fusion peut rencontrer des problèmes de fin si un enregistrement qui fait partie du jeu d’opérations est supprimé pendant l’exécution du travail du système de fusion. Cela entraîne souvent une erreur indiquant que l’enregistrement aura une « parenté différente » ou que l’enregistrement enfant « pourrait perdre sa parenté ». Si ce problème se produit et que vous préférez que la fusion continue même si l’enregistrement est manquant, vous pouvez choisir de désactiver la vérification parente lorsque vous sélectionnez les colonnes à fusionner.
Note
Lorsque vous effectuez une fusion entre deux tables personnalisées, les valeurs DateTime ne se fusionnent pas. DateTime de l’enregistrement cible reste inchangé.
Notification en cascade
Utilisez deux messages d’assistance de notification asynchrone en cascade pour notifier un utilisateur ou un journal lorsqu’un travail asynchrone en cascade échoue ou réussit. Pour implémenter cette solution, écrivez et inscrivez un plug-in personnalisé qui s’exécute lorsque ces messages sont traités et fournit une notification de réussite ou d’échec.
Les deux messages de notification sont les suivants :
| Nom | Description |
|---|---|
cascadeAsync_FailureAPI |
Ce message est traité (exécuté) lorsqu’un travail en cascade asynchrone s’interrompt en raison de plusieurs échecs. Utilisez ce message pour informer les utilisateurs qu’ils doivent examiner leur jeu de données pour connaître les problèmes liés aux plug-ins existants, aux problèmes de données ou aux problèmes de flux de travail. InputParameters : casadeAsyncExceptionDetails : détails de l’exception à l’origine de l’échec de la tâche asynchrone en cascade.casadeAsyncJobName : nom de la tâche asynchrone en cascade. |
cascadeAsync_SuccessAPI |
Ce message est traité (exécuté) lorsque le travail en cascade asynchrone est terminé avec succès. InputParameters : casadeAsync_JobName : nom de la tâche asynchrone en cascade. |
Inscrivez le plug-in personnalisé pendant l’étape post-opération et définissez-le en mode asynchrone. La figure suivante montre un exemple d’inscription de plug-in à l’aide de l’outil d’inscription de plug-in.
Voici quelques exemples de notifications que votre plug-in personnalisé peut fournir :
- En cas de réussite, ajoutez une entrée à un journal d’exécution.
- En cas d’échec, ajoutez une entrée à un journal d’exécution, puis envoyez un e-mail (ou une autre communication) à l’administrateur indiquant la date et l’heure et la nature de l’échec.
- Affichez un message à l’utilisateur interactif.
Réparation à l’accès hérité
Après avoir modifié le comportement en cascade d'une relation de table pour les actions réaffiliation ou partage à sans cascade, le système tente d’ajuster les droits d’accès hérités de l’utilisateur pour qu’ils correspondent au comportement en cascade actuel de la relation de table. En savoir plus sur le nettoyage des droits d’accès hérités.
Toutefois, si cette approche n’est pas réussie, les utilisateurs peuvent conserver l’accès aux enregistrements associés qui doivent être supprimés. Pour connaître les étapes à suivre pour résoudre ce problème, consultez Nettoyer l’accès hérité.