Microsoft Dynamics 365 + Ziggu

Microsoft Dynamics 365 and Ziggu connect through Ziggu's public REST API, built by your own Microsoft partner or your internal developers. Projects and the units inside them are created in Ziggu, and the contact on the sale is synced across, triggered either by the deal reaching a status you choose or by a custom field your team fills in. Dynamics stays where the sale is run. Ziggu is the client portal where the client lives with the result.

Key takeaways

• There is no Ziggu app for Dynamics 365. The connection is built on Ziggu's public REST API, usually by the Microsoft partner you already work with.
• Projects and units are created in Ziggu, and the contact follows.
• You choose the trigger: a deal status, or a custom field such as one named sync-ziggu that someone ticks when a record is ready to move.
• The custom-field option exists because a deal status is a blunt instrument. A field lets you decide case by case without bending your sales process.
• Inviting the client stays a deliberate step your team takes in Ziggu, whatever the integration does.
• The schedule is whatever your integrator builds. Ziggu does not impose one.

Why the trigger matters more than the plumbing

Moving data out of Dynamics is the easy part. The question that decides whether the connection is useful is when a record should move.

A deal status is the obvious answer and it works when your pipeline is clean and every sale follows the same path. It stops working the moment you have deals that close but should not start yet, or projects that begin before the paperwork is finished.

That is why the second option exists. A custom field, ticked by whoever knows, moves a record when it is genuinely ready. Most teams end up using the status for the standard case and the field for the exceptions, which is the combination that survives contact with a real pipeline.

Project, unit, and why the difference matters here

Ziggu organises work as projects, and a project can hold one unit or hundreds. A unit is the smallest thing a single client has: one apartment in a development, one house, one fit-out, one order. Between project and unit sit optional levels, phases and lots and buildings, which large projects use and small ones never see.

If you run one job per client, your project and your unit are the same record and those levels stay invisible. If you deliver many inside one project, you use all of them. Your integrator needs to know which of the two you are before anything else is decided, because it changes what a Dynamics record has to become.

What data moves between Dynamics 365 and Ziggu

The first column is the name your team knows from the app, the second is the endpoint the connection writes to.

‍

Anything beyond this is possible on the same API, because the full endpoint list covers documents, decisions, instalments, snag lists and messages. It is not part of what teams run today, so treat it as work to scope rather than something you switch on.

How do you connect Dynamics 365 to Ziggu?

This one is built rather than deployed, so the sequence is a project, not a setup wizard.

1. Request an integration token from Ziggu. Tokens are issued per organisation.
2. Decide the trigger with your sales team: a deal status, a custom field, or both.
3. Agree the mapping. Which Dynamics record becomes a Ziggu project, which becomes a unit, and how the contact finds its way to the right one.
4. Your Microsoft partner or your own developers build it against api.ziggu.app/public. Endpoint reference: Ziggu API documentation.
5. Test on one deal end to end, and look at what the client sees in their portal before you turn it on for the pipeline.

If you would rather not build, the same job can be done with a ready-made connector platform. That is how Ziggu customers connect Microsoft SharePoint and Teamleader Focus.

Where teams use it

Having the project ready before anyone asks for it

The gap between a signature and the first real contact is where confidence is lost. When the sale creates the project, everything is already standing when your team decides to open the portal, rather than being built the week after the client asked why they have heard nothing.

Keeping Dynamics as the sales record without keeping clients out

Dynamics holds the pipeline, the forecast and the internal notes, and none of that is client material. Ziggu shows the client their own project. The two do not have to become one system for the data to line up.

Running it across a portfolio

Once projects and units exist in Ziggu, everything else attaches to them: documents, decisions, snag lists. See how property developers use Ziggu.

What Dynamics 365 and Ziggu do not do

• There is no Ziggu app in Microsoft AppSource and no connector inside Dynamics. Somebody builds this, and that somebody is usually your Microsoft partner.
• Clients are not invited automatically. Whatever the integration creates, a person in Ziggu decides when the portal opens.
• Ziggu does not set the schedule. How often the connection runs, and whether it reacts to an event or polls, is what your integrator builds.
• Document and invoicing flows are not part of what teams run today. The API supports them, but that is scope for a project rather than something waiting to be switched on.
• Data flows from Dynamics into Ziggu. Nothing is written back unless your integrator builds that too.
• Ziggu's API is rate limited to 60 requests per minute across all endpoints, which is what shapes a first load of an existing pipeline.

Questions about the Dynamics 365 integration

Is there a Ziggu app for Dynamics 365?

No. The connection is built on Ziggu's public REST API, normally by the Microsoft partner you already work with.

What makes a project appear in Ziggu?

A trigger you choose: a deal reaching a status, or a custom field someone ticks when the record is ready. Many teams use both.

Why would we use a custom field instead of the deal status?

Because a status moves everything that reaches it. A field lets you move a record when it is genuinely ready, without changing how your pipeline is set up.

Does the client get invited automatically?

No. The integration prepares the project and the contact; someone on your team sends the invitation from Ziggu once the portal is ready to be seen.

How often does it sync?

Whatever your integrator builds. Ziggu does not impose a schedule on this route.

Can we sync documents and invoices too?

The API supports it. It is not what teams run today, so scope it as part of the build rather than expecting it out of the box.

We would rather not build anything.

Then look at a ready-made connector platform, the route behind Microsoft SharePoint. Or, if you want Ziggu to build and run it, see Salesforce and Ziggu.

Last verified: 28 August 2026.