Brand Center of brand kit: waar zet je je huisstijl in Microsoft 365?

Marcel

Kort antwoord: allebei, en waarschijnlijk ook nog een derde plek.

Het SharePoint Brand Center bepaalt hoe je intranet eruitziet. De organisatie-assetbibliotheek levert je sjablonen en beelden aan Word en PowerPoint. En de brand kit in de Copilot-app bepaalt waar Copilot op terugvalt als hij een deck of een visual voor je maakt. Ze overlappen, ze lezen elkaar maar gedeeltelijk, en ze hebben niet dezelfde beheerder nodig.

In dit artikel zet ik op een rij wat waar hoort, wat wel en niet doorwerkt, wat je gebruiker ervan merkt en welke afspraken je beter nu maakt dan straks.

Waar het Brand Center vandaan komt

Lang voordat er een Brand Center bestond, had SharePoint al de organisatie-assetbibliotheek: een aangewezen bibliotheek waarin je Word- en PowerPoint-sjablonen zet, die vervolgens in de Office-apps verschijnen onder een tabblad met de naam van je organisatie.

Het Brand Center is op die bibliotheek gebouwd. Microsoft beschrijft het zelf zo: de assetbibliotheek is de opslag eronder, en het Brand Center is de beheerapplicatie erbovenop. Daar kwamen kleuren, thema’s en eigen lettertypes bij, die SharePoint en de voormalige Viva Connections-ervaring kunnen overnemen.

Er is één Brand Center per tenant. De global admin zet het aan en het vereist een ingeschakelde Public CDN.

Wat de knop in het admincentrum wel en niet doet

Het Brand Center activeer je in het Microsoft 365-admincentrum via Instellingen > Org-instellingen > Brand center. Dat is één knop, plus een sitenaam. Microsoft stelt “Brand Guide” voor.

Hier zit een valkuil die veel mensen pas later ontdekken. Die knop maakt het Brand Center aan, maar níet de organisatie-assetbibliotheken waarin je sjablonen en beelden horen. Die richt je in met PowerShell, met Add-SPOOrgAssetsLibrary.

Het gevolg is zichtbaar bij je gebruikers. Het tabblad met de naam van je organisatie verschijnt namelijk sowieso in PowerPoint, ook als er niets achter zit. Een leeg tabblad dus, waar iedereen in je organisatie overheen klikt.

Had je die bibliotheken al wel, dan werkt het andersom prettiger: het Brand Center herkent de bestaande locatie en bouwt zichzelf op diezelfde site. Je raakt niets kwijt.

Deze volgorde en het lege tabblad zijn waarnemingen uit de praktijk van [PODCAST], die ik herken uit eigen tenants. Microsoft documenteert de PowerShell-stap wel, maar legt het verband met de admincentrum-knop niet expliciet.

Zo vind je het terug

Nog zo’n praktisch dingetje. De Brand Center-app is een systeempagina onder _layouts/15. Ga je naar de sitecollectie, dan land je op de gewone startpagina en zie je hem niet.

De oplossing is simpel: zet de link in de navigatie van die site, of in de favorieten van de mensen die ermee werken. Anders is de eerste vraag bij elke overdracht “waar zat dat ook alweer”.

Het Brand Center is geen beheerdersplek

Dit is het punt dat in de meeste artikelen ontbreekt en dat voor communicatieteams het belangrijkste is.

Het Brand Center is een gewone sitecollectie. Dat betekent dat je er rechten op kunt zetten zoals op elke andere site. Je marketingteam kan de assets beheren. Je vormgever kan de kleuren en de kleurcombinaties aanmaken. Je hoeft daar geen beheerder voor te zijn.

De activering is een beheerstaak. Het beheer daarna hoeft dat niet te zijn. Wie bepaalt welke kleur bij welke combinatie hoort, is geen technische vraag.

Wat je in het Brand Center zet

Kleuren eerst. Importeer al je merkkleuren voordat je een thema maakt. SharePoint-thema’s werken sinds de vernieuwing met maximaal zestien kleurcombinaties en een kleurkiezer, in plaats van de oude beperking tot een hoofdkleur met varianten. Staan je kleuren er al in, dan kies je ze per combinatie uit een lijst in plaats van iedere keer een hexcode over te tikken.

Dan de lettertypes. Eigen fonts upload je in de bibliotheek Brand fonts, waarna je ze in een fontpakket koppelt aan vier slots: titel, kop, body en interactief. Dat pakket verschijnt vervolgens in Het uiterlijk wijzigen bij je site-eigenaren.

Wat er nog niet is. Een preview waarin je kleuren en lettertypes samen ziet. Je beoordeelt ze los van elkaar en ziet het eindresultaat pas op een echte pagina.

Let op de licentiekant van fonts. Door een font te publiceren maakt SharePoint een fontcatalogus aan die publiek benaderbaar is, inclusief de fontbestanden zelf. Microsoft waarschuwt daar expliciet voor. Heb je een font met beperkingen op cloudhosting, controleer dat dan vóór je het uploadt.

Wat een brand kit is

De brand kit is een andere wereld, met een ander doel: hij stuurt wat Copilot maakt.

Je vindt hem in de Copilot-app op microsoft365.com, onder Create, en daarna More. Twee niveaus diep, dus hij is makkelijk te missen.

Een brand kit bevat logo’s, kleurenpaletten, lettertypes, iconen, beelden, Office-sjablonen en een beschrijving van je tone of voice. Die laatste twee zijn het echte verschil met het Brand Center: een brand kit beschrijft niet alleen hoe iets eruitziet, maar ook hoe het klinkt.

Vervolgens kun je in Copilot in PowerPoint via de +-knop in het promptveld een merk kiezen, waarna Copilot dat kit gebruikt bij het genereren van je presentatie.

Hiervoor heb je wel een Copilot-licentie nodig. Voor het Brand Center niet.

Wat hoort waar

Wat Waar je het zet Waar het landt
Merkkleuren en thema’s Brand Center SharePoint-sites en Viva Connections
Lettertypes voor het intranet Brand Center, bibliotheek Brand fonts SharePoint-sites en Viva Connections
Lettertypes voor de Office-apps Organisatie-assetinfrastructuur PowerPoint voor het web (E3 of E5)
Logo’s, iconen en beelden Organisatie-assetbibliotheek (afbeeldingen) Invoegen > Afbeeldingen > Brand Images in PowerPoint
Word- en PowerPoint-sjablonen Organisatie-assetbibliotheek (sjablonen) Tabblad met je organisatienaam bij Bestand > Nieuw
Logo’s, palet, beeld, sjablonen voor AI Brand kit Copilot-gegenereerde decks, documenten en visuals
Tone of voice en merkregels Brand kit Copilot-gegenereerde content

Wat werkt door en wat niet

Dit is het stuk waar de meeste verwarring zit, en waar de antwoorden per type asset verschillen.

Kleuren en lettertypes werken niet door. Wat je in het Brand Center hebt gezet, leest de brand kit niet. Je stelt het daar opnieuw in. Voor lettertypes betekent dat in de praktijk drie keer hetzelfde werk: één keer voor de SharePoint-ervaringen, één keer voor de Office-apps, en één keer voor Copilot.

Sjablonen en beelden kun je sinds kort wel koppelen. Verwijs je vanuit je brand kit naar een bestand dat al in je organisatie-assetbibliotheek staat, dan werkt een wijziging van dat bestand door. Dat geeft je één bron van waarheid voor de bestanden die er het meest toe doen.

Met één uitzondering. Voeg je een níeuw sjabloon toe aan je assetbibliotheek, dan verschijnt dat niet vanzelf in je brand kit. Dat koppel je er handmatig bij.

Wat je gebruiker hiervan merkt

Twee dingen, en ze zijn allebei zichtbaar zonder dat iemand iets hoeft uit te leggen.

Mogelijk twee tabbladen met dezelfde sjablonen. Klikt een collega in PowerPoint op Nieuw, dan ziet hij de Microsoft-galerij, een tabblad met de naam van je organisatie (uit de assetbibliotheek) en een tabblad Brand (uit de brand kit). Verwijst je brand kit naar bestanden die al in de assetbibliotheek staan, dan staan diezelfde sjablonen dus op twee plekken. Voor iemand die alleen een deck wil maken is dat een keuze zonder uitleg.

Copilot gedraagt zich per ingang anders. Vraag je in de Copilot-app om een presentatie met jullie officiële sjabloon, dan krijg je die meestal niet, want daar is de brand kit leidend en niet je assetbibliotheek. Werk je met Copilot ín PowerPoint, dan gaat het beter. Het advies dat je van Microsoft hoort is om eerst het sjabloon te openen en daarna Copilot te vragen. Dat werkt, maar het blijft een omweg.

En dan zijn er nog de ingangen waar het helemaal niet werkt. Copilot in SharePoint kent brand kits niet, dus je AI-gegenereerde intranetpagina pakt je merkregels niet mee.

Wie mag wat

Rond brand kits bestaan twee aparte instellingen in het Microsoft 365 Apps-beheercentrum (config.office.com), en ze doen niet hetzelfde.

Elevated role for Brand Managers bepaalt wie een brand kit officieel mag publiceren voor de hele organisatie. Je wijst een mail-enabled beveiligingsgroep aan, zet het beleid op tenantniveau met prioriteit 0, en de leden van die groep krijgen een publiceerknop in hun kits. Het beleid staat standaard uit.

Restrict brand kit creation bepaalt wie er überhaupt een brand kit mag aanmaken. Zonder dit beleid kan iedere gebruiker met de juiste licentie een eigen kit maken.

En hier zit een valkuil die je één keer meemaakt. Zet je het tweede beleid aan, dan moet je brand manager óók lid zijn van die tweede groep. Zit hij alleen in de brandmanagersgroep, dan kan hij niets meer aanmaken of bewerken. Beide beleidsregels hebben tot 24 uur doorlooptijd.

Microsoft adviseert overigens om een brand kit te combineren met een goed opgebouwd .potx-sjabloon. Het sjabloon levert de indelingen en de slide master, het kit levert logo’s, kleuren en richtlijnen. Zit je branding alleen op losse dia’s en niet in de master, dan houdt Copilot het niet vast.

En dan de schaal

Stel, je hebt alles ingericht. Dan komt de vraag die bij een intranet van enige omvang direct opspeelt: hoe weet je of het ook gebruikt wordt?

Daar lopen op dit moment drie dingen tegen elkaar in.

Je kunt een thema uit het Brand Center niet in bulk toepassen. Wil je het op dertig sites, dan ga je dertig keer naar Het uiterlijk wijzigen.

Er is geen overzicht van welke site welk thema gebruikt. Je kunt dus niet zien waar je afspraak wordt gevolgd en waar niet.

En er bestaat een brandingervaring op siteniveau die sterk lijkt op wat het Brand Center doet. Site-eigenaren kunnen daar eigen thema’s met eigen kleuren maken, los van wat jij centraal hebt klaargezet.

Dat laatste is uit te schakelen, maar alleen via PowerShell en niet met één knop voor de hele tenant. Of je dat wilt, hangt af van je organisatie. Een centrale huisstijl die je echt wilt afdwingen pleit ervoor. Afdelingen of merken met een eigen identiteit pleiten ertegen. Belangrijk is vooral dat het een keuze is die je maakt, en niet iets wat je overkomt omdat niemand wist dat de knop bestond.

Waar ik op zou letten

Benoem één eigenaar van de huisstijl in Microsoft 365. Niet van het Brand Center, niet van de brand kit, maar van het geheel. Zolang er drie plekken zijn, is de kans groot dat er drie halve eigenaren zijn.

Leg vast welke bron leidend is. Wijken kleuren of logo’s op twee plekken van elkaar af, dan wil je niet gaan vergaderen over wie gelijk heeft. Kies de organisatie-assetbibliotheek als bron voor bestanden en verwijs er vanuit je brand kit naar, dan heb je in elk geval voor sjablonen en beelden één versie.

Reken op handwerk bij een rebranding. Nieuwe fonts betekenen drie uploads. Dat is te overzien, zolang je van tevoren weet dat het zo werkt en niet halverwege ontdekt dat je intranet al om is en PowerPoint nog niet.

Train je redacteuren op de twee tabbladen. Dit is het soort verschil dat je in één zin uitlegt en dat anders maanden voor verwarring zorgt.

Kijk hier opnieuw naar over een half jaar. Dit onderdeel beweegt snel. De import van merkrichtlijnen uit een pdf was er en lijkt inmiddels weer weggehaald. De koppeling tussen brand kits en Clipchamp staat in de interface, maar lijkt nog niet te werken. Verwacht dat Microsoft deze onderdelen dichter bij elkaar brengt.

Tot slot

Branding in Microsoft 365 is er in een paar jaar enorm op vooruitgegaan. Wie dit tien jaar geleden deed, bouwde niet-ondersteund maatwerk en hoopte dat het de volgende update overleefde. Dat is voorbij.

Wat nog niet af is, is de samenhang. Een deel is gebouwd voor SharePoint, een deel voor Copilot, en de Office-apps zitten er tussenin en erven van allebei een stukje. Dat merk je als beheerder bij het inrichten, en je gebruiker merkt het bij het eerste deck dat hij maakt.

Dat is geen reden om te wachten. Wie wacht tot het af is, begint nooit, want er komt elke maand iets bij. Wel een reden om nu vast te leggen wie erover gaat.

Loop je hier tegenaan bij het inrichten, of wil je sparren over waar jullie huisstijl het beste landt? Laat het weten, ik denk graag mee.

Bronnen: SharePoint brand center, Brand fonts, Font packages, Font licensing for the brand center, Connect organizational asset libraries to PowerPoint, Enable enterprise brand images with PowerPoint Copilot, Enterprise brand manager policy setup en Restrict brand kit creation op Microsoft Learn.
Praktijkervaringen uit de M365-podcast van Hands-On M365, opgenomen bij CollabDays Bletchley Park op 23 september 2026.

Targeted release verdwijnt: waar laat je straks je testgroep?

Marcel

Veel organisaties hebben één plek waar ze zien wat Microsoft met SharePoint en Teams gaat doen voordat de rest van de organisatie het ziet. Een handvol mensen in Targeted release. De functioneel beheerder, iemand van IT, in het beste geval ook een redacteur.

Die constructie verdwijnt. In januari 2027 stopt Microsoft met Targeted release voor Microsoft 365-diensten. De eerste harde datum ligt dichterbij: vanaf november 2026 kun je niemand meer toevoegen aan die groep, er niemand meer uit halen en de instelling niet meer wijzigen.

Er komt iets voor in de plaats. Alleen werkt het precies andersom dan je gewend bent, en dat is het stuk waar het in de praktijk misgaat.

Wat er verandert en wanneer

Microsoft stapt over op een model met drie release-audiences. Targeted release past daar niet meer in en gaat eruit.

Nu. Kijk in het admincentrum wie er in Targeted release zit en bepaal welke voorkeur daarvoor in de plaats komt.

November 2026. Wijzigingen aan Targeted release-toewijzingen zijn niet meer mogelijk. Tegelijk verschijnt er een nieuw, samengevoegd scherm voor release-voorkeuren waarin je Frontier, Standard release en Deferred release op één plek beheert. Het huidige scherm voor Standard en Deferred verdwijnt op dat moment.

Januari 2027. Targeted release wordt uitgezet. De toewijzingen worden niet meer gebruikt voor het uitleveren van functies. Iedereen die erin zat, valt terug op de voorkeur die je voor algemene beschikbaarheid hebt ingesteld.

Het raakt de diensten die nu via Targeted release uitleveren: het Microsoft 365-admincentrum, Microsoft Teams, OneDrive, SharePoint Online, Outlook op het web, de nieuwe Outlook voor Windows, Office voor het web en enkele onderdelen van Exchange Online.

De drie opties die ervoor in de plaats komen

Frontier. Toegang tot functies voordat ze algemeen beschikbaar zijn. Bedoeld voor experimenteren, valideren en feedback geven, niet voor processen waar je bedrijf op draait. Het gaat inmiddels om AI- en niet-AI-functies.

Standard release. Je krijgt functies op het moment dat ze algemeen beschikbaar worden. Dit is de standaardinstelling en voor de meeste organisaties het uitgangspunt.

Deferred release. Je krijgt grote wijzigingen ongeveer 30 dagen later dan de Standard-groep. Bedoeld voor organisaties die tijd nodig hebben voor validatie of interne communicatie.

Bij Deferred hoort een belangrijke beperking. Het geldt niet voor alles. Alleen voor wijzigingen die Microsoft aanmerkt als grote wijziging én als deferred-capable. In je Message Center herken je die aan twee labels: Major update en Deferred feature. Een kleine aanpassing in de paginabewerker van SharePoint valt daar doorgaans buiten en komt gewoon binnen op het GA-moment.

Wie Deferred leest als “alles komt bij ons een maand later” komt bedrogen uit.

De omkering die je moet doorhebben

Targeted release zette een kleine groep vóór de organisatie. De rest liep op het normale tempo mee.

Het nieuwe model kent die vooruitgeschoven groep niet bij algemene beschikbaarheid. Je bereikt hetzelfde effect door de beweging om te draaien: je zet de organisatie áchter de GA-datum met Deferred release, en haalt je testgroep naar voren door die juist op Standard release te zetten.

Microsoft beschrijft die route zelf in de documentatie:

Huidige instelling Aanbevolen nieuwe instelling
Targeted release voor de hele organisatie Standard release, of Deferred release als je meer voorbereidingstijd wilt
Targeted release voor geselecteerde gebruikers Tenant op Deferred release, en je validatie-, support- of pilotgebruikers toevoegen aan Standard release
Standard release voor iedereen Niets doen, dit is de standaard

De tweede rij is degene die telt voor de meeste intranetorganisaties. Het is ook de rij waar je je kunt vergissen. Zet je je pilotgroep uit gewoonte op Deferred, dan loopt juist die groep achter en zien de collega’s die niets hoeven te testen de verandering als eerste.

Wat hier níet onder valt

De updatekanalen van Microsoft 365 Apps, de updatekanalen van Windows en het Microsoft 365 Insider-programma veranderen niet. Die staan los van deze wijziging en houden hun eigen instellingen.

Wat gebeurt er als je niets doet?

Microsoft past je instellingen niet automatisch aan. Tot de retirement blijven je Targeted release-gebruikers gewoon functies ontvangen. Daarna vallen ze terug op je ingestelde voorkeur voor algemene beschikbaarheid. Heb je die nooit ingesteld, dan is dat Standard release.

Technisch gaat er dus niets stuk. Praktisch ben je in januari je vooruitblik kwijt zonder dat iemand ergens op heeft geklikt. Het eerste wat je ervan merkt, is een collega die vraagt waarom de knop ineens ergens anders staat.

Waarom dit ook op het bureau van communicatie ligt

Het is verleidelijk om dit af te doen als een instelling in het admincentrum. Technisch klopt dat.

De vraag eronder is wie er in die validatiegroep hoort. Bij veel organisaties zit daar IT in en de intranetredactie niet. Terwijl de redactie degene is die als eerste merkt dat een webpart anders oogt, dat de nieuwsbewerker een knop heeft verplaatst of dat een sjabloon er op mobiel anders uitziet. Die signalen komen zelden uit een testscript.

Nu je die groep toch opnieuw moet inrichten, is dit het natuurlijke moment om die samenstelling tegen het licht te houden. Dat hoeft niet te betekenen dat de redactie erin gaat. Het betekent wel dat het een keuze wordt in plaats van een erfenis.

Er zit nog een tweede communicatievraag in. Wie vertelt de organisatie dat er iets verandert in de werkplek, en op basis van welk signaal? Als je testgroep straks op Standard zit en de rest op Deferred, heb je dertig dagen om dat te doen. Dat venster is alleen bruikbaar als iemand het Message Center leest en vertaalt naar gewone taal.

Wat je nu kunt doen

  1. Kijk wie er nu in Targeted release zit. In het Microsoft 365-admincentrum: Instellingen > Org-instellingen > Organisatieprofiel > Releasevoorkeuren.
  2. Bepaal welke rij uit de tabel hierboven op jou van toepassing is en stel de bijbehorende voorkeur in onder Copilot > Instellingen > Alles weergeven > Copilot Release preferences: General availability.
  3. Beslis of je iemand toegang wilt geven vóór algemene beschikbaarheid en richt Frontier in onder Copilot > Instellingen > Alles weergeven > Copilot Frontier.
  4. Werk je eigen documentatie en processen bij. Overal waar “Targeted release” staat in een werkinstructie, een beheerhandboek of een wijzigingsprocedure, klopt die verwijzing straks niet meer.
  5. Laat het de mensen weten die het raakt. Changemanagement, support, security en compliance, en je pilotgroep zelf.

Punt 1 tot en met 3 zijn werk van een halfuur. Punt 4 en 5 zijn het werk dat blijft liggen.

Tot slot

Dit is geen spannende wijziging. Er verdwijnt geen functionaliteit en er gaat niets kapot. Het is een instelling die verhuist en een logica die omdraait.

Juist daarom is het het soort wijziging dat in november langs iedereen heen gaat en in januari ineens opvalt. De groep die altijd een stapje voorliep, loopt dan gewoon mee. Dat is prima als je het zo hebt gekozen, en vervelend als het je overkomt.

Loop je hier tegenaan bij het inrichten? Laat het weten, ik denk graag mee.

Bronnen: Plan for the retirement of Targeted release in Microsoft 365, Configure new Standard and Deferred release options for Microsoft 365, Get started with the Microsoft Frontier Program en Frequently asked questions about modern release options op Microsoft Learn. Het bijbehorende Message Center-bericht staat in je eigen tenant.

HTML-pagina’s in SharePoint: wat kan wel en wat niet?

Marcel

Vanaf oktober kun je in SharePoint een pagina publiceren die helemaal uit HTML bestaat. Je laat Copilot hem ontwerpen, of je uploadt een HTML-bestand dat al klaarligt. SharePoint toont het resultaat als gewone pagina, naast je bestaande sitepagina’s.

In augustus schreef ik er al kort over op LinkedIn, toen er alleen nog een roadmap-item was. Er bleven toen vragen open. Wie bewaakt de huisstijl? Wat gebeurt er met scripts? Wie mag zo’n pagina plaatsen? Inmiddels heeft Microsoft de documentatie gepubliceerd en zijn de meeste antwoorden bekend.

In dit artikel zet ik ze op een rij: wat het is, hoe je het aanzet, wat er wel en niet kan, en waar ik als beheerder of communicatieadviseur op zou letten.

Wat is een HTML-pagina in SharePoint?

Een HTML-pagina is een los HTML-bestand in de bibliotheek Sitepagina’s dat SharePoint als pagina weergeeft. De SharePoint-balk met navigatie, Delen en Bewerken blijft gewoon bovenaan staan. Daaronder staat jouw ontwerp, zonder dat je beperkt bent tot secties en webparts.

Het voorbeeld hierboven komt van Microsoft zelf: de leeromgeving van het fictieve bedrijf Zava. Een donker ontwerp met grote typografie, een inhoudsopgave aan de zijkant en animaties. Met standaard webparts bouw je dat niet.

Het is een extra paginatype, geen vervanging. Je gewone sitepagina’s (ASPX) blijven bestaan en werken zoals je gewend bent.

Hoe zet je het aan?

Dit is het eerste wat je moet weten: HTML-pagina’s staan niet vanzelf aan. De site-eigenaar moet per site toestaan dat de bibliotheek Sitepagina’s HTML-bestanden accepteert.

  1. Ga naar de bibliotheek Sitepagina’s.
  2. Kies File types (Bestandstypen) in de commandbalk.
  3. Zet Allow HTML files aan.

Wil je het weer blokkeren, dan zet je dezelfde schakelaar uit.

Belangrijk voor beheerders: op tenantniveau uitzetten of beperken kan niet. Microsoft zegt dat letterlijk in de documentatie. De keuze ligt dus bij elke site-eigenaar afzonderlijk. Daarover verderop meer.

Let op: de uitrol loopt nog. De Engelse knopteksten komen uit de documentatie van Microsoft. Hoe ze in de Nederlandse interface heten, zie ik pas als het in mijn eigen tenant staat. Dan werk ik dit artikel bij.

Hoe maak je een HTML-pagina?

Er zijn drie routes.

Met Copilot. Kies op een site + New en dan HTML page, gebruik de zwevende Copilot-knop rechtsonder, of ga naar de Publish-startpagina en kies + Create en dan HTML page. Je beschrijft in een prompt wat je wilt, eventueel met bestanden als bijlage. Copilot maakt een concept en opent het in bewerkmodus. Controleer daarna of de pagina in Sitepagina’s staat. Zo niet, vraag Copilot hem te verplaatsen of doe het zelf.

Microsoft geeft in de documentatie een paar voorbeeldprompts, zoals een projectstatuspagina met roadmap en veelgestelde vragen, of een pagina met teamprofielen en een tijdlijn. Hoe concreter je bent over inhoud, opbouw en kleuren, hoe beter het resultaat.

Door te uploaden. Via hetzelfde scherm kies je Upload HTML page. In de bibliotheek Sitepagina’s kan het ook: Create or upload en dan Upload HTML page of Upload HTML folder. Met een map neem je afbeeldingen en andere bestanden mee. Die komen in Site assets terecht.

Vanuit een documentbibliotheek. Staat er al een HTML-bestand in een gewone documentbibliotheek, dan kies je via het menu Edit en daarna Edit in SharePoint. Let op: SharePoint verplaatst het bestand dan naar Sitepagina’s. Het verdwijnt uit de oorspronkelijke bibliotheek. Dat geldt ook als je bestanden met Move to naar Sitepagina’s verplaatst.

Hoe bewerk je zo’n pagina?

Op twee manieren. Tekst pas je rechtstreeks op de pagina aan: Edit, tekst selecteren, typen. Voor grotere wijzigingen in inhoud of ontwerp gebruik je het Copilot-chatvenster. Dan beschrijf je wat er moet veranderen, bijvoorbeeld “voeg onderaan een sectie met veelgestelde vragen toe” of “maak de achtergrond van de kop onze huisstijlkleur”.

Je hoeft dus geen HTML te kunnen schrijven. Wel handig om te weten: hoe preciezer je aangeeft welk onderdeel je bedoelt, hoe beter Copilot de wijziging op de juiste plek zet.

Publiceren werkt zoals bij een gewone pagina. Publish maakt de pagina zichtbaar voor iedereen die er rechten op heeft. Publiceren geeft zelf geen nieuwe rechten. Met Save and close bewaar je hem als concept.

Welke licentie heb je nodig?

Dat hangt af van wat je doet.

Wat je doet Copilot-licentie nodig?
Pagina maken via + New of + Create (HTML page) Ja
Pagina maken of bewerken via het Copilot-chatvenster Ja
HTML-bestand uploaden of verplaatsen naar Sitepagina’s Nee
Tekst direct op de pagina bewerken Nee
Publiceren en delen Nee
Pagina bekijken Nee

Ook zonder Microsoft 365 Copilot kun je dus HTML-pagina’s publiceren, mits iemand het bestand aanlevert. Voor alle acties heb je de gewone SharePoint-rechten nodig: pagina’s maken of bewerken, bestanden toevoegen, publiceren.

Wat kan wel en wat niet?

De pagina draait in een afgeschermde omgeving, een zogenaamde sandbox. SharePoint zet de HTML in een geïsoleerd frame, los van de header, footer en navigatie eromheen, met extra beveiligingsregels (Content Security Policy). Dat verklaart de meeste beperkingen.

Wat wel kan

  • Tekst bewerken op de pagina
  • Eigen afbeeldingen, als base64 in het bestand of via een URL binnen hetzelfde domein
  • Video als overlay, Word-, Excel-, PowerPoint- en pdf-bestanden openen in een nieuw tabblad
  • Live data uit SharePoint-lijsten en Excel
  • Links binnen de site, binnen de tenant en naar buiten (voor externe domeinen zie hieronder)
  • Ankerlinks binnen de pagina
  • JavaScript, zolang het in hetzelfde HTML-bestand staat
  • De bibliotheken Chart.js, Mermaid, React, Fluent UI en Babylon, gehost door Microsoft
  • Bekijken in de SharePoint-app in Teams op mobiel
  • Paginastatistieken, vergelijkbaar met gewone pagina’s

Wat niet kan

  • Externe API-aanroepen en willekeurige fetch-requests
  • Scripts of bibliotheken van een eigen of externe CDN
  • Live data uit andere bronnen, zoals Jira
  • De localStorage van de browser gebruiken
  • Inline video, audio en Office- of pdf-bestanden in de pagina tonen
  • Stockfoto’s, organisatie-assets of AI-gegenereerde afbeeldingen via de editor
  • Bewerken in de mobiele Teams-app

En voor communicatie misschien het belangrijkste lijstje:

  • Promoten naar nieuwsbericht
  • Amplify naar Teams en Viva Engage
  • Reacties en likes
  • Plannen van publicatie
  • Samen schrijven (co-authoring) en privéconcepten
  • Opslaan als paginatemplate

Een HTML-pagina is dus een presentatielaag. Hij komt niet in je nieuwsfeed, gaat niet mee in je Engage-flow en collega’s kunnen er niet op reageren.

Waarom opent een link op mijn pagina niet?

Links naar een andere tenant of naar een site buiten SharePoint werken alleen als het domein op de allowlist van de site staat. Dat regelt een site-beheerder:

  1. Ga naar Instellingen > Site-informatie > Alle site-instellingen weergeven.
  2. Kies HTML Field Security.
  3. Voeg het domein toe aan de lijst, sla op en ververs de pagina.

Dit is dezelfde lijst die je misschien al kent van ingesloten video’s en iframes.

Krijgt een HTML-pagina automatisch mijn huisstijl?

Alleen als Copilot hem maakt. Pagina’s die Copilot maakt of via een prompt bijwerkt, krijgen het thema en lettertype van de site. Een geüpload HTML-bestand niet. Dat toont precies wat erin staat. Je kunt Copilot achteraf vragen de pagina op de site-huisstijl aan te passen, maar daarvoor heb je weer een Copilot-licentie nodig.

Het maximum per HTML-bestand is 10 MB. Wordt het groter, verwijs dan naar gehoste afbeeldingen in plaats van ze in te sluiten en haal overbodige code weg.

Waar ik op zou letten

Maak de schakelaar onderdeel van je afspraken. Omdat je het niet centraal kunt uitzetten, bepaalt elke site-eigenaar zelf of zijn site HTML-pagina’s accepteert. Voor een kleine organisatie is dat geen probleem. Heb je honderden sites, neem het dan op in je site-aanvraagproces en in de instructie voor site-eigenaren. Op welke sites mag het aan, en wie beslist dat?

Denk na over huisstijl en toegankelijkheid. De vrijheid die dit biedt, geldt voor iedereen met bewerkrechten. Als elke afdeling zijn eigen ontwerp bouwt, heb je straks tien huisstijlen op één intranet. Geüploade HTML krijgt je huisstijl niet automatisch. En toegankelijkheid (WCAG) is bij een zelfgebouwde pagina net zo goed je verantwoordelijkheid. Voor overheid en zorg is dat een wettelijke verplichting. Een checklist voor wie een HTML-pagina publiceert, is snel gemaakt.

Pas op met ontwerpen van buitenaf. Levert een bureau een campagnepagina aan, controleer dan vooraf of die zonder externe scripts, lettertypen van een CDN of API-koppelingen werkt. Wat buiten de sandbox valt, doet het niet. Beter om dat vóór de lancering te ontdekken.

Kies bewust welk type pagina je gebruikt. Een HTML-pagina is sterk voor naslag die er goed uit moet zien: een onboardingsgids, een jaaroverzicht, een campagnepagina, een projectdashboard op basis van een SharePoint-lijst. Wil je dat collega’s reageren, of moet het bericht in de nieuwsfeed en in Viva Engage komen, dan blijft een gewoon nieuwsbericht de aangewezen route.

Check wat er met ‘live’ cijfers bedoeld wordt. Het voorbeeld van Microsoft toont indrukwekkende getallen en “real-time skill telemetry”. Live gegevens kunnen alleen uit SharePoint-lijsten en Excel komen. Wie een dashboard met een koppeling naar een LMS, CRM of ticketsysteem verwacht, moet de data eerst in een lijst krijgen. Of accepteren dat het een momentopname is.

Wanneer kun je het verwachten?

Volgens het Message Center loopt de uitrol van oktober tot en met december 2026. Je vindt het terug onder MC1479517 (roadmap-ID 569208). Het werkt in de webversie van SharePoint.

Als beheerder is het verstandig de afspraken over de schakelaar per site te maken voordat de knop bij je gebruikers verschijnt. Achteraf terughalen is lastiger.

Tot slot

HTML-pagina’s geven communicatieteams iets waar ze lang om hebben gevraagd: een pagina die eruitziet zoals zij hem bedacht hebben, zonder ontwikkelaar. Tegelijk is het een paginatype met duidelijke grenzen. Geen nieuws, geen gesprek, geen externe koppelingen.

Wie die grenzen kent, kan er goed mee uit de voeten. Wie ze niet kent, loopt er bij de eerste campagne tegenaan.

Bron: Create, upload, edit, and publish HTML pages in SharePoint, Microsoft Support. Message Center: MC1479517, roadmap-ID 569208. Beeld: Microsoft, demo-omgeving Zava.

Een intranetbeheer-dashboard maken met Copilot Skills, zonder developer

Marcel

Wie een SharePoint-intranet beheert, kent de vraag: welke pagina’s zijn verouderd, welke staan nog in concept en welke zijn uitgecheckt? Het antwoord vinden kost normaal veel klikwerk, of je laat een developer een rapportage bouwen. Sinds Copilot Skills kan het ook anders: je bouwt als eindgebruiker zelf een interactief dashboard. In deze blog en video laat ik zien hoe dat werkt.

Wat zijn Copilot Skills?

Copilot Skills zijn herbruikbare instructiesets die je zelf definieert in Microsoft 365 Copilot. Je legt eenmalig vast wat Copilot moet doen en hoe het resultaat eruit moet zien. Daarna voer je de skill uit wanneer je wilt, zonder telkens opnieuw je prompt op te bouwen.

De video: van skill naar dashboard

In onderstaande video zie je het complete proces. Ik heb een skill gemaakt met de naam SiteBeheerAudit en die uitgevoerd over 7 sites met in totaal 150 pagina’s:

Het resultaat is een HTML-dashboard dat in SharePoint leeft. In één oogopslag zie ik wat aandacht nodig heeft: 9 uitgecheckte pagina’s, pagina’s die nog in concept staan, 101 verouderde pagina’s en 18 pagina’s zonder titel. Bovenin staat een KPI-overzicht, daaronder een prioriteitenlijst en een filterbalk. Ik kan filteren op status en zelfs inzoomen per site, bijvoorbeeld alleen de uitgecheckte pagina’s van de site ICT.

Hoe zit het achter de schermen?

Het dashboard is geen losstaand trucje. In een documentbibliotheek Agent Assets in SharePoint staan de skill en het template. De skill bevat de instructieset voor het uitvoeren van de audit, het template bepaalt hoe het dashboard eruitziet. Copilot gebruikt beide elke keer dat je de skill draait. De versiegeschiedenis laat zien dat ik acht versies nodig had om tot dit resultaat te komen. Itereren hoort erbij, maar het blijft werk dat je zelf kunt doen.

Heb je hier een developer voor nodig?

Nee, en dat is precies het punt. Dit soort dashboards liet je voorheen door een developer bouwen. Met Copilot Skills maak je het als eindgebruiker zelf, met wat iteraties. Dat geeft net wat extra jus aan je intranet, zonder ontwikkelkosten en zonder wachttijd.

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.