FAQ sur l’outil de migration

Règles de création automatique d’enregistrements de l’outil de migration et accords de niveau de service

Qui peut accéder à l’outil de migration ou l’exécuter ?

Les administrateurs et les utilisateurs ayant un rôle de directeur du service clientèle peuvent exécuter l’outil de migration.

Les règles migrées sont-elles automatiquement activées après la migration ?

Non Vous devez activer manuellement les règles migrées lorsque la migration est terminée.

Puis-je continuer à utiliser mes anciennes règles après la date limite d’obsolescence ?

Oui. Les règles héritées actives après la date limite d’obsolescence continueront à fonctionner jusqu’à ce qu’elles soient désactivées. Cependant, la prise en charge et l’expérience d’édition s’arrêteront après l’obsolescence.

Puis-je activer une règle avec un statut de migration incomplète ?

Non Une règle migrée est activée uniquement lorsque vous basculez l’option Marquer comme terminée sur Oui après avoir examiné une règle incomplète et résolu tous les problèmes présents. C’est à ce moment-là que la règle est considérée comme migrée avec succès.

La règle existante est-elle désactivée après ma migration ?

• Oui, pour la création automatique d’enregistrements. Lorsque vous activez une règle de création automatique d’enregistrements migrée dans Unified Interface, la règle héritée correspondante est désactivée.
• Non pour les SLA. Lorsque vous activez une règle SLA migrée dans Unified Interface, la règle héritée correspondante reste active car les deux règles peuvent coexister.

Que signifie un statut de migration « incomplète » ?

• Dans la section Résumé : le processus de migration global n’a pas pu mener à bien la migration de toutes les règles sélectionnées.
• À côté d’une règle : la règle a échoué ou n’a pas pu être entièrement migrée (ce qui signifie qu’un ou plusieurs éléments ou conditions n’ont pas pu être migrés).

Où puis-je trouver une liste des règles partiellement migrées qui sont suivies dans l’outil de migration ?

Les règles partiellement migrées ou identifiées comme incomplètement migrées ne sont pas considérées comme entièrement migrées. Par conséquent, elles sont suivies sous En attente dans la section Résumé . Seules les règles dont la migration a réussi sont comptabilisées sous la section Migrées.

Les formulaires ou les champs personnalisés sont-ils pris en charge par l’outil de migration ?

• Oui, pour la création automatique d’enregistrements. L’outil de migration prend en charge les entités, champs, attributs et configurations personnalisés.
• Non pour les SLA. Les entités, champs, attributs et configurations personnalisés ne sont pas entièrement pris en charge par l’outil de migration. Les utilisateurs devront modifier les flux de personnalisation existants, les flux de travail, les plugins ou tout autre code personnalisé sur les entités, les champs, les attributs et les configurations personnalisés pour effectuer la migration.

Ai-je besoin d’une licence distincte pour Power Automate avant d’exécuter la migration ?

Non Pour plus d’informations sur les directives de licence, accédez à Quels sont les droits d’utilisation Microsoft Power Apps et Power Automate pour les applications Dynamics 365 ?

Certaines de mes règles sont incomplètes et/ou partiellement migrées. Que dois-je faire ?

Au choix, vous pouvez corriger la règle dans le client Web en fonction des détails du problème et réexécuter votre migration, ou corriger la règle migrée directement dans Unified Interface.

Puis-je réexécuter l’outil de migration pour une règle migrée spécifique ?

Oui, vous pouvez réexécuter l’outil de migration pour une règle migrée spécifique en fonction des critères suivants :

• Pour les règles dont la migration est incomplète ou a échoué : sélectionnez la même règle lorsque vous réexécutez l’outil de migration. L’outil remplace automatiquement la règle existante dont la migration a échoué ou est incomplète par la règle nouvellement migrée.
• Pour les règles migrées avec succès : supprimez la règle migrée dans Unified Interface avant de réexécuter l’outil de migration.

Qu’advient-il des enregistrements SLA existants qui sont associés à des SLA hérités une fois la migration terminée ?

• Si l’ancien SLA est désactivé après la migration : Le minuteur continuera à s’exécuter jusqu’à la phase terminale de ces enregistrements SLA. Cependant, les fonctionnalités Résoudre et Suspendre ne fonctionneront pas.
• Si le SLA hérité est toujours défini à l’état Actif : les enregistrements SLA existants associés à des SLA hérités continueront de fonctionner comme prévu.
• Si vous souhaitez utiliser les SLA créés dans les applications Unified Interface sur des enregistrements existants : vous devrez mettre à jour le champ SLA sur Unified Interface SLA manuellement ou écrire le plug-in pour mettre à jour les enregistrements. Par exemple, la logique du plugin pourrait être Modern Flow ou Workflow.

Pour des informations sur la règle ou les flux migrés dans la fonction de création d’enregistrement automatique moderne, rendez-vous sur FAQ sur la création automatique d’enregistrements modernes.

Problèmes connus de conversion de condition

Cette section décrit les principaux scénarios dans lesquels les règles ou éléments ne réussiront pas la migration :

Si mes éléments ou conditions de règle ont des entités associées incluses dans des clauses de groupe imbriquées (et/ou), seront-ils migrés vers Unified Interface ?

Non Nous ne prenons actuellement en charge qu’un seul niveau de hiérarchie d’entités associées. Pour que la migration de ces éléments ou conditions de règle aboutisse, vous devez supprimer toute entité associée dans les clauses de groupe avant la migration. Si vous n’effectuez aucune action, la règle échouera pendant l’étape de Bilan de prémigration. Si vous choisissez de poursuivre la migration, la règle aura une condition vide pour l’élément associé.

Exemple : entités associées dans une clause de groupe imbriquée

Vue du client Web avant la migration

Légende :

a. Titre de l’élément.

Vue de Unified Interface après la migration

Légende :

2a. Le titre de l’élément migré est modifié avec l’ajout d’un suffixe « FailedMigration ».

2b. Le même espace réservé standard, Date de création égale 2200-01-01, est ajouté à la condition.

Pourquoi mes éléments ou conditions de règle ayant un champ DateType qui utilise un opérateur « pas activé » (not on) échouent-ils lors de la vérification préalable à la migration et de la migration réelle ?

L’opérateur Pas activé pour le type de données Date n’est pas pris en charge dans Unified Interface. Par conséquent, il n’est pas pris en charge dans le cadre de la migration. Pour résoudre ce problème, vous pouvez modifier les éléments ou conditions hérités de {not-on selecteddate} en {selecteddate less than and selecteddate greater than}dans le client Web avant de réexécuter l’outil de migration pour la règle concernée.

Exemple : champ DateType qui utilise un opérateur Pas activé

Vue du client Web avant la migration

Légende :

a. Titre de l’élément.

Vue de Unified Interface après la migration

Légende :

2a. Le titre de l’élément migré est modifié avec l’ajout d’un suffixe « FailedMigration ».

2b. La condition comporte un espace réservé Date de création égale 2200-01-01 qui lui est ajouté.

Pourquoi les données de mon champ DateTime changent-elles pendant la migration ?

Aucun champ d’heure distinct n’existe dans Unified Interface. Par conséquent, le champ DateHeure passera d’un contrôle de calendrier à un champ de texte. L’entrée doit être dans un format spécifique, comme indiqué dans le champ de l’exemple ci-dessous.

Exemple : champ DateHeure

Vue du client Web avant la migration

Légende :

a. Champ Date et heure avant la migration.

b. Champ Date uniquement avant la migration.

Vue de Unified Interface après la migration

Légende :

a. Champ Date et heure après la migration.

b. Champ Date uniquement après la migration

Pourquoi certains de mes champs d’opérateur sont-ils vides dans Unified Interface après la migration ?

Pour les types de données de recherche, seuls les opérateurs égal, non égal, null et non null sont pris en charge dans Unified Interface et dans l’outil de migration. Les opérateurs En dessous et pas en dessous ne sont pas pris en charge dans Unified Interface et ne sont donc pas pris en charge dans l’outil de migration. Toutes les conditions qui ont des opérateurs sous ou pas sous sont traduits par des entités associées après la migration. Elles sont affichées vides dans Unified Interface et ne peuvent pas être modifiées.

Exemple : champs d’opérateur Sous et Pas sous

Vue du client Web avant la migration

Légende :

a. Opérateurs Sous.

Vue de Unified Interface après la migration

Légende :

b. Champ opérateur vide.

Puis-je migrer à nouveau une règle après son activation ?

• Oui, pour les règles de création automatiques d’enregistrements. Vous pouvez à nouveau migrer une règle activée, mais vous devez d’abord la désactiver et la supprimer de Unified Interface.
• Non pour les SLA. Une fois qu’une règle SLA migrée est activée, elle est liée à une autre entité (comme un incident, ou elle est en cours d’utilisation). Par défaut, une règle activée a été migrée avec succès. Avant de pouvoir migrer à nouveau une règle activée, vous devez la supprimer. Cependant, il existe une limitation pour les règles SLA Unified Interface. Une fois qu’une règle est associée à un incident ou à une entité (c’est-à-dire après qu’elle a été activée une fois), vous ne pouvez pas la supprimer, même si elle est désactivée. Par conséquent, la règle ne peut pas être migrée à nouveau si elle a été précédemment activée ou appliquée.

Puis-je migrer des règles SLA standard obsolètes ?

Non L’outil de migration prend en charge uniquement les règles SLA améliorées. Les règles SLA standard sont obsolètes. Elles ne sont plus pris en charge dans Unified Interface et ne sont donc pas pris en charge dans l’outil de migration. Pour plus d’informations, voir Les SLA standard dans Dynamics 365 Customer Service sont obsolètes.

Problèmes connus

Obsolescence de la propriété de canal

Si vous avez utilisé des propriétés de canal dans la personnalisation des règles héritées, ces règles ne seront pas migrées avec succès à l’aide de l’outil de migration. Il n’existe pas de solution de contournement générale pouvant être appliquée pour résoudre cet écart pour tous les utilisateurs. La solution de contournement dépend fortement de la manière dont vous utilisez les propriétés du canal dans les règles héritées.

Différence de comportement quand l’option « Créer des incidents pour les activités associées à un incident résolu » est sélectionnée

• Comportement hérité : si l’e-mail a un incident connexe qui a été résolu depuis l’heure spécifiée, l’incident résolu sera réactivé par défaut. Aucune personnalisation n’est requise.
• Comportement moderne : si l’e-mail a un incident connexe qui a été résolu depuis l’heure spécifiée, un nouvel incident sera créé par défaut. La personnalisation est Obligatoire pour réactiver un incident existant au lieu de créer un incident.

Différence de comportement quand l’option « Créer un incident si un droit valide existe pour le client » est sélectionnée

• Comportement hérité : si l’expéditeur du Courrier électronique n’a pas de droit valide et que le Courrier électronique a un incident connexe, l’incident connexe existant sera mis à jour.
• Comportement moderne : si l’expéditeur du Courrier électronique ne dispose pas d’un droit valide, aucun flux ne sera appelé.

Écarts de parité entre les flux de travail et les flux Power Automate (s’applique uniquement à la personnalisation des actions d’élément de règle)

• L’expression « First not null » ne peut pas être migrée automatiquement. Toutefois, la personnalisation peut être appliquée manuellement sur le flux pour la migration.
• Le mappage du nom d’affichage d’un enregistrement de recherche à un champ de chaîne ne peut pas être migré automatiquement. Toutefois, la personnalisation peut être appliquée manuellement sur le flux pour la migration.
• Les champs de groupe d’activités utilisés comme champs source ne sont pas pris en charge dans le flux.

Problèmes connus avec les flux

Les règles migrées comportent un caractère @ supplémentaire pour les champs de type chaîne @

Si le workflow de règle de création automatique d’enregistrements hérité est personnalisé et comporte un caractère @ en texte brut dans un champ de chaîne, vous verrez deux @, au lieu d’un lors de la migration. Par exemple, si vous ajoutez une adresse e-mail en texte brut dans le champ de description du cas, le caractère @ sera traité comme un caractère spécial et migré comme @@.

En effet, @ est identifié comme un caractère spécial pour toute expression dynamique, telle que @triggerOutputs()?[body/_emailsender_value] dans le flux de migration.

La solution de contournement consiste à supprimer manuellement le @ supplémentaire dans le flux migré.

La migration ne prend pas en charge plusieurs éléments ou conditions ayant la même condition « applicable quand » dans le même contrat SLA

Dans le client web, plusieurs éléments peuvent être définis avec la même condition « applicable quand » et différents critères de réussite pour un SLA. Cependant, la même fonctionnalité n’est pas prise en charge dans Unified Interface. Par conséquent, au cours de la migration, aucun élément SLA subséquent de ce type avec la même condition « applicable quand » ne sera créé.

Les captures d’écran suivantes illustrent le scénario qui n’est pas pris en charge dans Unified Interface. Les deux conditions « Applicable quand » indiqués ont des critères de réussite différents.

Problèmes d’attribut du type Groupe d’activité pendant la conversion d’un workflow en flux

Un attribut de type Groupe d’activité affecté à un autre champ de type Groupe d’activité ne sera pas migré pendant la conversion de workflow en flux. En effet, Power Automate ne prend actuellement pas en charge ce scénario. (Les champs les plus fréquemment concernés sont À, De, CC et Cci dans les e-mails.) Bien que la migration de la règle n’échoue pas, la valeur des données pour ces champs de type groupe d’activité qui reposent sur un autre attribut de type groupe d’activité sera vide après la migration.

Exemple : Attributs du groupe d’activité

Vue du client Web avant la migration

Légende :

a. Le champ De, qui est un champ de type Groupe d’activité affecté à un autre attribut de type Groupe d’activité {Bcc(Email)} . Il sera vide après la migration.

b. Le champ À sera migré.

Vue de Unified Interface après la migration

Légende :

b. Champ À.

La vérification « First not null » dans les expressions des workflows hérités lors de la conversion des workflows en flux n’est pas prise en charge

Dans les workflows hérités, un champ de recherche peut être mappé avec plusieurs expressions dans lesquelles vous vérifiez et attribuez l’expression « First Not Null », comme indiqué dans l’exemple du client web suivante. Actuellement, cette approche n’est pas pris en charge dans le cadre de la conversion d’un workflow en flux, car il s’agit d’une limitation connue du concepteur de workflow hérité. Par conséquent, le convertisseur de flux de travail attribue la première expression sans effectuer la vérification null. Il supprime ensuite toutes les expressions restantes, qu’elles aient ou non des valeurs non null. Dans l’exemple suivant, le flux n’aura que la valeur Regarding(Email) dans le champ Client à cette étape.

Exemple : expressions « First Not Null »

Vue préalable à la migration

Légende :

a.Vue client web : dans le workflow, le champ Client contient {Regarding(Email); Contact(Create (Case)); Customer(Create (Case))}.

Dans Unified Interface, le champ Client contient uniquement Regarding(Email), qu’il soit null ou non.

Voir aussi

FAQ sur la création automatique d’enregistrements modernes

Migrer les règles de création automatique d’enregistrements et les SLA

Guide opérationnel pour la migration de Dynamics 365 SLA et ARC