De handigste SharePoint-skills van de community, overzichtelijk in één dashboard

Marcel

De Microsoft 365-community is op zijn best wanneer mensen hun oplossingen niet voor zichzelf houden, maar teruggeven aan de rest. Precies dat gebeurt in de Patterns & Practices-community (PnP): vakgenoten van over de hele wereld bouwen kant-en-klare AI-skills voor Copilot in SharePoint en delen ze gratis. Caring is sharing, zoals we vroeger riepen.

Het enige nadeel: er zijn er inmiddels zoveel dat je door de bomen het bos niet meer ziet. Daarom heb ik ze voor je op een rij gezet in één overzichtelijk dashboard. Je vindt het verderop in deze blog, en ik neem je er hieronder alvast doorheen.

Wat zijn deze skills eigenlijk?

Een skill is een instructiebestand dat je uploadt naar een speciale Skills-bibliotheek op je SharePoint-site. Copilot in SharePoint pikt hem daar op en krijgt er een nieuwe vaardigheid bij. Geen code, geen developer: je geeft in gewone taal een opdracht en de skill doet de rest. Denk aan het opsporen van dode links, het opschonen van een bibliotheek, of het bouwen van een contentkalender.

Alles komt uit de open repository van Microsoft 365 PnP. Het is community-materiaal, geen officiële Microsoft-oplossing, dus je gebruikt het onder eigen regie en test het eerst rustig in een veilige omgeving. Een Copilot-licentie heb je wel nodig.

52 skills, geordend in acht clusters

In het dashboard hieronder heb ik alle 52 skills verdeeld over acht herkenbare clusters, zodat je meteen ziet wat er voor jou tussen zit:

  • Governance en audits: read-only rapporten over verouderde pagina’s, verweesde nieuwsberichten, dode links, rechten en gastaccounts. Ze brengen in kaart, ze wijzigen niks.
  • Opschonen en organiseren: bibliotheken structureren, bestanden classificeren en automatisch van metadata voorzien.
  • Visuele stijlthema’s: tien kant-en-klare looks waarmee je een saaie lijst omtovert tot iets waarvan je denkt “is dit echt SharePoint?”.
  • Content en intranet: contentkalenders, uitleg-dashboards en een documentbrowser. Direct interessant voor redactie en communicatie.
  • Rapportage en dashboards: management-rapporten, roadmaps en vergelijkingsmatrixen uit je eigen data.
  • Project Intelligence: een keten die projectdocumenten uitleest en er inzichten en beslissingen uit haalt.
  • RFP-respons: een complete offertemachine, van eisen extraheren tot de review.
  • Bouwen en overig: complete oplossingen bouwen, skills converteren en documenten laten stress-testen.

Waar ik zelf enthousiast van word

Zit je in marketing of communicatie, dan zijn twee clusters extra de moeite waard. De governance-skills brengen zonder enig risico in kaart waar je intranet vervuilt: welke pagina’s al maanden niet zijn aangeraakt, welke nieuwsberichten geen eigenaar meer hebben, welke links dood zijn. En de stijlthema’s laten zien dat SharePoint er echt niet grijs en saai uit hoeft te zien.

Dat sluit naadloos aan bij waar ik in geloof: van zenden naar verbinden. Een digitale werkplek die actueel en verzorgd is, nodigt mensen uit om er te zijn. En pas dan ontstaat er echte verbinding.

Bekijk het dashboard

Genoeg gepraat, blader er zelf doorheen. Je kunt in het dashboard zoeken op trefwoord, filteren per cluster en met één klik doorklikken naar de bron op GitHub. Pik eruit wat jouw intranet slimmer en mooier maakt, en deel het vooral weer met je eigen collega’s. Want zo houden we deze community sterk.

Open dashboard op volledig scherm ↗


Kan SharePoint wel in onze huisstijl?

Marcel

Laatst zat ik bij een communicatieteam aan tafel en binnen vijf minuten viel de zin die ik inmiddels bijna kan dromen: “SharePoint, dat ziet er toch overal hetzelfde uit? Onze ontwerpers kunnen daar niks mee.” Ik snap waar dat vandaan komt. Wie SharePoint een paar jaar geleden voor het laatst echt heeft bekeken, houdt een beeld over van grijze balken en een verplicht lettertype.

Maar dat beeld is verouderd. Microsoft heeft de visuele kant van SharePoint flink aangepakt, en die updates druppelen om de een of andere reden nauwelijks door naar de mensen die er het meest aan hebben: marketing en communicatie. Vijf dingen wil ik daarom uitlichten. Bij elk zeg ik er eerlijk bij wat je vandaag al kunt en wat nog aan het uitrollen is, want niets is vervelender dan iets beloven aan je organisatie dat er nog niet is.

1. Je eigen merk-lettertypes

Begin bij het lettertype, want dat zie je als eerste. Lange tijd was dat het pijnpunt: je zat vast aan wat SharePoint je gaf. Dat is voorbij sinds het Brand Center. Daar upload je gewoon je eigen merk-fonts (.ttf, .otf, .woff en .woff2, tot 10 MB per bestand) en bundel je ze tot een font package.

Zo’n pakket kent vier rollen: Title, Headline, Body en Interactive. In de praktijk zet je bijvoorbeeld een stevig display-font op je koppen en iets rustigs en leesbaars op je broodtekst. Site-eigenaren pikken dat pakket daarna zelf op via Wijzig het uiterlijk, onder “Van mijn organisatie”.

Let op twee dingen, want die vergeet men steevast. De eerste inrichting doet een beheerder eenmalig (het Brand Center draait op Public CDN). En je merk-fonts werken in SharePoint en Viva Connections, maar niet automatisch in Word of PowerPoint op je bureaublad. Voor PowerPoint op het web is er wel losse organisatiefont-ondersteuning, voor klanten met E3 of E5.

En bedenk: fonts erin zetten is een ding, ze eruit halen als een licentie afloopt is net zo goed onderdeel van je beheer. Daar schreef ik eerder over in mijn stuk over het opruimen van oude brand fonts.

2. Headers en sfeerbeelden

De kop van een pagina is je etalage, en daar valt meer te kiezen dan mensen denken. Op siteniveau heb je header-layouts als Standard, Compact, Minimal en Extended. Op de pagina zelf bepaal je met het titelgebied hoe je kop overkomt: Afbeelding en titel, Effen, Kleurblok, tot een paginabreed beeld met tekst eroverheen.

En daaronder geef je secties een eigen achtergrondkleur of een achtergrondafbeelding. Daarmee krijgt een campagnepagina een compleet andere sfeer dan een afdelingspagina. Die ene saaie platte balk waar iedereen zich zorgen om maakte, die hoeft dus echt niet meer.

3. Design Ideas en AI-secties: sneller naar een mooie opzet

Geen inspiratie voor een lay-out? SharePoint heeft, net als PowerPoint, een Design Ideas-functie. In SharePoint heet die Section Design Ideas. Je klikt op het shimmer-icoon in de paginawerkbalk en SharePoint stelt op basis van je content passende lay-outs, beeld en opmaak voor een sectie voor. Een klik en het staat erop. Voor iedereen die geen grafisch ontwerper is, scheelt dat echt.

Handig om te weten hoe ver het reikt. Design Ideas werkt voor secties met bijvoorbeeld een banner-webonderdeel, met een tot drie tekst-webonderdelen, of met een gelijk aantal tekst- en afbeeldings-webonderdelen. Het werkt niet overal: niet bij full-width of verticale secties, niet bij meer dan drie webonderdelen, en niet bij onderdelen als Snelle koppelingen. In niet-overheidstenants zoekt de functie er ook passende stockbeelden bij op basis van je tekst.

Daarnaast is er Sections with AI, waarmee de AI complete secties voorstelt op basis van wat je wilt vertellen. En je begint sowieso zelden bij een leeg canvas, want SharePoint levert ingebouwde sjablonen voor sites, pagina’s en secties.

Nog een weetje voor wie SharePoint langer volgt. De oude SharePoint Look Book, die galerij met voorbeeldontwerpen, is bij Microsoft niet meer als dienst beschikbaar. De ontwerpen bestaan nog wel, als open-source PnP-templates op GitHub, die een beheerder met PnP PowerShell uitrolt. Handig,

4. AI die de eerste opzet voor je maakt (rolt nu uit)

Dit vind ik het spannendste stuk, en juist hier moet ik precies zijn. Copilot in SharePoint laat je in gewone taal beschrijven wat je nodig hebt, en stelt dan een opzet voor: hele sites of losse pagina’s, met structuur en voorbeeldcontent. Jij checkt en schaaft dat plan bij voordat er iets echt wordt aangemaakt.

En nu de nuance die je richting je organisatie niet mag overslaan. Dit rolt nog uit. Sites maken met AI begint volgens Microsoft rond april 2026, en Copilot in SharePoint komt vanaf medio juni 2026 als opt-out preview automatisch beschikbaar voor iedereen met een Copilot-licentie. Verkoop het dus niet als iets van vandaag, en vergeet niet dat die Copilot-licentie een voorwaarde is. Ik heb liever dat een klant aangenaam verrast is dan teleurgesteld.

Waar dit trouwens interessant gaat worden, is de combinatie met HTML-pagina’s die je straks rechtstreeks in SharePoint kwijt kunt. Daar ging mijn eerdere stuk over HTML-pagina’s in SharePoint dieper op in.

5. Waar het echt om draait: grip op je merk

Al die losse knoppen zijn aardig, maar de winst zit in de combinatie. Zet in de Organisatie-beeldbank alleen goedgekeurde logo’s, kleuren en beelden klaar. Leg daar je font packages en huisstijlkleuren uit het Brand Center overheen. Dan gebeurt er iets waar ik als consultant blij van word: je collega’s kunnen alleen nog kiezen binnen de kaders die jij hebt gezet.

En dat mooie is: die beeldbank werkt allang niet meer alleen in SharePoint. Sinds kort haalt PowerPoint diezelfde goedgekeurde beelden op via Insert, Pictures, Brand Images, op desktop en op het web. Een bron dus, die zowel je intranet als je presentaties voedt. Voor redacteuren is dat fijn, maar eigenlijk voor iedereen die iets in de huisstijl moet maken. Let op: voor PowerPoint op het web geldt een E3- of E5-licentie, en een beheerder moet de beeldbank als doorzoekbaar instellen.

Het scheelt gedoe. Geen zoektocht meer naar wie de verkeerde logo-versie op de nieuwspagina heeft gezet, want die versie staat er simpelweg niet meer tussen. Je geeft mensen vrijheid, maar wel op de rails van je merk.

Zo pak je het in de praktijk aan

Even concreet, want “SharePoint kan huisstijl” is nog geen werkwijze. Wat in de praktijk werkt:

Zet eerst je herbruikbare bouwstenen centraal neer, conform je huisstijlboek: je typografie, kleuren en thema in het Brand Center, je goedgekeurde beelden in de beeldbank. Ontwerp daarna je hoofdsite goed, met een landingspagina en een basisnavigatie die als voorbeeld dienen. En rol dat dan uit.

Voor die uitrol heeft SharePoint twee mechanismen die je model kloppend maken. Koppel je sites aan een hub, dan erven ze automatisch het thema en de gedeelde navigatie van die hub. En met een site template leg je een standaard vast, thema, navigatie en instellingen, die je op nieuwe of bestaande sites toepast.

Twee dingen om niet te vergeten. Je pagina- en nieuwssjablonen erven niet automatisch mee via een hub. Die staan per site in Site-inhoud, onder Pagina’s, in de map Templates, en die kopieer je door of neem je op in je site template. Precies daar zit ook een governance-vraag: wie mag die sjablonen aanpassen? Daar ging mijn post over paginasjablonen op slot zetten over. En let op group-connected team sites: een custom thema of logo van de hub wordt daar niet vanzelf toegepast, dat moet handmatig. Bij communicatiesites gaat het wel automatisch.

Even terugkomen op die openingszin

SharePoint is geen starre IT-omgeving meer, maar een serieus intern communicatiekanaal. De technische muren die dat oude beeld in stand hielden zijn grotendeels gesloopt. Het gaat er niet meer om of je merk erin past. Het gaat erom hoe strak je de merkregie neerzet, zodat je huisstijl vanzelf klopt.

Mijn tip: begin niet bij het uiterlijk van een pagina, maar bij je bouwstenen in het Brand Center en de beeldbank. Dat is het fundament dat elke site kan overnemen. Maar denk niet dat je er dan bent. Je templates, je navigatie en je headers richt je daarnaast in, per site en per pagina. Het Brand Center geeft je het palet. Wat je ermee schildert, blijft mensenwerk.

Welke huisstijl-frustratie met jullie intranet zou jij het liefst als eerste de deur uit doen? Zet het in de reacties, ik denk graag mee.

Bronnen

Microsoft 365 SharePoint Online – 4 essentiële sitetypen onthuld!

Marcel

Deze week bezocht ik een klant om te praten over hun bedrijfsintranet. We wilden weten: hoe kunnen we verschillende sites binnen het bedrijf slim met elkaar verbinden?

Samen hebben we gekeken naar de verschillende soorten sites in Microsoft 365. Dat wil ik graag met jullie delen!

Soorten sites in Microsoft 365.

In SharePoint zijn er twee belangrijke soorten sites:

Teamsites 👥 Een teamsite is een plek waar collega’s samen kunnen werken

  • Geschikt voor projecten en afdelingen
  • Vaak gekoppeld aan een Microsoft Team
  • Iedereen uit het team kan hier documenten delen en samenwerken

Communicatiesites 📰 Een communicatiesite is bedoeld om informatie te delen met veel mensen binnen je bedrijf.

  • Geschikt voor bedrijfsnieuws
  • Leuk en aantrekkelijk vormgegeven
  • Eenrichtingsverkeer: van organisatie naar medewerkers
Artikelcontent
Voorbeeld van verschillende sites binnen een organisatie (bron: Microsoft)

Extra mogelijkheden: Hub Sites en Homesites

Deze speciale sites geven je extra mogelijkheden om verschillende sites van je organisatie beter met elkaar te verbinden. Zo maak je één samenhangend geheel voor alle interne sites

Hub Sites 🔗

Hubsites helpen je om structuur in je sites aan te brengen. Bijvoorbeeld op onderwerp geclusterde sites.

  • Gedeelde top navigatie
  • Uniforme huisstijl / rechten
  • Zoekfunctionaliteit binnen de geclusterde sites
  • Je kunt zowel team- als communicatiesites promoveren tot hubsite
  • Aan een hubsite kun je zowel team- als communicatiesites koppelen

Homesite 🏠

Digitale voorpagina van je intranet

  • Een homesite is een gepromoveerde communicatiesite
  • Dé hoofdsite / landingspagina van je intranet
  • Kan geïntegreerd worden in Teams
  • Organisatiebrede overzicht van alle informatie en nieuws.
  • Gepersonaliseerde content op basis van jouw rol in het bedrijf
  • Centrale landingspagina – voorkomt verwarring welke site nu leidend is

Praktijkvoorbeeld

Een intranet voor het hele bedrijf maar ook met met losse teamsites die geen onderdeel uitmaken van het intranet. Ze zijn niet verbonden met het menu in het intranet en kunnen een afwijkende stijl hebben.

Artikelcontent

Tips voor een goede indeling💡

  • Maximaal drie navigatieniveaus in je menu
  • Houd rechten (wie mag wat zien) zo simpel mogelijk
  • Maak een logische, intuïtieve navigatie zodat iedereen makkelijk kan vinden wat hij zoekt.

Referentielink https://support.microsoft.com/nl-nl/office/de-sjabloon-sharepoint-team-samenwerkingssite-gebruiken-75545757-36c3-46a7-beed-0aaa74f0401e

#Microsoft365 #SharePoint #IntranetDesign #DigitalWorkplace #OrganizationalCommunication

Ambassadeurs in je organisatie: de sleutel tot succesvolle adoptie van je intranet

Marcel

Veel communicatieprofessionals herkennen het spanningsveld: het management wil tempo maken met nieuwe tools, terwijl medewerkers zich juist overspoeld voelen.

Nieuwsberichten worden nauwelijks gelezen, trainingen zijn snel vergeten en de helpdesk krijgt het drukker in plaats van rustiger. De klassieke aanpak van zenden en informeren schiet tekort. Niet omdat de intentie verkeerd is, maar omdat het niet aansluit bij hoe gedragsverandering in de praktijk werkt.

Verandering van binnenuit

Wat beter werkt: collega’s die het goede voorbeeld geven. Niet vanuit de top, maar vanuit de werkvloer zelf. Mensen die in hun team laten zien hoe nieuwe tools helpen, vragen opvangen en praktische tips delen.

Die collega’s noemen we ambassadeurs. Microsoft noemt ze ‘champions’. Hoe je ze ook noemt: het zijn mensen die helpen om verandering van binnenuit te laten slagen.

Waar vind je ambassadeurs?

Ambassadeurs zijn vaak niet de usual suspects. Je vindt ze op plekken waar je misschien niet meteen aan denkt:

  • Collega’s die tijdens trainingen veel vragen stellen (ze denken namens velen)
  • Teams die vaak bij de helpdesk aankloppen (vaak leergierig en zoekend)
  • Mensen die creatieve omwegen bedenken (praktisch en oplossingsgericht)
  • Kritische medewerkers die, als je ze meekrijgt, juist heel overtuigend zijn

Een sterk ambassadeursnetwerk is een afspiegeling van je organisatie. Betrek mensen uit verschillende afdelingen, functieniveaus en werkcontexten – van beleid tot uitvoering, van digitaal vaardig tot aarzelend verkennend.

Wat geef je ambassadeurs terug?

Zo’n rol hoeft geen extra belasting te zijn én hoeft niet veel te kosten. Een aantal voorbeelden:

  • Erkenning: een bedankje van het MT, een vermelding in de nieuwsbrief
  • Groei: voorrang bij trainingen of presentaties geven in teamverband
  • Invloed: meedenken over communicatie of nieuwe functionaliteiten
  • Verbinding: een community waarin ambassadeurs ervaringen uitwisselen

Hoe houd je het levend?

Eenmalige aandacht is niet genoeg. Zorg dat het programma duurzaam is ingebed:

  • Veranker de rol in ontwikkelgesprekken of teamafspraken
  • Organiseer kennisdelingssessies of inspiratiebijeenkomsten
  • Deel successen zichtbaar in de organisatie
  • Bouw toe naar een groep die zelf initiatief neemt en kennis doorgeeft

De impact: meer dan adoptie alleen

Ambassadeurs zorgen voor draagvlak, begrijpelijke uitleg en praktische hulp. Maar hun waarde gaat verder: ze versterken onderlinge verbinding en maken van een technisch project een organisatieontwikkelingstraject.

De praktijk laat zien: programma’s die 12 tot 18 maanden de ruimte krijgen, leveren blijvende impact op.

Wil je hiermee aan de slag?

Microsoft heeft hiervoor een uitgebreid Champions-programma beschikbaar gesteld, inclusief formats, inspiratie en trainingstools: https://adoption.microsoft.com/en-us/champions/

Voor wie het structureel wil aanpakken: er is zelfs een gratis Teams-app (Champions Management Platform) waarmee je ambassadeurs kunt registreren, ondersteunen en activeren. Met optionele gamification zoals badges, challenges en scorekaarten.

Let wel: in de Nederlandse praktijk werkt het vaak het best als je de nadruk legt op samenwerking, zichtbaarheid en eigenaarschap – niet zozeer op competitie.

Meer info over de app: https://adoption.microsoft.com/en-us/champions/teams-app/

Kun je een SharePoint-nieuwsbericht delen in Viva Engage?

Marcel

Kun je een SharePoint-nieuwsbericht delen in Viva Engage?

Ja. En vanaf eind september gaat dat een stuk beter dan nu.

Microsoft rolt cross-posting uit tussen SharePoint News en Viva Engage. Je stuurt een nieuwsbericht rechtstreeks naar een community of storyline, het bericht wordt volledig getoond in de Engage-feed, en alle reacties uit SharePoint én uit Engage komen samen in één gesprek.

Klinkt als een detail. Voor wie het interne nieuws verzorgt, is het dat niet.

Wat kon er al, en waarom dat schuurde

Je nieuws in een community krijgen kon natuurlijk allang. Alleen niet elegant.

De meest gebruikte route: het nieuwsbericht publiceren in SharePoint, de link kopiëren, en die in de community plakken. Wat je dan krijgt is een linkvoorbeeld een klein kaartje met een thumbnail en een titel. Wie het bericht wil lezen, moet doorklikken.

Daarnaast bestaan er alternatieven. De Viva Engage-homefeed toont SharePoint-nieuws. Je kunt de Conversations-webpart op een SharePoint-pagina zetten, zodat het gesprek naast het nieuws staat. En met Power Automate kun je via RSS berichten naar een community sturen.

Allemaal bruikbaar. Maar ze lossen geen van alle het echte probleem op: je hebt na afloop twee plekken waar het gesprek plaatsvindt. Iemand reageert onder de SharePoint-pagina, iemand anders reageert in de community, en jij zit als redacteur twee kanalen te bewaken. De beste vraag staat net op de plek waar de helft van je collega’s niet kijkt.

Wat er verandert

Twee dingen.

Het bericht zelf verschijnt in de feed. Geen klein linkkaartje meer, maar de kop, de afbeelding, de tussenkoppen, de alinea’s en de opsommingen van je nieuwsbericht gerenderd in de Engage-feed, met een fade-out onderaan en een link “Nieuwsbericht bekijken”. Direct daaronder staan de reactieknoppen en een reactieveld.

Klik je op “Nieuwsbericht bekijken”, dan open je de volledige SharePoint-pagina. Microsoft is daar expliciet over: het is geen screenshot en geen uitgeklede kopie. Secties, afbeeldingen, knoppen, links en zelfs custom SPFx-webparts blijven gewoon werken. Wat je in SharePoint hebt gebouwd, blijft overeind.

De reacties worden één gesprek. Comments, replies en reacties die iemand plaatst in SharePoint of vanuit welk Engage-kanaal dan ook, verschijnen in dezelfde thread. Inclusief geneste antwoorden. Lezers reageren waar het hun uitkomt; jij hoeft maar één discussie te volgen.

En dat werkt over alle Engage-oppervlakken: web, mobiele app, en de Engage-apps in Microsoft Teams en Outlook.

Heb je hier een Viva-licentie voor nodig?

Nee. En dat is misschien wel het prettigste nieuws.

Cross-posting is beschikbaar voor iedereen met een Microsoft 365-licentie, ook zonder Viva Communications & Communities-licentie. Heb je die licentie niet, dan zie je in de commandbalk Promote in plaats van Amplify. De rest van de stappen is identiek.

Voor veel organisaties haalt dat het gebruikelijke bezwaar weg. “Leuk, maar dat kost vast weer een extra licentie” gaat hier niet op.

Hoe weet je of het werkt?

Je kunt de statistieken van beide kanten naast elkaar leggen.

De pagina-analytics in SharePoint tonen prestaties uit SharePoint én Engage. De analytics in Engage geven een kanaalbeeld: bereik, reacties en comments. Handig detail: SharePoint-nieuws wordt in de Engage-conversatierollups herkend als een apart posttype, dus je kunt het onderscheiden van gewone community-posts.

Wat je precies ziet, verschilt per licentie.

Waar ik op zou letten

Drie dingen, en het eerste is geen techniek maar een afspraak.

Bepaal vooraf welke nieuwssoorten je cross-post. Niet elk bericht hoeft een gesprek te worden. Een verplichte beleidsupdate met een open discussie eronder is zelden een succes — dan ben je vooral aan het modereren in plaats van aan het communiceren. Maak per nieuwstype een keuze: alleen SharePoint, of SharePoint plus community.

Spreek af wie modereert. Dit is de vraag waar nog weinig organisaties een antwoord op hebben. De conversatie leeft technisch in Engage, dus Engage-moderatie en -retentie zijn leidend. Maar de lezer die onder de SharePoint-pagina reageert, denkt dat hij in SharePoint zit. Is de redacteur verantwoordelijk voor die reacties, of de communitymanager? Zet dat op papier vóór het eerste bericht de deur uit gaat, niet erna.

Controleer je bestaande Engage-integraties. Twee klassiekers: de Viva Engage-webparts werken niet op sites met een vanity domain. En de klassieke Highlights-webpart wordt sinds 1 juni 2025 niet meer ondersteund — staat die nog ergens op je intranet, migreer dan eerst naar de Conversations-webpart.

Wanneer kun je het verwachten?

De wereldwijde uitrol start eind september 2026 en is naar verwachting eind oktober afgerond. In je Message Center vind je het terug onder MC1466762.

Als beheerder is het slim om je redacteuren erop voor te bereiden. Niet omdat er iets kapot gaat, maar omdat er een knop bijkomt waarvan ze het bestaan moeten kennen — en omdat je die governance-afspraken liever vóór de uitrol maakt.

Tot slot

Dit is een van die updates die klein oogt en in de praktijk veel scheelt. Niet omdat er een spectaculaire functie bijkomt, maar omdat een vervelend stukje handwerk verdwijnt: twee keer plaatsen, twee gesprekken bewaken, en achteraf uitzoeken waar de beste reactie ook alweer stond.

Werken jullie al met communities op het intranet, dan wordt dit vanzelf merkbaar. Doen jullie dat nog niet, dan is dit misschien het moment om die keuze opnieuw tegen het licht te houden.

Loop je ergens tegenaan bij het inrichten hiervan? Laat het weten — ik denk graag mee.

Bron: Introducing SharePoint News and Viva Engage cross-posting, Microsoft SharePoint Blog, 3 september 2026. Message Center: MC1466762.

Untitled

Marcel

Het einde van klassiek SharePoint: wat je nu al moet uitzoeken

Microsoft heeft een datum geprikt voor iets waar veel functioneel beheerders al jaren omheen lopen. De klassieke SharePoint-ervaringen verdwijnen. Niet volgende maand, en ook niet in één klap, maar de richting is nu officieel en er zitten harde datums aan.

De aankondiging staat in Message Center-bericht MC1464926 en in een uitgebreid artikel van Microsoft. Het gaat om drie dingen die bij elkaar horen: klassieke publishing-sites, klassieke door gebruikers gemaakte pagina’s, en custom scripting. Precies de hoek van SharePoint waar in de loop der jaren het meeste maatwerk in is geslopen.

Wat er verandert en wanneer

De uitrol gebeurt in twee fases.

Vanaf 1 maart 2027 kun je in geen enkele tenant meer nieuwe klassieke publishing-sites aanmaken, niet als sitecollectie en niet als subsite. De publishing-feature valt niet meer te activeren en de tenantinstelling die dat regelt wordt vastgezet. Voor tenants die ná die datum nieuw worden aangemaakt gaat er meteen meer op slot: geen nieuwe klassieke pagina’s, en custom scripting staat standaard uit.

Vanaf 1 oktober 2028 gelden die pagina- en scriptbeperkingen voor alle bestaande tenants. Klassieke door gebruikers gemaakte pagina’s worden dan read-only. Ze blijven leesbaar, maar bewerken of nieuwe aanmaken kan niet meer.

Belangrijk om te weten: er wordt niets weggegooid. Bestaande pagina’s blijven gewoon zichtbaar. Ze bevriezen alleen. Wie een pagina ná die datum nog wil kunnen aanpassen, moet hem vóór die tijd hebben omgezet naar een moderne pagina.

Welke pagina’s vallen hieronder

De read-only-wijziging raakt specifiek deze typen: wiki-pagina’s, Web Part-pagina’s, blogpagina’s, publishing-pagina’s, en custom ASPX-pagina’s die met SharePoint Designer of een externe oplossing zijn gemaakt.

Wat er buiten valt: lijst- en bibliotheekweergaven en formulierpagina’s van lijsten. Die blijven voorlopig zoals ze zijn. Met één addertje: zit er custom script in zo’n weergave, dan val je alsnog onder de scriptwijziging.

En dan die oudere sites en add-ons

Dit is het stuk waar ik functioneel beheerders op zou willen wijzen, want het is de blinde vlek.

Een intranet dat een jaar of vijf, zes meegaat, heeft vaak een laag onder de motorkap die niemand meer echt in beeld heeft. Een custom ASPX-pagina die ooit door een leverancier is neergezet. Een stukje script dat een tabel opmaakt of een teller bijhoudt. Een pagina uit een oude teamsite die met SharePoint Designer is gebouwd. Aan de voorkant ziet zo’n intranet er misschien modern uit, terwijl er achter de schermen nog klassiek werk draait.

Precies dat maatwerk is waar deze wijziging pijn kan doen. Als custom scripting straks standaard uit staat, stopt dat soort oplossingen met werken. En de leverancier die het ooit bouwde, is er soms niet meer, of het contract is allang afgelopen.

Er speelt bovendien iets aangrenzends dat losstaat van deze aankondiging maar in dezelfde hoek zit. Het SharePoint Add-In-model en de bijbehorende Azure ACS-authenticatie zijn per 2 april 2026 gestopt. Dat is dus al gebeurd. Draait er ergens nog een add-in van vroeger, dan is de kans groot dat die nu al niet meer werkt. Twee losse trajecten, dezelfde onderliggende beweging: het klassieke maatwerk gaat eruit.

Wat je nu kunt doen

Je hebt tijd, maar de eerste stap is geen migratie. Het is inventarisatie.

Begin met in kaart brengen wat je eigenlijk hebt. Microsoft geeft daar concrete handvatten voor. In Purview Audit zit een categorie SharePoint Classic Activities, met gebeurtenissen als ClassicPageCreated, ClassicPageEdited en ClassicPageViewed. Zo zie je niet alleen welke klassieke pagina’s er staan, maar ook of ze nog gebruikt worden. Daarnaast is er de Microsoft 365 Assessment Tool, die klassieke pagina’s, Web Parts en maatwerkpatronen opspoort en inschat hoe haalbaar modernisering is.

Vind je niets? Dan hoef je ook niets te doen. Dat is een geldige uitkomst en fijn om zwart op wit te hebben.

Vind je wel wat, begin dan bij de pagina’s die er echt toe doen. De veelbezochte, de vaak bewerkte, de bedrijfskritische. Groepeer ze naar complexiteit en verplaats ze in golven, zodat je per golf kunt controleren of links, rechten, Web Parts en opmaak nog kloppen voordat je de volgende groep aanpakt.

Waarom dit een communicatievraag is, niet alleen een IT-vraag

Het is verleidelijk om dit door te schuiven naar beheer. Toch zit de kern bij de eigenaar van je SharePoint sites.

Iemand moet namelijk bepalen welke oude pagina’s er nog toe doen. Welke campagne uit 2022 mag bevriezen, en welke kennisbank moet blijven leven. Dat is geen technische afweging, dat is een inhoudelijke. De functioneel beheerder kan de pagina’s opsporen en omzetten. De keuze wat blijft, ligt bij communicatie.

De datums liggen ver genoeg weg om rustig te plannen, en dichtbij genoeg om er dit jaar al mee te beginnen. Wie in 2028 pas kijkt, ontdekt te laat welke pagina niemand meer kan bewerken.

Agents, Copilot en skills in SharePoint: wat is wat, en wie gaat waarover?

Marcel

Stand van zaken: augustus 2026. 

Knowledge Agent. AI in SharePoint. Copilot in SharePoint. Drie namen voor dezelfde functie, binnen twaalf maanden. Als je als informatiemanager of functioneel beheerder het overzicht kwijt bent, ligt dat niet aan jou.

Dit artikel zet uit elkaar wat er in SharePoint naast elkaar staat, wie er per onderdeel aan de knoppen zit, en waar je rechtenmodel gaten laat vallen die je er niet zelf in hebt gemaakt.

Het zijn er twee, plus een uitbreiding

Veel verwarring komt voort uit een verkeerde indeling. Mensen zetten agents, Copilot en skills als drie gelijkwaardige dingen naast elkaar. Dat klopt niet. Het zijn twee functies, en skills zijn een uitbreiding op de tweede. Microsoft documenteert het ook zo: “Extend Copilot in SharePoint with skills”.

Agents in SharePoint, Copilot in SharePoint en skills vergeleken. Stand van zaken: augustus 2026.
Agents in SharePointAlgemeen beschikbaar Copilot in SharePointPreview SkillsUitbreiding op Copilot, preview
Wat het doet Beantwoordt vragen over de inhoud van een site, bibliotheek of selectie bestanden. Ook aan te roepen in een Teams-chat of standaardkanaal. Voert uit. Kolommen vullen, bestanden ordenen, secties en pagina’s maken, lijsten en bibliotheken opzetten, hele sites bouwen. Legt een werkwijze vast, zodat iedereen die hem aanroept dezelfde uitvoering krijgt.
Waar het staat Kant-en-klare agent per site zonder bestand. Zelfgemaakt als .agent-bestand in Site Assets of in de bibliotheek waar je begon. In het scherm zelf. Geen bestand, geen webpart. Markdown-bestanden onder /Agent Assets/Skills/<naam>/SKILL.md.
Wie gaat erover Bewerkrechten op de site om te maken en te bewerken. Beheerder kan de kant-en-klare agent weghalen via Restricted Content Discovery. Beheerder via Set-SPOTenant -KnowledgeAgentScope. Site-eigenaar via Site AI settings. Bewerkrechten om te maken, leesrechten om te gebruiken. Geen aparte beheerinstelling.
Waar je op let Copilot-licentie of pay-as-you-go vereist. De kant-en-klare agent kun je niet bewerken en niet delen. Sinds midden juni 2026 opt-out: aan tenzij je iets doet. Draait op een door Microsoft beheerd model van OpenAI, dat kan wijzigen. Geen koppeling met externe systemen en geen extra rechten. De rechten op Agent Assets zijn wel los te knippen van de site.

Agents in SharePoint

Agents beantwoorden vragen over inhoud. Ze zijn algemeen beschikbaar, geen preview, maar vereisen wel een Microsoft Copilot-licentie of pay-as-you-go voor SharePoint-agents.

Er zijn twee soorten.

De kant-en-klare agent krijgt elke site automatisch, zonder dat een site-eigenaar iets doet. Er hoort geen bestand bij. Je kunt hem niet bewerken en niet delen. Als beheerder haal je hem weg via de Restricted Content Discovery-policy. Op sites die in de Copilot-preview zitten, heet die agent “Copilot” in plaats van de sitenaam, wat de verwarring niet kleiner maakt.

De zelfgemaakte agent maak je met bewerkrechten op de site. Die krijgt wel een bestand: een .agent-bestand. Start je vanaf de homepage, dan komt het in Site Assets, in de map Copilots. Start je vanuit een bibliotheek of vanuit een selectie bestanden, dan wordt het opgeslagen in die bibliotheek. Dat is relevant voor je informatiebeheer, want zo’n bestand valt onder je gewone SharePoint-governance: rechten, bewaartermijnen, gevoeligheidslabels, auditing. Wil je met DLP op agents sturen, dan kun je condities op de .agent-extensie zetten in plaats van op gevoeligheidslabels.

Antwoorden zijn rechten-bewust. Wie een agent gebruikt, krijgt alleen antwoord op basis van zijn eigen toegang tot de bronnen. Een agent delen verandert daar niets aan. Dat is geruststellend, maar het is geen vrijbrief: als de onderliggende rechten te ruim staan, maakt een agent dat sneller zichtbaar dan een zoekopdracht ooit deed.

De agent verlaat de site

Dit is het punt dat in governance-gesprekken vaak wordt overgeslagen. Een zelfgemaakte agent blijft niet op de site staan.

Je kiest bij de agent Copy link for Teams, plakt die link in een groepschat, vergaderchat of standaardkanaal, en bevestigt “Add to this chat”. Daarna is de agent met een @-vermelding aan te roepen. Sinds midden juli 2026 zijn SharePoint-agents ook vindbaar in de Teams-store onder Agents en via “Agents en bots toevoegen” in de chat (MC1193415, roadmap-ID 515465).

Wat je daarbij moet weten:

  • Alleen zelfgemaakte agents zijn te delen. De kant-en-klare agent niet.
  • Privékanalen en gedeelde kanalen worden nog niet ondersteund. Een 1-op-1 chat met een SharePoint-agent ook niet.
  • Voeg je een agent toe aan een kanaal, dan wordt hij toegevoegd aan het onderliggende team.
  • Zitten er gasten of externe gebruikers in de chat of het kanaal, dan weigert de agent te antwoorden.

Dat laatste punt is voor gemeenten en zorgorganisaties met ketenpartners in kanalen belangrijker dan het lijkt. Het betekent dat de agent daar simpelweg niet werkt, niet dat hij minder deelt.

Copilot in SharePoint

Dit is de functie die eerst Knowledge Agent heette, daarna AI in SharePoint, en nu Copilot in SharePoint. De artikelen op Microsoft Learn zijn hernoemd naar copilot-in-sharepoint-*. De PowerShell-parameters houden bewust de oude naamgeving aan, daarover verderop meer.

Waar een agent antwoordt, voert Copilot in SharePoint uit:

  • kolommen automatisch vullen op basis van bestandsinhoud
  • bestanden en mappen ordenen
  • secties op een pagina genereren, met bestanden als bron
  • hele pagina’s schrijven en bewerken via het AI-authoringpaneel, inclusief indeling en webparts
  • lijsten en bibliotheken opzetten
  • complete sites bouwen op basis van een plan dat jij eerst goedkeurt
  • Word-, Excel- en PowerPoint-bestanden maken vanuit inhoud die al op je site staat

Sinds de augustusrelease kan Copilot ook een dashboard uit een lijst genereren als interactief HTML-rapport dat verbonden blijft met die lijst en zich ververst bij openen. Voor wie de discussie over HTML-pagina’s in SharePoint volgt: dat beantwoordt de vraag waar zo’n pagina zijn cijfers vandaan haalt, in elk geval voor deze route.

Preview, maar wel aan

Belangrijk voor je change-proces: Copilot in SharePoint is sinds midden juni 2026 geen opt-in preview meer, maar een opt-out preview. Het komt automatisch beschikbaar voor iedereen met een Copilot-licentie. Had je eerder de tenant of specifieke sites uitgezet, dan wordt dat gerespecteerd.

Niet beschikbaar in GCC, GCC High, DoD, air-gapped omgevingen en 21Vianet. Tijdens de preview gelden daarnaast dagelijkse en wekelijkse gebruikslimieten per gebruiker.

Wat je als beheerder kunt sturen

Tijdens de preview stuur je met PowerShell. Gebruik SharePoint Online Management Shell versie 16.0.26615.12013 of hoger. In multigeo-tenants voer je het script per geo uit.

powershell
Connect-SPOService https://jouwtenant-admin.sharepoint.com

# Beschikbaar op alle sites
Set-SPOTenant -KnowledgeAgentScope AllSites

# Of: alleen op een selectie sites
Set-SPOTenant -KnowledgeAgentScope IncludeSelectedSites
Set-SPOTenant -KnowledgeAgentSelectedSitesList @("https://jouwtenant.sharepoint.com/sites/site1")

# Of: overal behalve op een selectie
Set-SPOTenant -KnowledgeAgentScope ExcludeSelectedSites

# Of: helemaal uit
Set-SPOTenant -KnowledgeAgentScope NoSites

Get-SPOTenant | Select-Object KnowledgeAgentScope, KnowledgeAgentSelectedSitesList

De lijst met site-URL’s mag maximaal honderd items bevatten. Met KnowledgeAgentSelectedSitesListOperation kies je tussen Overwrite (standaard), Append en Remove. En ja, de parameters heten nog steeds KnowledgeAgent, terwijl de functie inmiddels anders heet. Microsoft heeft dat expliciet zo gelaten voor compatibiliteit tijdens de preview. Bij general availability verandert het inschakelproces.

Krijg je de foutmelding dat KnowledgeAgentScope niet gevonden wordt, dan draaien er waarschijnlijk meerdere versies van de management shell op je machine.

Twee bestaande instellingen werken gewoon door. Restricted Content Discovery wordt gerespecteerd: staat dat aan op een site, dan verschijnen Copilot in SharePoint en de AI-acties daar niet, ongeacht je overige instellingen. En in het paneel Site AI settings kiest de site-eigenaar zelf welke agent opent achter het AI-icoon, en kan hij de Copilot-knop verbergen voor bezoekers.

Die laatste is het vermelden waard richting je communicatiecollega’s. Op een intranetsite kun je bezoekers de agent geven die jij hebt ingericht, met jouw bronnen en jouw startvragen, in plaats van de standaardagent.

Het model

Copilot in SharePoint draait op een door Microsoft beheerd reasoning-model van OpenAI. Microsoft geeft aan dat dit model in de tijd kan wijzigen en dat je zelf niets configureert.

Dit is een correctie waard, want in het Message Center-bericht van maart 2026 stond een Anthropic-model genoemd, inclusief de opmerking dat beheerders in sommige regio’s Anthropic als subverwerker moesten toestaan. Dat verhaal circuleert nog steeds. Voor een verwerkingsregister of een DPIA: baseer je op de actuele documentatie, niet op een bericht van een half jaar geleden, en leg de datum van je vaststelling vast.

Skills

Skills zijn geen apart product. Het is een uitbreiding op Copilot in SharePoint, en een skill kan alleen wat Copilot daar toch al kan, maar dan in jouw volgorde.

Je maakt een skill in gewone taal in het chatvenster. Je beschrijft de werkwijze, je krijgt een concept terug dat je kunt bijstellen, en daarna sla je hem op. Het resultaat is een markdown-bestand onder /Agent Assets/Skills/<naam>/SKILL.md. Copilot laadt een passende skill zelf als je vraag erop lijkt, of je roept hem bij naam aan. In het chatvenster zie je een indicator dat er een skill geladen is. Met /skills zie je ook de ingebouwde skills die Microsoft zelf meelevert.

De waarde zit in eenheid van uitvoering. Wie de skill aanroept, krijgt dezelfde stappen, dezelfde volgorde en dezelfde uitkomst. Dat is precies waarom het een governance-onderwerp is.

Wat je hier wel en niet kunt

Wat je niet kunt: skills als functie uitzetten. Er zijn geen aparte beheerinstellingen voor. Ze bestaan alleen binnen Copilot in SharePoint, dus je enige tenantbrede rem is die functie zelf uitzetten of per site uitsluiten. De bibliotheek Agent Assets wordt door het product beheerd en kun je niet verwijderen.

Wat je wel kunt: standaard SharePoint-bestandsgovernance toepassen op de skill-bestanden. Rechten, bewaarbeleid, gevoeligheidslabels, auditing. En je kunt de overerving van rechten op de bibliotheek Agent Assets verbreken en er een strakker model op zetten.

Dat laatste is de kern van de zaak. Standaard geldt: bewerkrechten op de site zijn genoeg om een skill te maken, leesrechten zijn genoeg om hem te gebruiken. Wie vandaag een nieuwsbericht mag publiceren, legt morgen vast hoe de AI op die site werkt. Dat is geen fout in het product, dat is een keuze die jouw rechtenmodel voor je maakt zolang je er zelf niets van vindt.

Twee geruststellingen: een skill kan geen verbinding maken met externe systemen of eigen code uitvoeren, en hij kan alleen handelingen doen die de gebruiker zelf al mag doen. Er wordt dus geen toegang opgerekt.

Wat ik zou vastleggen

Vijf punten die je zonder project of budget kunt regelen:

  1. Wie mag skills schrijven. Bepaal of bewerkrechten op de site genoeg zijn, of dat je Agent Assets losknipt en aan een kleine groep geeft. Doe dat in elk geval voor je hoofdintranet en je kanaalsites.
  2. Wie mag agents publiceren. Zeker agents die in Teams-kanalen terechtkomen. Zo’n agent reist verder dan de site waar hij gemaakt is.
  3. Inventariseer wat er al staat. .agent-bestanden zijn vindbaar in Site Assets en in bibliotheken, skills in Agent Assets. Weet je wat er is, dan weet je waar je over praat.
  4. Neem agents en skills op in je levenscyclus. Ze hebben een eigenaar en een vervaldatum nodig, net als een pagina of een nieuwsbericht. Anders heb je over een jaar een tweede laag content waar niemand van is.
  5. Leg de datum van je vaststelling vast. Naamgeving, model en preview-status zijn dit jaar meermaals gewijzigd. Zonder datum weet je over zes maanden niet meer waarop je besluit gebaseerd was.

Bronnen

  • Get started with Copilot in SharePoint (preview): learn.microsoft.com/sharepoint/copilot-in-sharepoint-get-started
  • Extend Copilot in SharePoint with skills: learn.microsoft.com/sharepoint/copilot-in-sharepoint-skills
  • Create sites with AI: learn.microsoft.com/sharepoint/create-sites-with-ai
  • Get started with agents in SharePoint: support.microsoft.com/sharepoint/copilot-in-sharepoint/get-started-with-agents-in-sharepoint
  • Manage access to agents in SharePoint: learn.microsoft.com/sharepoint/manage-access-agents-in-sharepoint
  • MC1193415 en roadmap-ID 515465 voor SharePoint-agents in de Teams-store

SharePoint Skills: wie is eigenaar van jullie werkafspraak?

Marcel

Er is een terugkerend patroon bij AI op het intranet. De functie werkt. Maar het resultaat verschilt per persoon.

De ene redacteur vraagt: “Maak een samenvatting van maximaal honderd woorden.”

De andere schrijft: “Maak dit korter.”

Beide krijgen antwoord. Maar waarschijnlijk niet hetzelfde antwoord.

Dat is precies het soort probleem waarvoor Microsoft met SharePoint Skills komt, officieel Skills in Copilot in SharePoint geheten.

Een Skill legt een herhaalbare werkwijze met meerdere stappen vast als een herbruikbaar onderdeel van een SharePoint-site. Daardoor hoeft het resultaat minder afhankelijk te zijn van de toevallige formulering van een prompt. (Microsoft Learn)

Maar voor mij zit de interessantste ontwikkeling ergens anders. Op het moment dat je een werkafspraak in een Skill zet, ontstaat er een nieuw type content op je intranet. Niet content die medewerkers lezen.

Content die AI uitvoert. En daarmee krijgen informatiebeheer en AI ineens een heel directe verbinding.

Want wat bedoelen we eigenlijk precies met “schrijf volgens onze richtlijnen”? Wie bepaalt die richtlijnen? Wie is eigenaar? En wie zorgt ervoor dat een Skill nog klopt als de richtlijn over zes maanden verandert?

Dat zijn interessantere vragen dan alleen: “Hoe maak ik een Skill?”

Eerst de naamgeving

De functie heet inmiddels Copilot in SharePoint.

In eerdere preview-documentatie werd deze functie aangeduid als AI in SharePoint. Daarvoor kwam je ook de naam Knowledge Agent tegen.

Die geschiedenis zie je nog terug in de techniek. In PowerShell worden tijdens de preview nog steeds parameters met KnowledgeAgent in de naam gebruikt, zoals KnowledgeAgentScope. Microsoft geeft aan dat deze namen tijdens de preview ongewijzigd blijven voor compatibiliteit. (Microsoft Learn)

Dat is dus geen fout in je PowerShell-script. Het is simpelweg een erfenis uit de preview.

En nog iets belangrijks: Copilot in SharePoint is op dit moment nog preview. Microsoft documenteert de functie in augustus 2026 nog steeds als preview. Tegelijkertijd is de uitrol inmiddels wel veranderd: sinds medio juni 2026 wordt Copilot in SharePoint als opt-out preview automatisch beschikbaar voor gebruikers met een Microsoft 365 Copilot-licentie. (Microsoft Learn)

Wat zijn SharePoint Skills?

Microsoft omschrijft een Skill als een manier om een herhaalbare workflow met meerdere stappen om te zetten in een herbruikbaar onderdeel dat anderen op dezelfde site kunnen uitvoeren. (Microsoft Learn)

Een Skill kan daarbij organisatiespecifieke regels bevatten.

Denk bijvoorbeeld aan:

  • documentstandaarden
  • een reviewchecklist
  • een vaste beoordelingsmethode
  • een bepaalde manier van classificeren
  • een redactionele werkwijze

Het interessante is dat je zo’n Skill gewoon in natuurlijke taal kunt laten maken.

Je beschrijft wat je wilt bereiken. Copilot maakt vervolgens een concept van de Skill. Je kunt die bekijken en aanpassen voordat je hem opslaat. Daarna kan Copilot de Skill automatisch gebruiken wanneer een vraag daarbij past. Je kunt hem ook expliciet op naam aanroepen. (Microsoft Learn)

Microsoft gebruikt zelf een voorbeeld waarbij contracten worden gecontroleerd op de aanwezigheid van een advocaat-ID in een bepaald formaat. Contracten die niet voldoen, worden toegevoegd aan een SharePoint-lijst. Bestaat die lijst nog niet, dan kan de Skill die ook aanmaken. (Microsoft Learn)

Dat voorbeeld is duidelijk. Maar het gaat over juristen.

Daarom heb ik het vertaald naar een vraag die elke intranetbeheerder kent.

Een praktijkvoorbeeld: leeft deze site nog?

Vroeg of laat krijg je die vraag.

Is de content hier nog actueel? Kunnen we deze site archiveren? Wie heeft hier voor het laatst iets aan gedaan?

Het antwoord kost meestal een export, een filter en een kwartier handwerk. Elke keer opnieuw, want niemand heeft vastgelegd hoe je die vraag beantwoordt.

Ik heb het als Skill vastgelegd. Dit is letterlijk de prompt die ik in het Copilot-paneel heb gezet:

Maak een skill die de Sitepagina’s-bibliotheek van deze site doorloopt en per pagina de titel, laatste wijzigingsdatum en laatste bewerker vastlegt. Markeer pagina’s die langer dan zes maanden niet zijn gewijzigd als “te beoordelen”. Schrijf het resultaat naar de lijst Pagina-actualiteit en maak die lijst aan als hij nog niet bestaat.

Nederlands. Geen technische termen. Geen code.

Wat er daarna gebeurde, in volgorde:

Copilot maakte een concept. Met een voorgestelde naam, in dit geval “pagina-actualiteit-controleren”. Die kun je overschrijven, wat ik heb gedaan.

Copilot vroeg hoe ik hem wilde opslaan. Als site-skill, beschikbaar voor iedereen met toegang tot deze site. Of als persoonlijke skill, alleen voor mij. Op die keuze kom ik verderop terug, want daar zit wat mij betreft het belangrijkste governancepunt van dit hele artikel.


De bibliotheek werd aangemaakt. Letterlijke melding: “De library AgentAssets is aangemaakt.” Die stond er dus nog niet. In de documentatie staat dat de bibliotheek door het product wordt aangemaakt en beheerd, en niet kan worden verwijderd. In de praktijk verschijnt hij pas op het moment dat je je eerste Skill opslaat. (Microsoft Learn)

Bij het uitvoeren kwam er een bevestigingsstap. Voordat er items in de lijst werden weggeschreven, moest ik eerst op Maken klikken. Copilot doet dit dus niet stilzwijgend.

En toen het resultaat. Elf sitepagina’s gecontroleerd, de lijst Pagina-actualiteit aangemaakt en gevuld met elf items, waarvan vijf gemarkeerd als “te beoordelen”.

Voor wie zich afvraagt of dit met Nederlandse content werkt: ja. Nederlandse prompt, Nederlandse Skill-beschrijving, Nederlandse paginatitels, kloppend resultaat.

Eén detail viel me op toen ik het onderliggende bestand bekeek. De beschrijving van de Skill is Nederlands, maar de triggerregels eronder staan in het Engels (“Use when the user says”). Het bestand is dus deels Engelse boilerplate met jouw Nederlandse instructies erin.

Twee verwachtingen die je meteen moet bijstellen

Een Skill draait niet vanzelf. Er is geen tijdgebonden trigger. Iemand roept de Skill aan in de chat. Zelfs bij de regels in documentbibliotheken, waar wél triggers bestaan, wordt de trigger “date approaches” nog niet ondersteund. (Microsoft Learn)

Wat je vastlegt is dus niet de planning, maar de definitie. “Elke maand een overzicht” wordt in de praktijk: elke maand drukt iemand op de knop en krijgt hij hetzelfde overzicht.

Een Skill werkt op één site. De Skill staat in de Agent Assets-bibliotheek van die site en anderen kunnen hem op diezelfde site uitvoeren. De vraag “welke van onze tweehonderd sites staan stil” is een andere vraag, met een ander antwoord. Daarover verderop meer.

En één inhoudelijke nuance

In mijn testresultaat stond de pagina Home gemarkeerd als te beoordelen, laatst bewerkt door Systeemaccount in juni 2025.

Technisch klopt dat. Inhoudelijk is het de vraag.

Op een homepage staan doorgaans webparts die dagelijks nieuwe content tonen. De pagina zelf is dan al een jaar niet aangeraakt, terwijl wat de bezoeker ziet steeds verandert.

Actualiteit van een pagina is niet hetzelfde als actualiteit van wat erop staat.

Dat is geen tekortkoming van de Skill. Het is een tekortkoming van mijn instructie. En dat is precies waarom je zo’n Skill als levend document moet behandelen in plaats van als eenmalige inrichting.

Kun je een Skill dan niet automatisch laten draaien vanuit Power Automate of een Power App?

Dat is de eerste vraag die elke functioneel beheerder stelt. Het antwoord is nee, en dat is een expliciete grens in de documentatie, geen omissie.

Microsoft schrijft dat een Skill geen verbinding kan maken met externe systemen en geen eigen code kan uitvoeren. En daarnaast: standaard zijn Skills alleen beschikbaar binnen de eerste-partij Copilot-ervaring van SharePoint. (Microsoft Learn)

Er is dus geen connector-actie, geen API en geen trigger waarmee je een SharePoint-skill van buitenaf aanroept. Een flow kan hem niet starten. Een Power App ook niet.

Dat woordje “standaard” is overigens opvallend gekozen. Het suggereert dat er ooit iets anders komt. Maar daar kun je vandaag niets mee.

Wat wél kan, is de logica ergens anders opnieuw bouwen. In Copilot Studio maak je een agent met een recurrence-trigger, die dus wel autonoom draait. Houd er rekening mee dat elke triggerpayload meetelt als bericht voor je Copilot Studio-verbruik. Een trigger die elke tien minuten afgaat, stuurt elke tien minuten een bericht. (Microsoft Learn)

Maar dan gebruik je je SharePoint-skill niet.

Je hebt dan een tweede agent, met een tweede set instructies, in een ander product, met een andere licentie en een ander rechtenmodel.

En daarmee ben je terug bij het punt van dit artikel. Op het moment dat je die werkafspraak autonoom wil laten draaien, verlaat je de governance van de site. Het bestand in de Agent Assets-bibliotheek is niet langer de bron. Er ligt een kopie in Copilot Studio, en die twee lopen uit elkaar zodra iemand er één aanpast.

Twee bestanden, twee waarheden, en niemand die ze naast elkaar legt.

Kleine waarschuwing als je hier zelf op gaat zoeken: in Power Automate bestaat een connector die “Skills Plugins” heet. Die heeft niets met SharePoint Skills te maken. Dat is een naamsbotsing uit een ander tijdperk.

En hier wordt het interessant voor informatiemanagement

Kijk nog eens naar die instructie.

Zes maanden. Dat is geen technische instelling. Dat is een organisatieafspraak over wat actueel betekent.

En in de meeste organisaties staat die nergens. Er staat wel iets in een governancedocument over dat content actueel moet zijn. Maar dat is geen afspraak. Dat is een wens.

Een Skill dwingt je tot een getal. En zodra je dat getal opschrijft, blijkt het per type site te verschillen. Een nieuwsarchief mag stilstaan. Een pagina met verlofregelingen niet. Dat gesprek voer je normaal gesproken nooit. Nu moet het, omdat je het anders niet in de Skill krijgt.

Dat is wat mij betreft de echte winst. Niet de tijdwinst per taak. Maar het feit dat impliciete werkafspraken ineens expliciete kennis worden.

Waar worden Skills opgeslagen?

Een Skill wordt opgeslagen als Markdown-bestand in de Agent Assets-bibliotheek van de SharePoint-site.

Het pad is:

/Agent Assets/Skills/<skill-naam>/SKILL.md

Je kunt Skills via de chat maken en beheren, maar je kunt het onderliggende Markdown-bestand ook rechtstreeks bekijken. Microsoft waarschuwt daarbij om de structuur intact te laten als je het bestand rechtstreeks bewerkt. (Microsoft Learn)

Er zijn daarnaast ingebouwde Skills die door Microsoft worden geleverd en onderhouden. Die staan niet in de Agent Assets-bibliotheek. In de chat kun je /skills gebruiken om de beschikbare Skills te bekijken. (Microsoft Learn)

Wat kan een Skill?

Een Skill gebruikt de bestaande mogelijkheden van Copilot in SharePoint en kan die mogelijkheden in meerdere stappen achter elkaar gebruiken.

Afhankelijk van wat Copilot in SharePoint op de betreffende site ondersteunt, kan een Skill bijvoorbeeld:

  • content begrijpen en samenvatten
  • bestanden en mappen organiseren
  • met SharePoint-content zoals lijsten werken

Maar er zijn duidelijke grenzen.

Een Skill kan:

  • geen verbinding maken met externe systemen
  • geen eigen code uitvoeren
  • geen rechten uitbreiden
  • geen mogelijkheden toevoegen die Copilot in SharePoint zelf niet heeft

Een Skill kan alleen acties uitvoeren waarvoor de gebruiker zelf al toestemming heeft. (Microsoft Learn)

Dat laatste is belangrijk.

Een Skill is geen nieuw rechtenmodel.

Het is een opgeslagen instructie die gebruikmaakt van de mogelijkheden en rechten die er al zijn.

Dat is precies de zin die ik zou gebruiken wanneer je dit aan een security officer uitlegt.

Een Skill is een kopie, geen verwijzing

Dit punt staat nergens in de documentatie, maar volgt logisch uit de manier waarop Skills werken.

Een Skill bevat zijn eigen instructies. Die staan in het SKILL.md-bestand.

Stel dat je organisatie een nieuwe schrijfrichtlijn invoert, of besluit dat drie maanden voortaan de norm is in plaats van zes.

Dan kun je de PDF of de intranetpagina met die richtlijn aanpassen. Maar daarmee is je Skill niet bijgewerkt. Die blijft doen wat er in staat.

Je hebt geen verwijzing gemaakt. Je hebt een kopie gemaakt.

Daarom hoort bij een volwassen aanpak een lifecycle: weet je bij een wijziging in de richtlijn welke Skills je moet nalopen?

Een Skill zonder eigenaar is uiteindelijk gewoon een werkafspraak waar niemand meer naar omkijkt.

Governance: wie mag de organisatieafspraak aanpassen?

Want zodra een Skill een organisatieafspraak bevat, wordt beheer een rechtenvraag.

Microsoft heeft voor Skills zelf geen aparte beheerinstelling waarmee je ze centraal aan- of uitzet. Skills zijn onderdeel van Copilot in SharePoint en volgen de beschikbaarheid daarvan.

De bibliotheek zelf kun je niet verwijderen, maar je kunt er wel de normale SharePoint-governance op toepassen, zoals:

  • rechten
  • bewaarbeleid
  • gevoeligheidslabels
  • auditing

(Microsoft Learn)

Standaard is de situatie interessant:

Iedereen met Edit-rechten op de site kan een Skill maken. Iedereen met View-rechten kan hem gebruiken. (Microsoft Learn)

Daar zit een belangrijke ontwerpkeuze.

Stel dat je een communicatiesite hebt waarop tien communicatieprofessionals kunnen bewerken.

Dan kunnen zij volgens de standaardrechten ook Skills maken.

Dat is prima als je Skills ziet als persoonlijke of teamgerichte werkwijzen.

Maar wat gebeurt er als een Skill ineens de officiële redactionele werkwijze van de organisatie bevat?

Dan wil je misschien niet dat iedereen die de site kan bewerken ook die werkwijze kan aanpassen.

Je kunt in dat geval de rechtenovererving van de Agent Assets-bibliotheek verbreken en daar beperktere rechten instellen. (Microsoft Learn)

Dat is dus geen technische detailkwestie. Het is een governancekeuze.

En dan die keuze bij het opslaan

Terug naar het moment waarop Copilot vroeg hoe ik de Skill wilde bewaren: als site-skill, of als persoonlijke skill.

Die tweede optie staat niet in de documentatie die ik heb kunnen vinden. Learn beschrijft alleen het sitemodel, met de Agent Assets-bibliotheek als opslagplek.

En dat roept een vraag op die je als informatiemanager wilt beantwoorden voordat je dit breed uitzet.

Alle governance die ik hierboven beschreef, rechten, bewaarbeleid, labels, auditing, hangt aan die bibliotheek. Maar dat werkt alleen voor wat er in die bibliotheek staat.

Een persoonlijke Skill staat daar niet.

Je kunt geen eigenaar aanwijzen voor iets wat je niet ziet. Je kunt geen reviewcyclus inrichten op iets wat niet in een bibliotheek staat. En je kunt niet controleren of iemand met een eigen definitie van “actueel” werkt.

Dit is voor mij het punt om in de gaten te houden bij deze functie. Niet omdat persoonlijke Skills verkeerd zijn. Voor een individuele werkwijze zijn ze prima. Maar de grens tussen “mijn manier van werken” en “onze afspraak” is in de praktijk dun, en het verschil zit hier in één klik bij het opslaan.

Test dit zelf in je eigen tenant en kijk waar een persoonlijke Skill terechtkomt en of een sitebeheerder hem kan zien. Ik zou daar geen aannames over doen.

Mijn advies: behandel een Skill als content

Geef een belangrijke Skill een eigenaar.

Leg vast wat de bron van de instructie is.

Plan een reviewmoment.

En bepaal wat er gebeurt als de onderliggende richtlijn verandert.

Een Skill is redactionele content in technische verpakking. Behandel hem ook zo.

Verwar dit niet met Copilot in het beheercentrum

Zodra je het over site-activiteit hebt, komt de vraag: kan ik dit ook voor mijn hele tenant?

Ja, maar niet met Skills.

In het SharePoint-beheercentrum zit een aparte Copilot met eigen skills. Die werkt met natuurlijke taal, geeft contextuele begeleiding en kan sites bevragen op meerdere voorwaarden tegelijk. Microsoft geeft als voorbeeld een vraag als “vind sites die vorige maand zijn gemaakt en extern zijn gedeeld”. Ook daarvoor is een Microsoft 365 Copilot-licentie nodig. Belangrijk detail: die Copilot voert zelf geen configuratiewijzigingen uit. (Microsoft Learn)

Twee verschillende functies dus, met twee verschillende doelgroepen:

  • Skills in Copilot in SharePoint staan op een site, worden gemaakt door iemand met bewerkrechten, en gaan over de inhoud van die site.
  • Copilot in het beheercentrum werkt tenantbreed, vereist beheerrechten, en gaat over sites als geheel.

Voor een functioneel beheerder van een intranet zijn beide relevant, maar op verschillende momenten. De ene beantwoordt “is deze site nog actueel”, de andere “welke sites moet ik gaan opruimen”.

Beschikbaarheid en licentie

Voor Copilot in SharePoint is een actieve Microsoft 365 Copilot-licentie nodig.

Microsoft geeft aan dat Copilot in SharePoint tijdens de preview en ook bij General Availability bij die licentie is inbegrepen, zonder extra kosten. (Microsoft Learn)

Tijdens de preview kan een beheerder de beschikbaarheid via PowerShell sturen, met de KnowledgeAgent-parameters uit de naamgeving-paragraaf hierboven.

Met KnowledgeAgentScope kun je onder meer kiezen voor:

  • AllSites
  • IncludeSelectedSites
  • ExcludeSelectedSites
  • NoSites

Bij IncludeSelectedSites en ExcludeSelectedSites kun je maximaal honderd site-URL’s opgeven. In een multigeo-omgeving moet je het script per geo uitvoeren. Microsoft geeft bovendien aan dat de manier waarop de beschikbaarheid wordt beheerd bij General Availability verandert. (Microsoft Learn)

Een belangrijk detail: Restricted Content Discovery wordt gerespecteerd. Staat dat op een site aan, dan verschijnen Copilot in SharePoint en de bijbehorende AI-acties daar niet, ongeacht de andere beschikbaarheidsinstellingen. (Microsoft Learn)

Ook via Site AI settings zijn er enkele mogelijkheden. Een site-eigenaar kan bijvoorbeeld bepalen welke agent opent vanuit het Agent-icoon en kan de Copilot-knop voor bezoekers verbergen. (Microsoft Learn)

Copilot in SharePoint wordt op dit moment niet ondersteund in Microsoft 365 Government (GCC, GCC High en DoD), air-gapped cloudomgevingen en Microsoft 365 die door 21Vianet wordt beheerd. (Microsoft Learn)

Vergeet de gebruikslimieten niet

Tijdens de preview gelden dagelijkse en wekelijkse gebruikslimieten per gebruiker.

Die limieten worden niet gedeeld binnen de organisatie. Bereikt een gebruiker zijn limiet, dan zijn de Copilot-functies tijdelijk niet beschikbaar totdat de limiet automatisch wordt gereset. Microsoft geeft aan dat de limieten tijdens de preview kunnen veranderen. (Microsoft Learn)

Voor een organisatie die hier serieus mee aan de slag wil, is dat iets om mee te nemen in een pilot.

Niet omdat een Skill ineens onbetrouwbaar wordt, maar omdat je niet wilt dat een zorgvuldig ontworpen werkwijze in de praktijk strandt op een gebruikslimiet waar niemand rekening mee heeft gehouden.

Wat er in augustus 2026 bij kwam

De ontwikkeling gaat snel, en twee toevoegingen van augustus 2026 sluiten direct aan op het voorbeeld hierboven.

Copilot in SharePoint kan een dashboard genereren vanuit een lijst als interactief HTML-rapport dat verbonden blijft met die lijst en ververst wanneer je het opent. Dat kan ook vanuit Excel- en CSV-bestanden. Daarnaast zijn er paginaknoppen waarmee je een geschreven Copilot-prompt met één klik start. (Microsoft SharePoint Blog, augustus 2026)

Zet je dat naast elkaar, dan is de keten rond:

  1. De Skill legt vast hoe je pagina-actualiteit beoordeelt en vult de lijst.
  2. Het dashboard hangt aan die lijst en ververst bij openen.
  3. Een knop op de startpagina van de site zet het geheel in gang.

De site-eigenaar hoeft dan niets te weten van prompts. Hij klikt en ziet wat er aan zijn site mankeert.

Voor wie mijn eerdere artikel over HTML-pagina’s in SharePoint heeft gelezen: daarin schreef ik dat dataversheid bij zo’n gegenereerde pagina geen garantie is en dat je per geval moet testen waar de cijfers vandaan komen. Voor dashboards die op een SharePoint-lijst zijn gebouwd is die nuance sinds augustus deels achterhaald. Voor rapporten uit andere bronnen blijft de vraag staan.

Taal: let op het verschil tussen Skills en Rules

Copilot in SharePoint ondersteunt de talen die zowel door SharePoint als door Microsoft 365 Copilot worden ondersteund.

Microsoft adviseert om prompts in een ondersteunde taal te gebruiken. Voor andere talen zijn de resultaten niet getest of gevalideerd en kunnen ze variëren. (Microsoft Learn)

Maar hier moet je goed opletten dat je Skills niet verwart met Rules.

Copilot in SharePoint kan namelijk ook regels in een documentbibliotheek maken.

Daar geldt op dit moment expliciet dat Copilot tekstuele prompts en antwoorden in de ondersteunde Microsoft 365 Copilot-talen aankan, maar dat het verwerken van bestanden voor deze Rules alleen in het Engels wordt ondersteund. Daarnaast gelden onder meer beperkingen op het aantal regels, de triggers en acties. Zo kun je maximaal vijftien regels per lijst of bibliotheek maken. (Microsoft Learn)

Die Engelse beperking staat bij Rules, niet bij Skills.

Voor een Nederlandse organisatie is dat een belangrijk onderscheid. In mijn eigen test met een Skill op Nederlandse sitepagina’s ging het goed.

Maar mijn advies blijft: beloof niet vooraf dat een Nederlandse Skill perfect werkt met jouw Nederlandse documenten. Test het met je eigen content.

Dat is bij AI nog altijd verstandiger dan een demo als bewijs beschouwen.

Welk model gebruikt Copilot?

Copilot in SharePoint draait momenteel op een door Microsoft beheerd redeneermodel van OpenAI.

Microsoft kiest en beheert het model. Het specifieke model kan in de loop van de tijd veranderen. Je hoeft als beheerder zelf geen model te selecteren of te configureren. (Microsoft Learn)

Ook dat past bij het algemene Microsoft 365-model: je gebruikt een dienst die Microsoft beheert, in plaats van zelf een AI-model te beheren.

De vraag die je als informatiemanager zou moeten stellen

De eerste vraag is daarom wat mij betreft niet:

“Welke Skills kunnen we maken?”

Maar:

“Welke werkafspraken willen we eigenlijk herhaalbaar en uitvoerbaar maken?”

Dat is een wezenlijk verschil.

Een Skill kan een redactionele controle uitvoeren. Maar voordat je die Skill bouwt, moet je weten wat “goed geschreven” betekent.

Een Skill kan documenten controleren. Maar dan moet duidelijk zijn welke standaard je gebruikt.

Een Skill kan content classificeren. Maar dan moeten de classificatieregels ergens bestaan en actueel zijn.

De kwaliteit van een Skill wordt volledig bepaald door de kwaliteit van de werkafspraak die erin staat.

En daarna komt de volgende vraag.

Wie is eigenaar van die werkafspraak?

Dat is misschien wel de belangrijkste Skill die je als organisatie moet ontwikkelen.

Bronnen

De schermafbeeldingen in dit artikel komen uit mijn eigen tenant, augustus 2026.

Flexibele secties krijgen hulplijnen

Marcel

In februari 2025 kregen we flexibele secties in SharePoint. De reactie was vrijwel unaniem enthousiast. Eindelijk konden redacteuren webparts neerzetten waar ze wilden, ze schalen, ze over elkaar heen leggen. Geen vaste kolommen meer.

Anderhalf jaar later is de praktijk genuanceerder. Veel redacteuren hebben het één keer geprobeerd en zijn teruggegaan naar de vertrouwde drie kolommen. Niet omdat de functie niet werkt, maar omdat vrijheid zonder houvast lastig is. Je bouwt iets op een breed scherm, het ziet er goed uit, en op een telefoon of in een e-mail valt de compositie uit elkaar.

Deze maand rolt Microsoft verbeteringen uit die dat aanpakken. Ze zijn in de aankondiging beschreven als een gebruiksverbetering. In de praktijk raken ze iets breders: wie in jouw organisatie bepaalt hoe een pagina eruitziet, en wie controleert of hij nog leesbaar is voor iedereen.

Waar we vandaan komen

Een flexibele sectie laat de kolomstructuur los. In plaats van één, twee of drie kolommen krijg je een raster waarin je webparts vrij plaatst. Je kunt ze schalen, over elkaar heen leggen en groeperen zodat ze samen bewegen.

Twee beperkingen die vanaf het begin gelden en die vaak vergeten worden:

Niet elk webpart schaalt vrij. Tekst, Afbeelding en Bestand en media kun je op vrijwel elke breedte zetten. Kaartgebaseerde webparts zoals Snelkoppelingen, Personen en Hero hebben vier vaste breedtes: volledig, tweederde, de helft en een derde van het canvas. Aangepaste SPFx-webparts krijgen standaard diezelfde vier opties.

Op mobiel en in e-mail wordt het altijd één kolom. Overlappende webparts bestaan daar niet. Ze worden onder elkaar gestapeld. In de sectie-eigenschappen kies je in welke volgorde dat gebeurt: van boven naar beneden, of van links naar rechts.

Die tweede beperking is precies waar de meeste teleurstelling zat. Je ontwerpt in twee dimensies, maar de helft van je lezers krijgt één dimensie te zien.

Wat er nu verandert

De aankondiging staat in het Message Center onder MC1446804 en op de roadmap onder ID 567889. De uitrol is wereldwijd, begon medio augustus 2026 en zou eind augustus afgerond moeten zijn. Er is geen actie van beheerders nodig. De functies verschijnen vanzelf.

Drie dingen veranderen.

1. Hulplijnen voor de indeling

In het sectievenster, onder het tabblad Indeling, kies je nu een hulplijnindeling. De opties heten precies zoals de kolomindelingen die je al kent: Geen, Eén kolom, Twee kolommen, Drie kolommen, 1/3 links, 1/3 rechts. Nieuwe webparts lijnen standaard uit op de breedte van die hulplijn. Je kunt daarna nog steeds alles verplaatsen en schalen.

Dat klinkt als een uitlijnhulp. Dat is het niet helemaal. De toelichting in de interface zegt dat de hulplijnen bepalen hoe inhoud wordt verplaatst wanneer de grootte van de sectie verandert. Ze sturen dus het herschikgedrag aan, niet alleen de plaatsing tijdens het bewerken. Samen met de bestaande instelling voor mobiel en e-mail bepaal je daarmee vooraf hoe je ontwerp zich gedraagt op een scherm dat je niet hebt getest.

Dat is het echte verschil met de situatie van anderhalf jaar geleden. Toen was responsief gedrag iets wat je achteraf controleerde in de preview. Nu is het iets wat je vooraf instelt.

2. Raster permanent zichtbaar

Er komt een schakelaar in de opdrachtbalk waarmee je raster en hulplijnen zichtbaar houdt tijdens het bewerken. Daarnaast is er een instelling op paginaniveau voor hetzelfde.

Tot nu toe verschenen de hulplijnen pas op het moment dat je een webpart begon te slepen. Je moest dus iets verplaatsen om te zien of het al goed stond. Klein ongemak, maar het verklaart waarom veel redacteuren het gevoel hadden dat ze aan het gokken waren.

3. Een bestaande sectie omzetten

Dit is de meest onderschatte van de drie. Je kunt een bestaande standaardsectie omzetten naar een flexibele sectie vanuit het eigenschappenvenster van die sectie. De kolomindeling en de plaatsing van de webparts blijven daarbij behouden.

Waarom dat telt: tot nu toe was experimenteren met flexibele secties gelijk aan opnieuw beginnen. Je bestaande nieuwspagina of afdelingspagina moest je van voren af aan opbouwen. Dat is precies de reden waarom veel redacteuren het na één poging lieten zitten. Die drempel verdwijnt.

Eén kanttekening. De documentatie van Microsoft stelde tot nu toe expliciet dat wisselen tussen flexibele en andere sectietypen niet wordt ondersteund. De aankondiging beschrijft alleen de richting standaard naar flexibel. Over de weg terug staat niets. Ga er voorlopig van uit dat conversie eenrichtingsverkeer is en test het op een kopie voordat je het op een gepubliceerde pagina doet.

Het punt dat in geen enkele aankondiging staat

Hier wordt het interessant voor wie verantwoordelijk is voor digitale toegankelijkheid.

In een flexibele sectie volgen de leesvolgorde en de tabvolgorde niet de positie op het canvas. Ze volgen de volgorde waarin de webparts zijn toegevoegd. Dat is meerdere keren gemeld door mensen die het hebben getest, ook in de reacties onder Microsofts eigen aankondiging van de functie.

Wat dat betekent in de praktijk: je kunt een pagina bouwen die er visueel logisch uitziet en die voor een schermlezer of iemand die met het toetsenbord navigeert in een willekeurige volgorde wordt voorgelezen. De blokken staan visueel netjes van links naar rechts, maar worden voorgelezen in de volgorde waarin de redacteur ze toevallig heeft neergezet.

Voor overheden en zorginstellingen raakt dat direct aan verplichtingen. WCAG 1.3.2 gaat over betekenisvolle volgorde, 2.4.3 over focusvolgorde. Beide zijn niveau A. Dit is geen theoretisch risico.

De conversiefunctie maakt dit relevanter dan het was. Een omgezette sectie erft de volgorde van de oorspronkelijke kolommen, en die was waarschijnlijk correct. Maar zodra een redacteur daarna dingen gaat verslepen, kunnen kijkvolgorde en leesvolgorde uit elkaar lopen zonder dat iemand het merkt. Precies de handeling die deze update makkelijker maakt.

Dit is geen reden om flexibele secties te vermijden. Het is wel een reden om de test in je werkwijze op te nemen. Doorloop de pagina één keer met de Tab-toets voordat je publiceert. Als de focus van links onder naar rechts boven springt, klopt de volgorde niet.

Wat dit betekent voor je afspraken

De hulplijnen zijn een instelling per sectie. Niet per pagina, niet per site. Dat betekent dat consistentie tussen pagina’s niet vanzelf ontstaat.

Grofweg zijn er twee routes, met verschillende kosten.

Vooraf vastleggen. Je bepaalt welke hulplijnindelingen passen bij welk paginatype, legt dat vast in paginatemplates en sectietemplates, en informeert je redacteuren voordat ze de nieuwe knoppen zien verschijnen. Kost tijd en overleg. Levert eenheid op en een pagina die er over twee jaar nog steeds uitziet zoals bedoeld.

Achteraf bijsturen. Je laat het gebeuren, kijkt wat redacteuren ermee doen en corrigeert waar het misgaat. Kost minder voorbereiding. Levert meer variatie op, en de kans dat je pas bij een toegankelijkheidsaudit ontdekt wat er is ontstaan.

Welke route past, hangt af van hoeveel redacteuren je hebt, hoe lang je pagina’s blijven staan en of je onder de toegankelijkheidsverplichting valt. Bij tien redacteuren en een handvol pagina’s is bijsturen prima werkbaar. Bij tachtig redacteuren verspreid over veertig afdelingssites is dat een ander verhaal.

Wat in beide routes helpt: een paginatemplate is een sterker sturingsmiddel dan een richtlijn in een document. Redacteuren lezen zelden documentatie. Ze pakken wat er klaarstaat.

Wat je deze maand zou kunnen doen

Een paar concrete stappen, in volgorde van moeite.

Controleer of de functies in je tenant staan. Open een testpagina, klik op een sectie en kijk of je onder Indeling de hulplijnopties ziet.

Test de conversie op een kopie van een bestaande pagina. Kijk wat er met de plaatsing gebeurt, en controleer daarna de mobiele en e-mailweergave via de preview.

Loop één bestaande flexibele sectie door met de Tab-toets. Als je er al hebt, weet je binnen een minuut of je een probleem hebt.

Informeer je redacteuren. Er is geen adminactie nodig, dus zij zien dit vanzelf verschijnen. Een korte uitleg vooraf voorkomt tickets en experimenten op gepubliceerde pagina’s.

Kijk je huidige richtlijnen na. Als daar staat welke kolomindelingen zijn toegestaan, klopt dat document niet meer.

Tot slot

Microsoft heeft hier iets gedaan wat vaker zou mogen. Niet een nieuwe functie toevoegen, maar een bestaande functie voorspelbaarder maken. Flexibele secties waren krachtig en onhandelbaar. Ze worden nu krachtig en stuurbaar.

De vraag die overblijft is niet technisch. Meer ontwerpvrijheid betekent meer manieren waarop pagina’s van elkaar gaan verschillen. Of dat een probleem is, hangt af van wat je intranet moet zijn. Een verzameling afdelingspagina’s die elk hun eigen karakter mogen hebben, of één herkenbare omgeving waarin een medewerker altijd weet waar hij kijkt.

Dat is een keuze die je maakt voordat de knoppen verschijnen, of eentje die je achteraf terugdraait.

Bronnen

  • Message Center MC1446804, SharePoint Pages: Flexible Section Authoring Improvements, 4 augustus 2026
  • Microsoft 365 roadmap ID 567889
  • Microsoft 365 roadmap ID 395213 (introductie flexibele secties, uitrol afgerond april 2025)
  • Microsoft Support: Secties en kolommen toevoegen aan een moderne SharePoint-pagina
  • Microsoft Tech Community: Introducing flexible sections in SharePoint Pages and News, inclusief reacties over tab- en focusvolgorde
Afbeelding weergeven

Wat moet je regelen voordat SharePoint je bestanden archiveert?

Marcel

Microsoft 365 Archive kan sinds kort losse bestanden archiveren in plaats van hele sites. Pieter Kops schreef daar een helder stuk over: wat het is, hoe het werkt en wat het scheelt in opslagkosten. Dat ga ik hier niet overdoen.

Dit artikel gaat over de vraag die daarna komt. Je hebt het gelezen, je ziet de besparing. Alleen: sinds file-level archiving algemeen beschikbaar is, uitgerold in juli 2026, staat de functie standaard aan op je SharePoint-sites. De vraag is dus niet meer “hoe zet ik het aan”, maar “wat had ik geregeld moeten hebben voordat het aanstond, en waar wil ik het juist uitzetten?”

Want file-level archiving is een schakelaar met een verrassend grote kring van betrokkenen. Niet alleen de beheerder, maar ook de site-eigenaar, de redacteur van het intranet en de collega die volgende week een oud bestand zoekt dat ineens “gearchiveerd” blijkt.

Wat is file-level archiving in het kort?

Een gearchiveerd bestand blijft in SharePoint staan, maar verhuist naar een goedkopere opslaglaag. Het is dan niet meer direct te openen, telt niet meer mee voor Copilot en blijft wel vindbaar via Purview Content Search en eDiscovery. Wie leesrechten heeft kan het gratis heractiveren: recent gearchiveerde bestanden komen vrijwel direct terug, bij oudere bestanden kan het tot 24 uur duren (bij grote mappen langer), waarna het 120 dagen niet opnieuw gearchiveerd kan worden.

Dat laatste getal kom je in andere bronnen soms anders tegen. Microsoft Learn noemt 120 dagen. Houd dat aan.

File-level archiving staat standaard aan

In de public preview stond de functie nog standaard uit. Sinds de algemene beschikbaarheid is dat omgedraaid: op elke SharePoint-site waar Microsoft 365 Archive actief is, staat file-level archiving standaard aan. Je hoeft niets te doen om het te laten werken. Je moet juist iets doen om het tegen te houden.

Dat regel je per tenant of per site met PowerShell:

Set-SPOTenant -AllowFileArchive $false
Set-SPOSite -Identity <site_url> -AllowFileArchive $false

En voor sites die je in de toekomst aanmaakt:

Set-SPOTenant -AllowFileArchiveOnNewSitesByDefault $false

Zet je het op $false, dan kan er niets nieuws meer gearchiveerd worden. Bestanden die al in het archief staan, blijven gewoon te heractiveren.

Zolang het aanstaat, kan iedereen met bewerkrechten op een bibliotheek een of meer bestanden selecteren en op Archiveren klikken. Geen goedkeuring, geen extra rol. Dezelfde rechten die iemand nodig heeft om een bestand te bewerken, zijn genoeg om het in de koelkast te zetten. En iedereen met leesrechten kan het er weer uit halen.

Dat is de kern van het governance-vraagstuk. De techniek is bewust laagdrempelig gemaakt en staat inmiddels standaard aan. De vraag is of jouw organisatie daar klaar voor is.

Vraag 1: weet je wat je hebt?

Een gearchiveerd bestand zonder metadata is geen opgeruimd bestand. Het is een bestand dat je kwijt bent. Je vindt het alleen terug als je weet dat het bestaat, in welke site het stond en hoe het heette.

Daarom begint dit onderwerp bij Purview, niet bij Archive. Retentielabels vertellen wat een document is en hoe lang het relevant blijft. Een projectdossier dat na afronding twee jaar bewaard moet worden, een campagneplan dat na de campagne klaar is, een beleidsdocument dat pas vervangen mag worden als de nieuwe versie is vastgesteld. Zonder die afspraken is archiveren een gok op basis van datum.

Heb je die labels nog niet? Dan is dat de eerste stap. Niet omdat archiveren anders technisch mislukt, maar omdat je anders over een jaar niet meer weet wat je in de archieflaag hebt liggen en waarom.

Vraag 2: wie mag archiveren, en waar zet je het uit?

Nu de functie standaard aanstaat, is dit geen theoretische vraag meer. Iedereen met bewerkrechten kan het al. De keuze die je bewust maakt, is waar je dat wilt toestaan en waar niet.

Optie A: site-eigenaren doen het zelf. Laat file archive aanstaan op de sites waar de eigenaar zijn bibliotheek kent en periodiek opruimt. Snel, dicht bij de inhoud, weinig centrale last. Het risico: verschillende sites hanteren verschillende maatstaven, en niemand heeft overzicht.

Optie B: archiveren is een centraal proces. Zet het uit op de sites die er nog niet klaar voor zijn, en laat een beheerder of informatiemanager archiveren op basis van labels of ouderdom, met een vast ritme. Consistent en controleerbaar. Het risico: het wordt een klus die op de stapel blijft liggen, en de site-eigenaar voelt zich er niet verantwoordelijk voor.

Wat je ook kiest: begin met een paar sites, niet met de hele tenant. De schakelaar op siteniveau bestaat precies hiervoor. En zet hem uit op de plekken waar een verdwenen bestand meteen pijn doet, zoals je intranet en je publicatiebibliotheken, tot je die bewust hebt ingericht.

Vraag 3: wat merkt de intranetredactie?

Dit is de vraag die ik in de meeste artikelen mis, en voor wie het intranet beheert is het de belangrijkste.

SharePoint-pagina’s, de Site Assets-bibliotheek, OneNote en SharePoint-agents kunnen niet op bestandsniveau gearchiveerd worden. Dat klinkt geruststellend. Maar een pagina verwijst vaak naar documenten in een gewone bibliotheek: de handleiding onder een knop, het formulier achter een link, de PDF in een quick links-webpart. Archiveert een collega dat bestand, dan werkt de pagina nog, maar de lezer klikt op een link en krijgt een bestand dat eerst geheractiveerd moet worden. En dat is geen kwestie van seconden: heractiveren kan tot 24 uur duren.

Voor Copilot geldt iets vergelijkbaars. Gearchiveerde bestanden vallen buiten het bereik van Copilot. Dat is precies de bedoeling bij oude troep. Het is minder fijn als het bestand een bron was voor een SharePoint-agent die de redactie heeft ingericht. De agent zelf blijft staan, de bron valt weg.

En dan de apps. Niet elke client laat even duidelijk zien dat een bestand gearchiveerd is. Microsoft schrijft zelf dat sommige apps geen duidelijke indicatie geven, en dat de SharePoint-site of OneDrive in de browser de betrouwbaarste plek is om de archiefstatus te zien en een bestand te heractiveren. De ondersteuning per client, van de webversies van Office tot de Teams-app, de mobiele apps en de synchronisatieclient, verschuift bovendien nog. Test in je eigen tenant hoe een gearchiveerd bestand zich gedraagt in de apps die jouw mensen dagelijks gebruiken, voordat je de redactie iets belooft.

Vraag 4: wat betekenen die 120 dagen voor je ritme?

Heractiveren is gratis. Maar een geheractiveerd bestand kan vier maanden lang niet opnieuw gearchiveerd worden.

In de praktijk betekent dat: te vroeg archiveren kost geen geld, wel irritatie. Een collega heractiveert een bestand om er één ding in op te zoeken, en het staat daarna een kwartaal lang weer in de actieve laag. Bij tien bestanden merk je dat niet. Bij een bibliotheek van tienduizend wel.

Een opruimritme per kwartaal, gekoppeld aan je retentielabels, past beter bij die 120 dagen dan ad-hoc archiveren op het moment dat iemand ruimte tekortkomt.

En de kosten dan?

Kort. Archiefopslag kost $0,05 per GB per maand, tegenover $0,20 per GB per maand voor gewone opslag boven je quota. Je betaalt alleen voor wat je quota overschrijdt. Blijf je eronder, dan kost archiveren niets. Facturatie loopt pay-as-you-go via het Microsoft 365 admin center, niet via Azure.

Dat betekent ook: de business case hangt af van je situatie. Zit je ruim onder je quota, dan is de winst geen geld maar minder ruis in zoeken en Copilot. Dat kan een prima reden zijn. Het is alleen een andere reden, en die verdient een ander gesprek met je organisatie.

Waar ik op zou letten

Drie dingen, en het eerste is geen techniek maar een afspraak.

Leg vast wanneer iets het archief in mag. Ouderdom alleen is een slechte maatstaf. Koppel het aan status (afgerond, vervangen, verlopen) en leg dat vast in labels voordat iemand op Archiveren klikt.

Zet het bewust uit waar je nog niet klaar bent. De functie staat standaard aan, dus niets doen is ook een keuze, alleen niet een die je hebt gemaakt. Begin met een pilot op een paar sites en houd het uit op je intranet tot je weet hoe het zich gedraagt.

Vertel de redactie wat er verandert. Zij zijn de eersten die een kapotte link of een verdwenen agentbron opmerken. Neem ze mee voordat de eerste site live gaat, niet erna.

Tot slot

File-level archiving is een goede toevoeging. Het lost een echt probleem op: oude bestanden die kosten, ruis geven en Copilot op het verkeerde been zetten.

Maar de schakelaar is het makkelijke deel, en die staat nu standaard aan. De afspraken eromheen bepalen of je straks een opgeruimde omgeving hebt, of een archieflaag waarvan niemand meer weet wat erin zit.

Loop je hier tegenaan in je eigen organisatie? Laat het weten, ik denk graag mee.

Bronnen: Overview of Microsoft 365 Archive, Manage Microsoft 365 Archive, End user experience in Microsoft 365 Archive en Pricing model for Microsoft 365 Archive op Microsoft Learn; File-level archiving comes to Microsoft 365 Archive, Microsoft Tech Community. Aanleiding: File-level archiving in Microsoft 365: minder ruis, lagere kosten van Pieter Kops.