Configurer le comportement en cascade de la relation de table
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 support du SDK pour .NET configurent le comportement en cascade.
Utilisation de l’API Web pour configurer le comportement en cascade
Lors de l’utilisation de l’API web, vous pouvez définir une relation un-à-plusieurs avec OneToManyRelationshipMetadata entity type. Cette définition inclut le nom de la table avec intersection à créer ainsi que le mode d’affichage dans l’application à l’aide du type complexe AssociatedMenuConfiguration, du type complexe Label et du type complexe LocalizedLabel.
Pour plus d’informations, voir Créer une relation un-à-plusieurs à l’aide de l’API Web.
Utilisation du SDK pour .NET pour configurer le comportement en cascade
Lorsque vous utilisez les classes CreateOneToManyRequest ou UpdateRelationshipRequest, incluez une instance d’une classe OneToManyRelationshipMetadata dans le corps de la requête. Dans la propriété CascadeConfiguration de cette classe, vous utilisez la classe CascadeConfiguration.
La classe CascadeConfiguration ou le type complexe CascadeConfiguration contient les propriétés suivantes qui représentent les actions qui peuvent être effectuées sur la table référencée dans la relation de table un-à-plusieurs. Une des valeurs de l’énumération de type CascadeType peut être attribuée à chaque propriété.
| active | Étiquette de l’application | Description |
|---|---|---|
| Activé | 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 vers l’article | 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êcher la suppression de l’enregistrement de table référencé en présence de tables de référencement associées. |
| 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 les actions en cascade
Les actions en cascade sur les enregistrements actifs ne comprennent que des enregistrements dont le code d’état est « Actif ». Les codes d’état suivants pour ces tables sont considérés comme Actif pour les actions en cascade. Différentes étiquettes (autres que Actif) peuvent être utilisées pour ce code d’état dans différentes tables. Aucun état ou code de statut personnalisé avec des valeurs autres que celles de la table suivante ne sera traité comme un enregistrement actif à des fins de cascade.
| Nom de 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 | |||
| x | ||||
| Télécopie | x | |||
| Incident | x | |||
| IncidentResolution | x | |||
| Facture | x | |||
| Prospect | x | |||
| Lettre | x | |||
| Opportunité | x | |||
| OpportunityClose | x | |||
| OrderClose | x | |||
| PhoneCall | x | |||
| Commande client | x | |||
| Tâche | x | |||
| Toutes les tables personnalisées et activités personnalisées | x | |||
| Devis | x | |||
| Contrat | x | |||
| Rendez-vous | x | |||
| ServiceAppointment | x | |||
| RecurringAppointmentMaster | x |
La classe CascadeConfiguration du SDK pour .NET ou le type complexe CascadeConfiguration de l’API web contient les propriétés suivantes qui représentent les actions qui peuvent être effectuées sur la table référencée dans la relation de table un-à-plusieurs.
| Pour | Description | Options valides |
|---|---|---|
| Affecter | Le propriétaire de l’enregistrement de table référencé et/ou la division sont modifiés. | Activé Cascade NoCascade UserOwned |
| Suppr | L’enregistrement de table référencée est supprimé. Remarque : les options de cette action sont limitées. | En cascade RemoveLink Restreindre |
| Fusionner | L’enregistrement est fusionné 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. | En cascade NoCascade |
| Redéfinir la parenté | Consultez À propos de l’action Redéfinir la parenté ultérieurement. | Activé Cascade NoCascade UserOwned |
| Partager | Lorsque l’enregistrement de table référencé est partagé avec un autre utilisateur. | Activé Cascade NoCascade UserOwned |
| Annuler le partage | Lorsque le partage est supprimé pour l’enregistrement de table référencé. | Activé Cascade NoCascade UserOwned |
Notes
Les actions Attribuer, Supprimer, Fusionner et Redéfinir la parenté ne s’exécuteront 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
Notes
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
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 lorsque l’enregistrement parent est mis à jour.
La propriété de l’enregistrement autorisé entre les divisions n’est pas activée
Quand la propriété de l’enregistrement autorisé entre les divisions n’est pas activée, la colonne Division propriétaire ne peut pas être mis à jour explicitement lors du changement de propriétaire de l’enregistrement. Ce qui suit répertorie les comportements en cascade lorsque le propriétaire de l’enregistrement parent est mis à jour.
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 n’est pas mis à jour (pas de cascade)
- La division des enregistrements enfants n’est pas mise à jour (pas de cascade)
La propriété de l’enregistrement autorisé entre les divisions est activée
Quand la propriété de l’enregistrement autorisé entre les divisions est activée, la colonne Division propriétaire peut être mise à jour explicitement 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.
AlwaysMoveRecordToOwnerBusinessUnit peut être défini dans les paramètres de base de données de l’environnement et peut également être défini à 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 n’est pas mis à jour (pas de cascade)
- La division des enregistrements enfants n’est pas mise à jour (pas 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 n’est pas mis à 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 n’est pas mis à 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
- La division de l’enregistrement est mise à jour vers la nouvelle division
- 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
- 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)
Modifiez les comportements en cascade avec OrgDBSettings AlwaysMoveRecordToOwnerBusinessUnit
Vous pouvez définir AlwaysMoveRecordToOwnerBusinessUnit sur false ; la division des enregistrements appartenant à l’utilisateur n’est pas déplacée vers la division du nouvel utilisateur.
AlwaysMoveRecordToOwnerBusinessUnit peut être défini dans les paramètres de base de données de l’environnement et peut également être défini à l’aide de l’Outil OrgDBOrgSettings pour Microsoft Dynamics CRM.
Si vous mettez à jour le propriétaire :
AlwaysMoveRecordToOwnerBusinessUnit = false
- 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 n’est pas mise à jour
- Le propriétaire des enregistrements enfants est mis à jour vers le nouveau propriétaire
- La division des enregistrements enfants n’est pas mise à jour
- 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 n’est pas mise à jour
- 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 la division :
AlwaysMoveRecordToOwnerBusinessUnit = false
- Comportement d’affectation en cascade par défaut (tout en cascade)
- Le propriétaire de l’enregistrement n’est pas mis à 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 n’est pas mis à 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 = false
- 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 nouvelle division
- 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
- 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)
Notes
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 et/ou la division, nous vérifions que le propriétaire a le privilège pour la division avant d’autoriser les mises à jour.
- Cependant, le privilège du propriétaire de l’enregistrement pour les enregistrements 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 la division A et comporte des enregistrements enfants appartenant au propriétaire 2 dans la division B. Le propriétaire 1 dispose d’un rôle de sécurité pour les divisions A et B et peut donc accéder aux enregistrements enfants. Lorsque l’enregistrement parent est mis à jour vers le propriétaire 3, le propriétaire des enregistrements enfants est également remplacé par le propriétaire 3, mais les enregistrements enfants appartiennent toujours à la division B. Le propriétaire 3 n’aura pas accès à ces enregistrements enfants à moins que le propriétaire n’ait un rôle de sécurité dans la division B.
Exemple 2
Un enregistrement parent appartient au propriétaire 1 dans la division A et comporte des enregistrements enfants appartenant au propriétaire 2 dans la division B. Le propriétaire 1 dispose d’un rôle de sécurité pour les divisions A, B et C et peut donc accéder aux enregistrements enfants. Lorsque la division propriétaire est remplacée par la division C, la division des enregistrements enfants est remplacée par la division C. Le propriétaire 2 de ces enregistrements enfants n’aura pas accès à ses enregistrements à moins qu’il n’ait un rôle de sécurité dans la division C.
À propos de l’action Redéfinir la parenté
L’action Redéfinir la parenté est similaire à l’action de partage, à ceci près qu’elle traite des droits d’accès hérités au lieu des droits d’accès explicites. L’action Redéfinir la parenté est l’action effectuée lorsque vous modifiez la valeur de la colonne de référencement dans une relation parentale. Lorsqu’une action Apparenter a lieu, l’étendue souhaitée des droits d’accès hérités en lecture pour les tables associées peut changer pour ReadAccess, WriteAccess, DeleteAccess, AssignAccess, ShareAccess, AppendAccess et AppendToAccess. 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
L’action de fusion peut parfois présenter des problèmes d’exécution si un enregistrement qui fait partie de l’ensemble d’opérations est supprimé pendant l’exécution de la tâche 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 cela 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 de parenté lorsque vous sélectionnez les colonnes à fusionner.
Notes
Lors d’une fusion entre deux tables personnalisées, les valeurs DateTime ne fusionnent pas. La DateHeure de l’enregistrement cible restera inchangée.
Notification en cascade
Vous pouvez utiliser deux messages d’assistance de notification asynchrone en cascade pour fournir une notification à un utilisateur ou à un journal lorsqu’une tâche asynchrone en cascade échoue ou réussit. Pour cela, vous devez écrire et enregistrer 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 est suspendu en raison de plusieurs échecs. Cela peut être utilisé pour informer les utilisateurs qu’ils doivent examiner leur jeu de données pour détecter les problèmes avec les plug-ins existants, les problèmes de données ou les 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. |
Le plug-in personnalisé doit être enregistré pendant la phase de post-opération et doit être défini en mode asynchrone. La figure suivante montre un exemple d’enregistrement de plug-in à l’aide de l’outil d’enregistrement de plug-in.
Voici quelques exemples du type de notifications que votre plug-in personnalisé peut fournir :
- En cas de succès, 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 toute autre communication) à l’Administrateur indiquant la date/l’heure et la nature de l’échec
- Afficher un message à l’utilisateur qui interagit
Réparation à l’accès hérité
Après avoir modifié le comportement en cascade d’une relation de table pour les actions Apparenter ou Partager en Sans mise en cascade, le système tente d’ajuster les droits d’accès hérités de l’utilisateur pour correspondre au comportement en cascade actuel des relations entre les tables. En savoir plus sur le nettoyage des droits d’accès hérités
Toutefois, si cette approche échoue, les utilisateurs peuvent conserver l’accès aux enregistrements associés qui doivent être supprimés. Pour connaître la procédure à suivre pour résoudre le problème, consultez Nettoyer l’accès hérité.
Voir aussi
Notes
Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)
Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour