SharePoint struktur best practice: ryd op til Copilot

I har flyttet filserveren til SharePoint, men I leder stadig efter dokumenter i dybe mapper og gamle genveje. Copilot giver upræcise svar, fordi indholdet mangler kontekst og afgrænsning. Samtidig vokser risikoen for oversharing, når projekter og leverandører blandes på tværs. Her får I en praktisk SharePoint struktur best practice, der kan implementeres uden et kæmpe IA-projekt.

• Skil data ad med hubs: Byg en flad arkitektur med Hub Sites, så Produktion, Projekter og HR ikke ender i samme søge- og Copilot-scope.
• Byt mapper ud med få, stærke kolonner: Indfør 3–6 metadatafelter pr. bibliotek (fx Projekt-ID, Dokumenttype, Status) og brug views som “mapper”.
• Brug Document Sets til projekter: Saml “Projekt A” som en enhed, så alle dokumenter arver samme metadata og I slipper for mappe-helvede.
• Stop biblioteker der bliver for store: Hold performance ved at filtrere på metadata og undgå “alt i ét bibliotek” uden indekserede kolonner (SharePoint-soft limit på 5.000 items pr. view).
• Gør NIS2 praktisk: Brug Sensitivity Labels og tydelige site-grænser, så “hvem må se hvad” kan dokumenteres og håndhæves.

Hvorfor dybe mapper giver dårlig søgning og dårlig Copilot

Mapper føles trygge, men de er et dårligt styringsværktøj i Microsoft 365. I praksis bliver mappestien en privat “logik” i hovedet på dem, der byggede strukturen. Når medarbejdere skifter rolle, eller et projekthus reorganiserer, falder den logik fra hinanden.

Copilot og søgning performer bedre, når dokumenter har tydelige signaler: dokumenttype, projekt, anlæg, kunde, status. Microsofts anbefalinger for Copilot-optimering peger på, at metadata er mere brugbart som kontekst end mappestier, fordi det kan filtreres, genbruges og valideres.

Før → Efter #1
Før: “\\Projekter\\2025\\KundeX\\02 Udførelse\\Tegninger\\Final\\Final2” og ingen ved, hvad “Final2” betyder.
Efter: Ét bibliotek med Document Sets pr. projekt + kolonnerne Projekt-ID, Dokumenttype, Revision, Status. Resultat: I kan filtrere, lave views og få mere præcise Copilot-svar, fordi konteksten står i felter – ikke i mappestier.

Sådan bygger I en flad SharePoint-arkitektur med Hub Sites

Microsoft anbefaler “flat architecture”: flere sites i et overskueligt niveau, forbundet med hubs – frem for dybe hierarkier med subsites. Subsites er i praksis en blindgyde i moderne SharePoint, mens Hub Sites giver fælles navigation og søge-scope uden at blande rettigheder ukontrolleret.

Praktisk hub-model til produktion og projekthuse

• Hub: Produktion (kvalitet, procedurer, tegninger, maskindata). Stram adgang.
• Hub: Projekter (projekt-sites pr. kunde/leverance). Skabelonstyret.
• Hub: Administration (økonomi, salg, HR). Isoleret fra projektdata.
• Ekstra hub ved behov: Leverandører/Partnerskaber (hvis I har mange gæster).

Beslutningsregel: Hvis to områder har forskellige regler for gæsteadgang, retention eller labels, så skal de typisk ikke være i samme hub.

Hvordan vælger I mellem metadata vs. mapper i 2026

I behøver ikke forbyde mapper. I skal styre, hvor de giver mening. Tommelfingerreglen for SharePoint metadata vs mapper er enkel: Mapper til “arbejdsbunker” og midlertidig sortering; metadata til alt, der skal findes igen, rapporteres på, arkiveres eller bruges af Copilot.

Brug metadata når

• I vil filtrere på tværs af projekter (fx alle “Kontrakter” med status “Til underskrift”).
• I vil styre livscyklus (fx “Udløbet/Arkivér”).
• I vil bruge automatisering (fx Power Automate-regler baseret på Dokumenttype).
• I vil have styr på compliance (labels, retention, eDiscovery).

Brug mapper når

• I har korte forløb (1–2 uger) hvor teams sorterer midlertidigt.
• I har store filer der kun håndteres af få personer og ikke skal søges bredt.

Tjekliste: SharePoint governance plan, der kan driftes af en SMB

Det her er “set-and-forget” versionen: få regler, konsekvent udrulning og månedlig kontrol. Den virker både ved flytte filserver til SharePoint og når I allerede har 200 sites uden ejere.

1. Definér 4 site-typer (templates): Projekt, Produktion/Proces, Afdeling, Ekstern samarbejde. For hver: standardbiblioteker, standardkolonner, standardlabels.
2. Minimér metadata (men gør dem obligatoriske): 3–6 felter pr. bibliotek. Start med: Dokumenttype, Projekt-ID/Anlæg, Klassifikation, Status, Ejer (valgfri).
3. Indekser kolonner og byg views: Lav “Kontrakter”, “Tegninger”, “Seneste ændringer” som views. Undgå views der viser “Alle dokumenter” uden filter når bibliotekerne vokser.
4. Ejerskab og gæsteadgang: Hvert site skal have 2 ejere. Gæster må kun være i sites med “Ekstern samarbejde”-typen.
5. Labels og minimumskrav: Sæt Sensitivity Labels pr. site-type. Kræv “Intern” som minimum. “Fortrolig” for kontrakter, HR og leverandørpriser.
6. Livscyklus: Projekt-sites får en slutdato. Efter afslutning: read-only + arkiveringskø. Overvej Microsoft 365 Archive til “døde” projekter, så I ikke betaler aktiv storage for alt.
7. Månedlig kontrol (30 min): Tjek nye sites, eksterne brugere, delingslinks og sites uden ejer. SharePoint Advanced Management kan rapportere oversharing og gæster på tværs.

Før → Efter #2
Før: Projekt-sites lever for evigt. Gæster bliver hængende. Ingen tør slå Copilot til, fordi man ikke ved, hvad der ligger hvor.
Efter: Site-lifecycle med slutdato + ejer-bekræftelse, labels pr. site-type og månedlig oversharing-rapport. Resultat: I kan dokumentere adgang og reducere “ukendte” delinger, samtidig med at søgning og Copilot bliver mere præcis.

Sådan bygger I “det perfekte projektrum” med Document Sets

Til projekthuse er Document Sets ofte den hurtigste vej væk fra mapper. Et Document Set er en “container” i et bibliotek, hvor alle dokumenter automatisk arver projektets metadata. Det gør standardisering lettere, også når projektlederen ikke er SharePoint-ekspert.

Opskrift (konkret)

• Ét Projektbibliotek i projekt-sitet.
• Aktivér Document Sets og opret en type: “Projekt”.
• Felter på Document Set: Projekt-ID, Kunde, Projektleder, Fortrolighed.
• Felter på dokumenter: Dokumenttype (Kontrakt/Tegning/Referat), Status (Kladde/Godkendt), Revision.
• Views: “Til godkendelse”, “Tegninger – seneste revision”, “Kontrakter”.

Fejl der koster tid: biblioteker uden filtre og grænser

SharePoint kan håndtere meget store biblioteker, men drift og brugeroplevelse falder, når I lægger alt i ét bibliotek og forventer, at folk bare søger. Microsoft beskriver stadig en 5.000 items view threshold som en praktisk soft limit for visninger, og performance bliver typisk dårligere når store biblioteker ikke er segmenteret med metadata og indekserede kolonner.

Tre simple grep:

• Split logisk: Ét bibliotek pr. proces/område (fx “Tegninger” og “Kontrakter”), ikke pr. år.
• Filtrér altid: Standardview skal have filter (fx Status = Aktiv).
• Undgå masse-synk: Synkronisér ikke hele biblioteker med tusindvis af filer. Synk kun projektets Document Set eller filtrerede mapper.

FAQ: spørgsmål vi ofte får om SharePoint struktur

Hvad er SharePoint struktur best practice, hvis vi kommer fra filserver?

Lav en flad struktur med flere sites (fx pr. afdeling og pr. projekt), forbundet med hubs. Migrér ikke mappetræet 1:1. Kortlæg de 10–20 mest brugte dokumenttyper og lav metadata til dem, før I flytter alt.

SharePoint hub sites vs subsites: hvad skal vi vælge?

Vælg Hub Sites som standard. Subsites passer dårligt til modern SharePoint og gør omorganisering sværere. Brug hubs til fælles navigation og søgning, og brug separate sites som sikkerhedsgrænser.

SharePoint metadata vs mapper: hvor mange metadatafelter kan vi tåle?

Start med 3–6 felter pr. bibliotek. Hvis brugerne ikke kan udfylde dem på under 15 sekunder ved upload, er I typisk gået for langt. Brug valgfelter (choice) og defaults for at gøre det hurtigt.

Hvordan hænger NIS2 dokumentation sammen med SharePoint?

NIS2 handler ikke kun om tekniske kontroller, men om at kunne vise styring af data. I SharePoint betyder det: tydelige site-grænser, ejerskab, logning/audit og klassifikation via Sensitivity Labels. Brug labels og adgangsmodeller, så I kan forklare, hvorfor leverandørdata ikke ligger i samme område som HR.

Hvad er en god SharePoint document sets guide-regel for projekter?

Brug ét Document Set pr. projekt eller pr. leverance, ikke pr. dokumenttype. Lad Document Set bære “projekt-identiteten” (Projekt-ID, Kunde), og lad dokumenter bære “dokument-identiteten” (Dokumenttype, Status, Revision). Så kan I filtrere på tværs uden at opfinde nye mapper hver gang.

Optimering af SharePoint til Copilot: hvad er de første 3 ting vi gør?

1) Fjern “alle har adgang”-sites og segmentér med hubs/sites. 2) Indfør få, obligatoriske metadata på de vigtigste biblioteker. 3) Ryd op i “døde” projekter: sæt read-only og overvej arkiv, så Copilot primært søger i aktuelt, velstruktureret indhold.

Hvornår giver Microsoft 365 Archive mening?

Når I har afsluttede projekter, der skal gemmes (kontrakt/garanti/krav), men sjældent bruges. Arkivér hele sites efter en fast proces, i stedet for at lade dem ligge aktivt og vokse i storage og søge-støj.

Sådan kommer I i gang de næste 10 arbejdsdage

1. Dag 1–2: Udpeg 2 ejere pr. hub-område (Produktion, Projekter, Administration) og beslut, hvor eksterne må være.
2. Dag 3: Opret/justér hubs og flyt 3–5 pilot-sites ind under de rigtige hubs.
3. Dag 4–6: Vælg 3–6 metadatafelter til ét kritisk bibliotek (fx Projekter) og byg 3 standardviews.
4. Dag 7: Implementér Document Set for projekter og lav en simpel projektskabelon (site + bibliotek + views).
5. Dag 8–9: Sæt labels pr. site-type og gennemgå gæsteadgang. Luk for gæster i “forkerte” sites.
6. Dag 10: Sæt en fast månedlig kontrol: nye sites, sites uden ejere, eksterne brugere, delingslinks. Log resultaterne som en del af jeres governance.

Hvis I vil have det gennemført uden at stoppe driften, kan vi hjælpe med design, udrulning og løbende drift via /drift og Microsoft 365 governance på tværs af /compliance.