Microsoft Dynamics 365 et Ziggu se connectent via l'API REST publique de Ziggu, construite par votre propre partenaire Microsoft ou vos développeurs internes. Les projets et les unités qu'ils contiennent sont créés dans Ziggu, et le contact de la vente est synchronisé, déclenché soit par le deal qui atteint un statut que vous choisissez, soit par un champ personnalisé que votre équipe remplit. Dynamics reste l'endroit où la vente se pilote. Ziggu est le portail client où le client vit avec le résultat.
Sortir des données de Dynamics est la partie facile. La question qui décide si la connexion est utile, c'est quand une fiche doit bouger.
Un statut de deal est la réponse évidente et il fonctionne tant que votre pipeline est propre et que chaque vente suit le même chemin. Il cesse de fonctionner dès que vous avez des deals qui se concluent mais ne doivent pas encore démarrer, ou des projets qui commencent avant que la paperasse soit bouclée.
C'est pour cela que la seconde option existe. Un champ personnalisé, coché par celui qui sait, déplace une fiche quand elle est vraiment prête. La plupart des équipes finissent par utiliser le statut pour le cas standard et le champ pour les exceptions, et c'est la combinaison qui survit à un vrai pipeline.
Ziggu organise le travail en projets, et un projet peut contenir une unité ou des centaines. Une unité est la plus petite chose qu'un client possède : un appartement dans une promotion, une maison, un aménagement, une commande. Entre le projet et l'unité se trouvent des niveaux optionnels, phases, lots et bâtiments, que les grands projets utilisent et que les petits ne voient jamais.
Si vous menez un chantier par client, votre projet et votre unité sont la même fiche et ces niveaux restent invisibles. Si vous en livrez plusieurs dans un même projet, vous les utilisez tous. Votre intégrateur doit savoir dans quel cas vous êtes avant toute autre décision, car cela change ce qu'une fiche Dynamics doit devenir.
La première colonne est le nom que votre équipe connaît dans l'application, la seconde est l'endpoint vers lequel la connexion écrit.
| Ce que c'est dans Ziggu | Endpoint | Sens | Quand |
|---|---|---|---|
| Les projets, et les unités qu'ils contiennent | /projects, /units | Dynamics 365 vers Ziggu | Sur votre déclencheur |
| Le contact de la vente, rattaché à la bonne unité | /customers, /unit_customers | Dynamics 365 vers Ziggu | Une fois le projet ou l'unité créé |
| L'entreprise derrière le contact | /companies | Dynamics 365 vers Ziggu | Avec le contact |
| L'invitation au portail | Envoyée depuis Ziggu par votre équipe | Manuel | Quand vous décidez que le portail est prêt |
Tout le reste est possible sur la même API, puisque la liste complète des endpoints couvre documents, décisions, tranches, listes de réserves et messages. Ce n'est pas ce que les équipes exploitent aujourd'hui : traitez-le comme un chantier à cadrer, pas comme un interrupteur.
Celle-ci se construit plutôt qu'elle ne se déploie, donc la séquence est un projet et non un assistant d'installation.
Si vous préférez ne rien construire, une plateforme de connecteurs prête à l'emploi peut faire le même travail. C'est ainsi que des clients Ziggu connectent Microsoft SharePoint et Teamleader Focus.
L'écart entre une signature et le premier vrai contact est l'endroit où la confiance se perd. Quand la vente crée le projet, tout est déjà debout quand votre équipe décide d'ouvrir le portail, au lieu d'être montré en hâte la semaine où le client demande pourquoi il n'a rien reçu.
Dynamics contient le pipeline, le forecast et les notes internes, et rien de tout cela n'est destiné au client. Ziggu montre au client son propre projet. Les deux n'ont pas besoin de fusionner pour que les données s'alignent.
Dès que projets et unités existent dans Ziggu, tout le reste s'y rattache : documents, décisions, listes de réserves. Voir comment les promoteurs immobiliers utilisent Ziggu.
Non. La connexion se construit sur l'API REST publique de Ziggu, normalement par le partenaire Microsoft avec lequel vous travaillez déjà.
Un déclencheur que vous choisissez : un deal qui atteint un statut, ou un champ personnalisé coché quand la fiche est prête. Beaucoup d'équipes utilisent les deux.
Parce qu'un statut déplace tout ce qui l'atteint. Un champ vous laisse déplacer une fiche quand elle est vraiment prête, sans changer la configuration de votre pipeline.
Non. L'intégration prépare le projet et le contact ; quelqu'un de votre équipe envoie l'invitation depuis Ziggu une fois le portail prêt à être vu.
Celle que votre intégrateur construit. Ziggu n'impose pas de rythme sur cette voie.
L'API le permet. Ce n'est pas ce que les équipes exploitent aujourd'hui, donc cadrez-le dans le chantier plutôt que de l'attendre prêt à l'emploi.
Regardez alors une plateforme de connecteurs prête à l'emploi, la voie derrière Microsoft SharePoint. Ou, si vous voulez que Ziggu construise et exploite, voir Salesforce et Ziggu.
Dernière vérification : 28 août 2026.
Ziggu already integrates seamlessly with a number of CRM, ERP and document management systems. Can't find yours? Contact us and we'll research the possibilities!
CONTACT US
