Categorie: News

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.

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

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.

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

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.