Microsoft SharePoint + Ziggu

Microsoft SharePoint en Ziggu koppelen via de publieke REST API van Ziggu. De documenten die je aanduidt om te delen worden naar het juiste project in Ziggu geschreven, onder de juiste categorie, en de klant krijgt een melding. SharePoint blijft de werkomgeving van je team met zijn drafts en interne versies, en het klantportaal toont de klant alleen wat jij besloot te delen.

In het kort

• Microsoft SharePoint koppelt aan Ziggu via de publieke REST API van Ziggu. Je kan het zelf bouwen, je partner laten bouwen, of een kant-en-klare template op Peliqan gebruiken.
• Documenten worden gekoppeld aan een project en een documentcategorie in Ziggu, met je SharePoint-mappenstructuur of je metadata als regel.
• Klanten krijgen nooit een SharePoint-login. Ze zien de documenten die in hun project geschreven werden, en niets eromheen.
• Dit is een geplande koppeling, geen event-gestuurde. Een bestand verschijnt in Ziggu bij de volgende ronde, en jij bepaalt hoe vaak dat is.

Waarom de SharePoint-map niet delen

Omdat die map niet klaar is voor een klant, en dat ook nooit zal zijn. Ze bevat drafts, achterhaalde versies, interne notities en de bestanden van andere klanten. Een submap delen betekent voor altijd rechten onderhouden op elke nieuwe map, en één verkeerde overerving is een lek.

De gebruikelijke omweg is de finale PDF mailen, en die maakt zijn eigen probleem: achteraf kan niemand nog zeggen welke versie de klant effectief gekregen heeft. Het document naar het project van de klant in Ziggu schrijven lost allebei op. Er is één actuele versie, de klant krijgt een melding, en je ziet wie het geopend heeft. Zie Documenten.

Welke data beweegt tussen Microsoft SharePoint en Ziggu

De eerste kolom is de naam die je team uit de app kent, de tweede is het endpoint dat je ontwikkelaar effectief aanroept.

‍

Hoe koppel je Microsoft SharePoint aan Ziggu?

Drie routes, dezelfde API eronder. Kies degene die past bij wie het gaat onderhouden.

1. Zelf bouwen. Vraag een integratietoken aan bij Ziggu en schrijf tegen api.ziggu.app/public. Tokens worden per organisatie uitgegeven. Endpointreferentie: Ziggu API-documentatie.
2. Je integratiepartner laten bouwen. Dezelfde API, hetzelfde token, andermans onderhoud.
3. Een kant-en-klare template op Peliqan gebruiken. Uitgerold en geconfigureerd in plaats van geschreven, en per klant aangepast.

Welke route je ook kiest, één beslissing komt eerst en bepaalt al de rest: de regel die zegt welk bestand bij welk project hoort. Een map per project is de simpele versie. Een metadatakolom is de flexibele. Leg dat vast, laat het één keer lopen op één projectmap, en kijk naar wat de klant zou zien voor je het breder zet.

Waar teams het voor gebruiken

De goedgekeurde versie delen, niet de map waar ze uit komt

Je team blijft werken zoals het werkt, met drafts en revisies in SharePoint. Alleen wat jouw regel als deelbaar aanduidt, gaat de grens over, dus de klant krijgt het goedgekeurde plan en ziet de zes versies ervoor nooit.

Het opleverdossier zichzelf laten samenstellen

Elk document dat de klant bij oplevering moet krijgen, staat al in SharePoint. In plaats van op het eind met de hand een dossier samen te stellen, belandt elk document in het project van de klant zodra het definitief is, en bestaat het dossier omdat het project af is.

Een hele portefeuille dezelfde documentstructuur geven

Eén mappatroon in SharePoint wordt dezelfde categoriestructuur in elk project in Ziggu. Een klant op het ene project en een klant op het andere vinden hun documenten op dezelfde plek, en dat is wat het portaal voorspelbaar genoeg maakt om te stoppen met vragen. Zie hoe projectontwikkelaars Ziggu gebruiken.

Wat Microsoft SharePoint en Ziggu niet doen

• Dit is een geplande koppeling, geen event-gestuurde. Een bestand dat je in SharePoint opslaat, verschijnt in Ziggu bij de volgende ronde. Jij bepaalt het schema.
• Er zit geen Ziggu-app in SharePoint. Iemand bouwt of rolt de koppeling uit, of dat nu jij bent, je partner of een template op Peliqan.
• Projecten worden gematcht, niet aangemaakt. Een document waarvan de map of de metadata niet naar een bestaand Ziggu-project leidt, heeft nergens om te landen, dus de mappingregel moet kloppen voor je opschaalt.
• Wat een concrete implementatie verplaatst, spreek je af bij de setup. Behandel de tabel hierboven als de vorm van de koppeling, niet als een vast contract.
• De API van Ziggu is beperkt tot 60 requests per minuut over alle endpoints samen, en dat bepaalt hoe een eerste lading van een bestaande documentbibliotheek verloopt.

Vragen over de SharePoint-integratie

Hebben onze klanten SharePoint-toegang nodig?

Nee. Dat is net het punt. Klanten zien alleen documenten die in hun eigen Ziggu-project geschreven werden.

Hoe komt een bestand in het juiste project terecht?

Via de regel die jij vastlegt: een map per project, of een metadatakolom in SharePoint die het project benoemt. De koppeling leidt daaruit een bestaand Ziggu-project af.

Hoe snel verschijnt een document in Ziggu?

Bij de volgende geplande ronde. Jij bepaalt het schema.

Krijgt de klant een melding wanneer er een document binnenkomt?

Ja, op dezelfde manier als bij elk ander document in Ziggu. Je ziet ook wie het geopend heeft.

Welke kant beweegt het op?

Documenten gaan van SharePoint naar Ziggu. Alles daarbuiten is een beslissing die je neemt wanneer de koppeling gebouwd wordt.

Wij gebruiken iets anders voor documenten. Werkt dat ook?

Ja. Nextcloud en Dynamics 365 dekken hetzelfde terrein, elk via hun eigen route.

Laatst nagekeken: 28 augustus 2026.