Migrer en gardant les décisions
Un champ personnalisé doit-il garder son nom ou son sens ?
Pour qui : Deux outils ont un champ Priorité mais utilisent des valeurs et règles différentes.
Recherche documentaire le 8 novembre 2026 ; aucune application testée.
Notre avis
Exiger un dictionnaire et une table de correspondance des valeurs avant de reprendre les données.
Dans l’ordre
- Deux champs Priorité peuvent classer des choses différentes
- Une valeur inconnue doit produire une exception
- Faire importer une ancienne option sans correspondance puis contrôler son traitement avant tout tri ou automatisme de priorité.
Pourquoi
- Un intitulé identique peut masquer des unités ou des règles différentes ; la correspondance des valeurs protège les tris et automatismes futurs.
Ce qui change le choix
Si les valeurs sont strictement identiques et leur gouvernance commune, une correspondance simple suffit.
Deux champs Priorité peuvent classer des choses différentes
Un champ de même nom peut avoir des valeurs, unités ou règles différentes dans la destination. Nous vérifierions donc le sens avant la copie : qui le renseigne, quelles valeurs sont autorisées, comment le vide est traité et quelle décision dépend de son tri.
La correspondance doit prévoir les valeurs inconnues et les anciennes options supprimées. Les convertir toutes en Autre peut être acceptable pour un historique consultatif, mais pas si elles déclenchent des engagements ou des escalades dans le nouveau système.
Une valeur inconnue doit produire une exception
Préparez Haute, Moyenne, Basse et une ancienne valeur Urgent client. Mappez les trois premières vers les niveaux retenus et laissez la quatrième sans équivalence automatique. Vérifiez qu’elle apparaît dans une liste à arbitrer, sans devenir prioritaire ou sans priorité par défaut.
Nous conserverions le dictionnaire et sa date dans le dossier de migration. Après l’import, faites trier une vue réelle et déclencher une règle témoin. Une cellule lisible dans l’export ne prouve pas que sa valeur a gardé le même effet dans le planning.
L’API Asana distingue métadonnées du champ, valeurs portées par les objets et options d’énumération identifiées.
Limites
Analyse documentaire et méthode éditoriale. Les protocoles sont proposés, pas exécutés sur les logiciels. Les exemples chiffrés sont fictifs ; les fonctions dépendent du produit, du forfait, des droits et de la configuration.
Prochaine action
Faire importer une ancienne option sans correspondance puis contrôler son traitement avant tout tri ou automatisme de priorité.
Preuves et sources
Ce qui relève d’un fait lu, d’une déclaration, de notre calcul, de notre méthode ou de notre avis. Notre méthode
Déclaration de l’éditeur. L’API Asana distingue métadonnées du champ, valeurs portées par les objets et options d’énumération identifiées.
Relevé du 8 novembre 2026. Édition ou périmètre : Documentation publique du 8 novembre 2026 ; produit et périmètre nommés dans le constat.
- Asana Developers : https://developers.asana.com/docs/custom-fields-guide Lu le 8 novembre 2026. Documentation officielle lue ; déclaration du fournisseur, aucun essai..
Notre méthode. Mapper Haute/Moyenne/Basse vers P1/P2/P3 avec une valeur inconnue ; contrôler l’exception et la règle de tri dans la destination.
Daté du 8 novembre 2026. Édition ou périmètre : Protocole éditorial proposé ; aucune observation de compte client.