Wix réunit création de site, commerce, CRM, CMS, marketing et données applicatives au sein d’un même site. Cette diversité rend la signification des données plus importante que la simple similitude des champs. Un Product source peut devenir un Product Wix Stores avec options, choix, variantes, médias, Categories, relations de marque et stock. Une personne peut exister comme Contact, Member du site, Customer lié à des Orders ou participant à une autre application métier Wix. Un enregistrement CMS source peut relever d’une collection Wix CMS, tandis qu’un Product, Blog Post, booking, event ou enregistrement applicatif appartient à un autre propriétaire de données Wix.
Wix possède aussi une frontière active liée à la version du catalogue. Un site Wix peut utiliser Catalog V1 ou Catalog V3, mais pas les deux simultanément. Catalog V3 introduit des variantes universelles, des Customizations réutilisables, des Inventory Items séparés par variante et emplacement, des Categories hiérarchiques, des marques, des sections d’information réutilisables et d’autres entités du catalogue. La version du catalogue du site cible fait donc partie du modèle de données ; ce n’est pas un détail technique secondaire.
La tâche essentielle consiste à préserver les relations parent-enfant et intersystèmes derrière les données. L’identité Product doit rester reliée à la bonne variante, Category, au bon enregistrement de stock, emplacement, média et identifiant externe. L’identité Contact doit rester distincte de l’accès Member et du consentement marketing. Les Orders doivent conserver les éléments de transaction sans devenir la configuration du futur processus de commande. Les collections CMS et données d’applications ont besoin de propriétaires explicites au lieu d’être aplaties en contenu de page générique.
La version du catalogue Wix constitue une frontière de responsabilité des données
Catalog V1 et Catalog V3 n’exposent pas exactement les mêmes structures d’enregistrements. Un site utilise une seule version de catalogue à la fois ; la traduction des données doit donc suivre celle active sur le site cible. Catalog V3 repose sur des services plus explicites pour Products, variantes, Inventory Items, emplacements, Categories, marques, ribbons, sections d’information et Customizations réutilisables.
Catalog V3 utilise aussi des variantes universelles : chaque Product possède au moins une variante, y compris une variante par défaut pour les Products sans options visibles. Prix, SKU, stock et autres caractéristiques vendables peuvent donc être compris au niveau de la variante même si l’acheteur ne voit qu’un Product simple.
| Hypothèse de la boutique source | Signification dans le catalogue Wix | Conséquence de traduction |
|---|---|---|
| Un Product sans options n’a pas de variante. | Catalog V3 représente tout de même une variante par défaut. | Identité Product et identité vendable restent liées même lorsqu’aucun choix n’est visible. |
| Toute option est une donnée descriptive du Product. | Les options créent des variantes ; les modifiers collectent une personnalisation sans créer de variantes. | Séparer les choix portant du stock des saisies acheteur et personnalisations facultatives. |
| Une quantité de stock appartient au Product. | Les Inventory Items de Catalog V3 relient une variante à un emplacement. | Préserver à la fois la variante vendable et le contexte d’emplacement derrière chaque quantité. |
| Une collection équivaut à un arbre de Categories. | La version du catalogue Wix et son modèle de Categories déterminent l’organisation des Products. | Traduire la hiérarchie source vers les relations de Categories prises en charge par le site cible. |
| Les données Wix Stores et Wix CMS sont interchangeables. | Les entités du catalogue Wix Stores et les éléments de collections Wix CMS ont des propriétaires différents. | Utiliser CMS uniquement pour les enregistrements qui appartiennent réellement à des collections CMS ou structures de données externes. |
Il ne faut donc pas supposer qu’une correspondance de champs conçue pour une version du catalogue Wix s’applique telle quelle à une autre. Les intégrations externes ont également besoin des bons IDs d’entités et du bon niveau de granularité. Un ERP qui reconnaît les variantes ne peut pas être relié de manière fiable avec le seul ID du Product parent lorsque Catalog V3 gère le stock par variante et emplacement.
Products, variantes universelles, options, choix et modifiers
Un Product Wix est l’enregistrement parent du catalogue. Dans Catalog V3, chaque Product possède au moins une variante. Les Products dotés d’options peuvent générer des variantes à partir des combinaisons de choix. Chaque variante peut porter un SKU, un prix, des médias et une signification de stock distincts. Les Customizations distinguent les options qui créent des variantes des modifiers qui collectent des saisies supplémentaires de l’acheteur sans modifier l’identité de variante ou de stock.
Cette distinction est essentielle pour migrer des Products configurables. Une taille ou une couleur source qui modifie SKU ou stock relève généralement des options et variantes. Un champ de gravure, un message cadeau ou une personnalisation facultative se rapproche d’un modifier. Une application source peut combiner les deux dans un même configurateur ; la migration doit alors séparer l’identité vendable obtenue des instructions fournies par l’acheteur.
| Configuration source | Propriétaire Wix | Signification à préserver |
|---|---|---|
| Product simple avec un SKU | Product plus variante par défaut | Contenu Product au niveau parent ; SKU vendable, prix et identité de stock au niveau variante. |
| Combinaisons taille/couleur | Options, choix et variantes | Chaque combinaison achetable reste reliée aux bons choix, SKU, prix, médias et stock. |
| Texte de gravure ou message cadeau | Modifier ou sortie de personnalisation possédée par une application | La saisie acheteur reste rattachée à la bonne ligne achetée sans créer de fausses variantes de stock. |
| Upgrade facultatif | Modifier, Product séparé ou variante selon la signification de stock et de prix | Le propriétaire cible dépend de l’existence ou non d’un article vendable distinct. |
| Bundle ou kit | Relation Product, bundle possédé par une application ou structure de stock externe | Composants, autorité du stock, formation du prix et données de ligne Order résultantes restent explicables. |
| Subscription, booking, event ou offre de service | Product Wix Stores ou autre application métier Wix selon le fonctionnement | L’identité de catalogue reste distincte de la facturation récurrente, de la planification, de la participation ou des droits d’accès. |
Les Customizations de Catalog V3 peuvent être réutilisées entre plusieurs Products. Cela crée une autre frontière relationnelle : la définition de personnalisation peut être partagée, tandis que l’affectation au Product et le fonctionnement de la variante ou du modifier restent propres à chaque Product. Supprimer ou modifier une définition partagée peut toucher plusieurs Products ; les templates d’options source ne doivent donc devenir des entités réutilisables que s’ils partagent réellement la même signification métier.
Les médias Product exigent également une responsabilité claire. Les médias du Product parent peuvent décrire l’offre globale, tandis qu’une image de choix d’option ou de variante peut identifier une combinaison précise. Rassembler toutes les images dans une galerie indifférenciée préserve les fichiers mais peut faire perdre la relation qui permet à l’acheteur de reconnaître la variante sélectionnée.
Categories, Brands, Info Sections, Ribbons et découverte
L’organisation du catalogue Wix peut faire intervenir des Categories hiérarchiques, affectations Product, Brands, Ribbons, Info Sections réutilisables, recherche, navigation du site et présentation des pages. Ces enregistrements ont des finalités différentes.
Les Categories de Catalog V3 peuvent former des arbres parent-enfant et affecter un Product à plusieurs Categories, avec une relation de Category principale. Les Brands représentent l’identité du fabricant ou de la marque. Les Info Sections apportent des informations Product riches et réutilisables comme spécifications, guides de tailles, conseils d’entretien ou garanties. Les Ribbons portent des libellés promotionnels. Les pages et menus du site déterminent la navigation publique et la présentation.
| Concept source | Propriétaire Wix cible | Conséquence de traduction |
|---|---|---|
| Hiérarchie permanente de rayons | Arbre de Categories et relations Product-Category | Préserver la signification durable de navigation et de classification. |
| Fabricant ou marque | Entité Brand et association au Product | Garder l’identité de marque distincte des Categories et spécifications descriptives. |
| Spécifications techniques | Champs Product, Info Sections, données CMS ou PIM externe selon réutilisation et responsabilité | Ne pas transformer des attributs descriptifs en variantes s’ils ne créent pas de combinaisons vendables. |
| Guide de tailles ou d’entretien partagé | Info Section réutilisable | Préserver un propriétaire de contenu partagé et les références Product. |
| Badge promotionnel, nouveauté ou mise en avant | Ribbon ou présentation merchandising | Garder le statut promotionnel distinct de la classification Product permanente. |
| Collection saisonnière | Category, page d’atterrissage, ribbon, campagne ou présentation sélectionnée selon sa finalité | Préserver la signification de campagne sans en faire un type Product permanent. |
| Élément de menu | Relation de navigation vers Category, page Product, CMS Page ou URL externe | La navigation ne devient pas propriétaire de la classification Product. |
Une même valeur source peut avoir plusieurs propriétaires selon son usage. « Organic » peut être une spécification recherchable, un badge Product, une Category ou un champ de certification provenant d’un PIM externe. La traduction doit suivre le processus qui consomme la valeur, non le libellé utilisé dans le système source.
Les relations entre variantes et emplacements déterminent le sens du stock
Les Inventory Items de Catalog V3 représentent une variante précise à un emplacement précis. L’enregistrement de stock peut suivre quantité, disponibilité, précommande et autres significations pour cette combinaison variante-emplacement. Chaque boutique possède aussi un emplacement par défaut ; des emplacements supplémentaires peuvent représenter entrepôts, succursales ou points de traitement.
Une plateforme source peut stocker une quantité par Product, une quantité par variante, ou des quantités séparées par entrepôt et canal. Ces modèles ne sont pas équivalents.
| Modèle de stock source | Relation Wix cible |
|---|---|
| Une quantité Product sans options visibles | Variante par défaut → emplacement de stock prévu → Inventory Item. |
| Stock par variante | Chaque combinaison vendable source → variante Wix → Inventory Item par emplacement. |
| Stock par entrepôt | Entrepôt/succursale source → emplacement Wix ou système d’entrepôt externe → quantité variante-emplacement. |
| Disponibilité illimitée ou fabrication à la demande | Disponibilité de la variante et sens du suivi de stock, non une quantité arbitrairement élevée. |
| Stock en précommande | Inventory Item variante-emplacement plus règles de précommande lorsque la cible prend ce fonctionnement en charge. |
| Autorité de stock externe | IDs variante/emplacement Wix plus clé ERP ou entrepôt utilisée pour la synchronisation continue. |
| Allocation marketplace | Variante → relation canal/listing externe → propriétaire du stock, au lieu de quantités dupliquées et non gouvernées. |
Dans Catalog V3, création du Product et création de l’Inventory Item sont des opérations séparées sauf utilisation d’un flux combiné. Cette séparation renforce le modèle de responsabilité : un Product peut exister sans enregistrement de stock complet, et le stock ne peut être compris sans la variante et l’emplacement qui le possèdent.
Lorsqu’un ERP ou un système d’entrepôt reste l’autorité, la quantité de stock initiale est moins durable que les identifiants qui maintiennent les futures mises à jour alignées. Un ID externe au niveau Product ne suffit pas si le système externe stocke chaque couple variante-emplacement séparément.
Relations entre Contacts, Members, Customers et marketing
Wix CRM Contacts et Members du site représentent des relations différentes. Un Contact est un enregistrement de personne ou d’organisation utilisé dans CRM, communications, Orders et applications métier. Un Member est un utilisateur du site avec authentification et éventuellement profil, rôle, permission ou accès à du contenu réservé. Un Customer commercial peut être relié à un Contact et à des Orders sans reproduire tous les fonctionnements du compte source.
Un compte Customer source peut contenir adresses, historique Order, mots de passe, rôles d’entreprise, groupes Customer, exonérations fiscales, points de fidélité, memberships, subscriptions, consentement et attributs propres à des applications. Ces valeurs doivent être affectées à l’entité Wix ou au système externe qui possède leur usage continu.
| Modèle d’identité source | Décision relationnelle dans Wix |
|---|---|
| Acheteur retail enregistré | Identité Contact/Customer reliée aux adresses et Orders ; relation Member uniquement si un accès au site est prévu. |
| Acheteur invité | Contexte Contact lié à l’Order sans inventer de compte Member. |
| Abonné newsletter uniquement | Contact plus relation de consentement/abonnement aux communications, non automatiquement Customer ou Member. |
| Utilisateur d’une communauté ou de contenu réservé | Member plus relation Contact et tout rôle, permission ou propriétaire d’accès pertinent. |
| Contact d’entreprise B2B | Contact plus relation entreprise/CRM/compte externe ; ne constitue pas automatiquement une hiérarchie organisationnelle complète. |
| Participant fidélité | Contact/Customer plus registre Wix ou externe qui possède points et statut. |
| Comptes source dupliqués | Fusion uniquement lorsque email, téléphone, IDs externes, adresses, consentement et responsabilité des Orders soutiennent une identité unique. |
Les mots de passe et l’état d’authentification ne doivent pas être traités comme de simples champs de profil. Même lorsqu’un Customer source devient Member Wix, identifiants de connexion, état d’invitation, rôles et permissions ont une signification de sécurité et de cycle de vie distincte.
Le consentement marketing reste lui aussi indépendant de l’historique d’achat. Un Contact qui a acheté une fois n’est pas automatiquement abonné, et un abonné peut n’avoir jamais acheté. Préserver le consentement exige de maintenir la relation de communication distincte de l’enregistrement Contact lui-même.
Les Orders préservent l’historique commercial et le contexte applicatif
Les Wix eCommerce Orders gèrent le cycle après achat. Un Order peut contenir articles achetés, détails de paiement, informations de facturation et d’expédition, remises, taxes, données de livraison ou retrait, statut de traitement, remboursements, factures et références externes. Draft Orders, enregistrements de facturation, transactions, factures et traitements ont des propriétaires liés mais distincts.
La ligne Product ou variante d’un Order historique constitue un instantané de transaction. Elle doit préserver ce qui a été acheté, y compris options sélectionnées ou personnalisations, même si le catalogue actuel change ensuite. Paramètres actuels de paiement, taxes, expédition, notifications, facturation et stock restent de la configuration pour les futurs Orders.
| Valeur historique | Signification dans l’Order Wix |
|---|---|
| Numéro Order source | Référence externe pour service Customer et rapprochement. |
| Ligne Product/variante | Titre acheté, variante, SKU, quantité, prix et choix sélectionnés. |
| Sortie de modifier ou personnalisation | Valeur fournie par l’acheteur ou générée par une application, reliée à la bonne ligne Order. |
| Remise, taxe et frais de livraison | Explication du total historique, non configuration des règles actuelles. |
| Données de paiement et remboursement | Historique financier lié à l’Order et au propriétaire de transaction. |
| Expédition, livraison, retrait ou traitement de service | État historique de traitement et contexte de suivi. |
| Référence de facture ou comptable | Relation Order/facture plus identifiant comptable externe. |
| Référence de canal de vente ou application | Source de l’Order et responsabilité de l’application externe. |
Les Orders Wix peuvent être créés par plusieurs solutions métier et intégrations Wix, pas uniquement Wix Stores. Un enregistrement source migré doit donc préserver l’application ou le canal à l’origine de la transaction lorsque cette distinction influence l’analyse opérationnelle, le traitement ou le service Customer.
Les Orders historiques ne doivent pas non plus créer artificiellement des Products actifs. Une ligne Order correspondant à un Product retiré, un service ponctuel ou une charge générée par une application peut rester compréhensible comme instantané sans ajouter un nouveau Product au catalogue actif.
Collections Wix CMS, Data Items, références et données externes
Wix CMS stocke des Data Items dans des collections. Ils peuvent contenir des champs typés et des références vers d’autres éléments. Wix prend aussi en charge des connexions à des bases externes qui exposent des collections extérieures via ses interfaces de données. Ces capacités rendent CMS utile pour le contenu structuré, annuaires, catalogues personnalisés, bibliothèques de ressources et données applicatives, mais CMS ne remplace pas Wix Stores, Contacts, Orders, Blog, Bookings, Events ou les autres propriétaires spécialisés.
Une table source personnalisée ne doit devenir collection Wix CMS que si l’enregistrement métier appartient réellement à un modèle de contenu ou de données personnalisées. Un Product qui doit participer au processus de commande Wix Stores, aux variantes, au stock et aux Orders doit rester un Product Wix Stores. Un Blog Post doit rester du contenu Blog si le fonctionnement éditorial importe. Un booking doit rester relié au système de réservation qui possède disponibilité et participation.
| Enregistrement source | Propriétaire Wix cible |
|---|---|
| Bibliothèque de spécifications Product | Info Sections, champs Product, collection CMS ou PIM externe selon réutilisation et autorité. |
| Ressource éditoriale ou annuaire | Collection CMS et Data Items avec références explicites et relations de pages dynamiques. |
| Article de blog | Wix Blog Post avec signification de publication, auteur, Category/tag, média et URL. |
| Catalogue Product personnalisé non vendu directement | Collection CMS ou base externe ; Wix Stores uniquement si un fonctionnement commercial est requis. |
| Enregistrement event, booking, cours ou membership | Application métier Wix pertinente plus relations Contact/Member et transaction. |
| Ligne de base de données externe | Relation de collection externe avec IDs stables et champs de référence. |
| Contenu de page builder | Présentation de page/section du site reliée aux enregistrements CMS ou commerciaux, non propriétaire de données de référence. |
Les champs de référence CMS préservent les relations entre enregistrements, par exemple une ressource liée à un auteur, une Category, un Product ou un emplacement. Aplatir ces relations en texte copié supprime la possibilité de mettre à jour et d’interroger les enregistrements indépendamment.
Pages du site, URLs, médias, données multilingues et SEO
Le contenu Wix peut inclure pages, pages dynamiques, Blog Posts, contenu piloté par CMS, médias, menus, pages Product, pages Category, redirections, champs SEO, domaines et variantes multilingues. Ces enregistrements déterminent comment catalogue et contenu sont présentés et découverts, sans remplacer le Product, l’élément CMS, le Contact ou l’Order sous-jacent.
Une mise en page de page builder source peut combiner références Product, texte, images, formulaires et widgets applicatifs. Le modèle cible doit séparer contenu et enregistrements métier réutilisables de la section visuelle qui les affiche.
| Ressource web source | Relation de responsabilité dans Wix |
|---|---|
| Titre, description, médias, URL et données SEO Product | Product Wix Stores et présentation de la page Product. |
| Page d’atterrissage Category | Category plus relation de page/navigation et contenu d’accompagnement. |
| CMS Page ou page de contenu dynamique | Page/page dynamique du site plus collection CMS et références Data Item. |
| Blog Post | Enregistrement Wix Blog avec auteur, publication, Category/tag, médias et signification de route. |
| Élément de menu | Relation de navigation pointant vers page, Category, Product, page dynamique, ancre ou URL externe. |
| Contenu multilingue | Champs et références propres à la langue dans le site/contenu/Product, non des enregistrements dupliqués sans lien sauf intention explicite. |
| URL source | Route cible plus relation de redirection lorsque le chemin change. |
| Thème ou composant Editor | Configuration de présentation faisant référence aux entités de contenu ou commerce qui font autorité. |
L’ancienne URL doit pointer vers un enregistrement cible connu. Une redirection est une relation entre routes ; elle ne remplace pas la définition du Product Wix, de la Category, de la page, du Blog Post ou de l’élément dynamique qui remplace la ressource source. Les liens internes et références média doivent aussi conserver leur destination prévue au lieu de préserver des chemins source obsolètes.
Applications, Velo, service plugins et responsabilité des systèmes externes
Applications Wix, code Velo, service plugins, automatisations, webhooks, bases externes et systèmes tiers peuvent posséder des données qui ne sont pas natives du catalogue Wix Stores. Reviews, subscriptions, fidélité, marketplaces, comptabilité, traitement, recherche avancée, flux Product, CRM et configurateurs personnalisés peuvent chacun introduire enregistrements et identifiants.
Une application cible qui remplit une fonction similaire ne prouve pas que les données de l’application source correspondent directement. Il faut comprendre l’entité propriétaire, le schéma de données, les clés de relation et le cycle de vie.
| Signal personnalisé ou externe | Propriétaire cible |
|---|---|
| ID ERP de Product ou variante | Product/variante plus relation ERP au niveau de catalogue reconnu par le système externe. |
| Clé de stock d’entrepôt | Inventory Item variante-emplacement plus système d’entrepôt. |
| ID CRM de Contact ou entreprise | Contact plus relation CRM/entreprise externe. |
| ID de listing marketplace | Relation Product/variante/canal, non champ Product générique. |
| Enregistrement Review, fidélité ou subscription | Application Wix ou système externe plus références Product, Contact, Member ou Order. |
| État d’un configurateur personnalisé | Propriétaire application/Velo/CMS plus Product/variante et sortie de ligne Order. |
| Enregistrement de base externe | Collection externe plus champs de référence Wix et clé durable du système externe. |
| Paramètre webhook ou service plugin | Configuration cible reliant des systèmes, non enregistrement Customer ou Product. |
Ce modèle de responsabilité évite de préserver des données personnalisées inutilisables. Une valeur n’est durable que lorsque les équipes connaissent son enregistrement parent, système faisant autorité, cycle de vie et consommateur. Des champs personnalisés génériques ne remplacent pas une relation définie Product→application, Contact→CRM, Order→marketplace ou CMS→base externe.
Chaînes de traduction Wix représentatives
Les chaînes relationnelles rendent la signification cible explicite en montrant l’enregistrement parent, les dépendances et, le cas échéant, le propriétaire externe. Elles sont particulièrement utiles dans Wix, car commerce, CRM, Members, CMS et applications peuvent tous contenir des données sur un même événement métier. Une chaîne complète indique quelle entité Wix fait autorité et quels enregistrements ne font que référencer ou présenter ces données.
| Modèle source | Relation Wix cible |
|---|---|
| Product textile avec stock taille/couleur | Version de catalogue → Product → options/choix → variantes → média/SKU variante → Inventory Items par emplacement. |
| Cadeau personnalisé | Product/variante → modifier ou saisie possédée par une application → personnalisation de ligne Order → référence de traitement. |
| Stock multi-emplacements | Variante → emplacement Wix → Inventory Item → clé d’entrepôt externe lorsque l’autre système reste autoritaire. |
| Customer utilisant aussi du contenu réservé | Contact/Customer → Orders et adresses ; Member → authentification/rôle/accès ; le consentement reste une relation de communication distincte. |
| Ressource CMS reliée à des Products | Collection CMS → Data Items/champs de référence → IDs Product Wix Stores → page dynamique/navigation. |
| Vente marketplace | Order → référence source/canal → instantané Product/variante de ligne → historique transaction/traitement → ID marketplace externe. |
| Category sensible au SEO | Arbre de Categories/appartenance Product → page ou route Category → navigation → URL cible → redirection source. |
Ces chaînes préservent la responsabilité propre à Wix tout en reconnaissant qu’une plateforme source peut avoir combiné données de commerce, contenu, identité et applications dans un même enregistrement ou une même table.
Conclusion
La traduction du modèle de données Wix commence par la version de catalogue du site cible et s’étend à Wix Stores, emplacements de stock, CRM Contacts, Members du site, eCommerce Orders, collections CMS, pages, contenu Blog, applications, Velo et systèmes externes. Ces familles d’enregistrements sont reliées, mais ne sont pas interchangeables.
Un modèle cible Wix solide affecte chaque valeur source au Product, à la variante, Customization, Category, emplacement, Inventory Item, Contact, Member, Order, élément CMS, enregistrement de contenu, application ou système externe qui possède sa signification continue. Cette structure préserve les relations commerciales et de contenu sans confondre données historiques et configuration future ni aplatir les données applicatives spécialisées en champs génériques.
Questions fréquentes
Pourquoi la version du catalogue Wix est-elle importante pendant la migration ?
Un site Wix utilise soit Catalog V1, soit Catalog V3, et les relations entre entités diffèrent. Catalog V3 emploie des variantes universelles et des services séparés pour le stock par variante et emplacement, les Categories, Brands, Customizations, Info Sections et autres enregistrements du catalogue.
Les options Product et modifiers Wix sont-ils identiques ?
Non. Options et choix créent des variantes pouvant porter SKU, prix, médias et stock. Les modifiers collectent personnalisation ou saisie facultative sans créer une variante ni une identité de stock séparée.
Tout Contact Wix peut-il devenir Member du site ?
Non. Un Contact est un enregistrement CRM et de relation métier. Un Member porte authentification et éventuellement profil, rôle, permission ou accès réservé. Un acheteur peut rester Contact/Customer sans recevoir de compte Member.
Les Orders Wix migrés configurent-ils le futur processus de commande ?
Non. Les Orders préservent articles achetés, choix, historique de paiement/remboursement, adresses, traitement, factures et références externes. Le fonctionnement actuel des paiements, taxes, expéditions, notifications et stocks reste une configuration séparée.
Quand des données personnalisées source doivent-elles devenir une collection Wix CMS ?
Utilisez CMS lorsque les données appartiennent à un modèle de contenu structuré ou d’enregistrements personnalisés qui bénéficie de champs, références, requêtes et pages dynamiques. Products, Orders, Contacts, Blog Posts, bookings, events et autres enregistrements spécialisés doivent rester chez leur propriétaire Wix natif lorsque ce fonctionnement est requis.
Comment représenter les données d’applications Wix et de systèmes externes ?
Conservez la valeur avec son Product, sa variante, son Contact, Member, Order, élément CMS ou autre enregistrement métier parent et préservez l’identifiant externe utilisé par l’application propriétaire. Une note générique ou un champ non structuré ne préserve pas la relation nécessaire à une synchronisation future.