En vidensbase i moderne SharePoint

Det moderne SharePoint har ikke den gamle wikisideskabelon, og en wiki er ofte netop det, der er brug for. Det, folk kalder en wiki, bruges i praksis næsten altid som en vidensbase, så det er det, jeg bygger.

Det er fire dele, der sættes sammen: et kommunikationswebsted, en indholdstype, et termsæt til kategorierne og en sideskabelon. Resten er indstillinger og vaner, og de er lige så vigtige.

Hvorfor wikien er væk#

Wikisider findes som indholdstype på publiceringswebsteder, men ikke på kommunikationswebsteder. En moderne side med webdelene Text og Markdown dækker mange af de samme behov, men wikisyntaksen er væk. Kun links med dobbelte kantede parenteser virker stadig i Text (Microsoft).

Det er ikke kun en mangel i det nye. Wikisider er klassiske, brugeroprettede sider, og dem er Microsoft ved at lukke:

• Fra 1. marts 2027 kan der ikke oprettes nye publiceringswebsteder, og skabelonen Enterprise Wiki hører med til dem.
• Fra 1. oktober 2028 bliver klassiske brugeroprettede sider skrivebeskyttede for alle tenants, wikisider og webdelssider med. Der kan hverken oprettes eller redigeres klassiske sider.
• Det, der allerede står der, bliver ikke slettet. Det kan stadig læses (Microsoft).

Teams har haft sin egen wiki, men dens sider blev gemt som løse filer i SharePoint og kunne ikke deles inde i SharePoint. Den er siden udfaset til fordel for OneNote. En vidensbase, der skal leve, hører hjemme på et SharePoint-websted.

Hvad folk faktisk skal bruge#

Når nogen beder om en wiki, er det sjældent selve wikien, de mangler. De vil have ét sted, hvor svaret på et spørgsmål står, så det kan findes igen. Det kræver fire ting:

• Artikler, der ligner hinanden i opbygning, så de er lette at skimme.
• Kategorier, man kan bladre i, uden at skulle kende artiklens navn.
• En søgning, der finder artiklerne, og som kan indsnævres på kategori.
• En person, der svarer for, at artiklen stadig passer.

Det er en vidensbase, og alle fire ting kan bygges i moderne SharePoint. Det samme er Microsofts anbefaling, efter at Viva Topics lukkede den 22. februar 2025: brug SharePoint til at udgive og organisere viden, så den kan findes i Microsoft Search og bruges af Copilot (Microsoft).

Tre niveauer#

Tre niveauer er nok for de fleste. Er der brug for både kategorier og underkategorier, kan strukturen udvides, men den enkle udgave er som regel den, folk faktisk bruger.

• Niveau 1: Forsiden. Det overordnede emne, fx Teknik.
• Niveau 2: Kategorisider. Emnet delt op i kategorier, fx Wi-Fi.
• Niveau 3: Indholdssider. Siderne med selve indholdet.

Kun niveau 3 er artikler. Niveau 1 og 2 er sider, der peger videre, og de skal ikke skrives som artikler. Det har betydning for resten af opbygningen, for det er artiklerne, der får indholdstypen og kategorien.

Fire dele#

Delene bygges én gang pr. websted. Derefter laver forfatterne bare nye sider ud fra skabelonen, og læserne ser kun siderne.

Den røde tråd er kolonnen Kategori. Den kommer fra termsættet, sidder på indholdstypen, følger med ind i skabelonen og er det, kategorisiderne senere filtrerer på.

Opret kommunikationswebstedet#

Opret et kommunikationswebsted (Communication site) med den tomme skabelon, Blank (Microsoft). Et kommunikationswebsted er bygget til at blive læst af mange og skrevet af få, og det er netop vidensbasens form. Hold webstedet til vidensbasen alene, så rettigheder, navigation og søgning ikke deles med andet.

Rettighederne følger tre grupper: Visitors læser (permission level Read), Members redigerer (Edit), og Owners har fuld kontrol (Full Control) (Microsoft). Mere om, hvem der skal i hvilken, længere nede.

Opret indholdstypen#

Indholdstypen (content type) er det, der gør en artikel til noget andet end en side. Den bygges på Site Page (på dansk Webstedsside), så den er en side med alt, hvad en side har, og kan gemmes i biblioteket Site Pages sammen med resten.

Opret den i Site settings på vidensbasens eget websted, under Site content types, med Site Page som overordnet indholdstype. Navngiv den efter det, den bruges til, fx Vidensartikel.

Den kan også oprettes i Content type gallery i SharePoint admin center, men så ligger den i content type hub’en på /sites/ContentTypeHub (Microsoft). Siden 2021 skubbes indholdstyper derfra ikke længere ud til webstederne af sig selv, så til ét websted er indholdstypen på webstedet selv det enkleste. Hvorfor det er sådan, og hvad man gør, hvis den alligevel skal komme fra hub’en, står i Indholdstyperne fra hub’en kom ikke længere af sig selv og Hent en indholdstype fra content type hub’en med Power Automate.

Opret termgruppe og termsæt#

Kategorierne ligger i termlageret (Term store), ikke i en valgkolonne. En valgkolonne skal rettes på kolonnen hver gang, der kommer en ny kategori. Et termsæt rettes ét sted, og kolonnerne følger med (Microsoft).

I SharePoint admin center findes termlageret under Content services → Term store (Microsoft). Til globale termer kræves rollen SharePoint-administrator eller højere i Microsoft 365, eller Term Store Administrator i SharePoint (Microsoft).

1. Termgruppe (valgfrit). En gruppe er en samling termsæt med samme sikkerhedskrav. Kun dem, der har Contributor på gruppen, kan oprette og rette termsæt i den. En egen gruppe til vidensbasen giver mening, når andre end administratorerne skal vedligeholde kategorierne.
2. Termsæt. Opret et termsæt, fx Kategorier, og læg kategorierne ind som termer. Termer kan have synonymer og kan lægges i flere niveauer, men for en vidensbase med tre niveauer er en flad liste som regel nok.
3. Indsendelsespolitik (Submission policy). Under Usage settings sættes den til Open, så nye kategorier kan tilføjes, efterhånden som de opstår. Med Closed kan kun dem med rettighed til termlageret tilføje termer, med Open kan brugerne tilføje dem direkte fra kolonnen.
4. Tilgængelig til tagging (Available for tagging). Skal være slået til. Ellers er termsættet ikke synligt for de fleste.
5. Ejer og kontakt. Sæt en ejer og en kontakt-mailadresse på termsættet. Kontakten er den, brugerne kan sende ønsker om nye termer til.

Et åbent termsæt kan med tiden få termer, der betyder det samme, fx både Wifi og Wi-Fi. Det kan rettes bagefter. Slås termerne sammen, opdateres de artikler, der brugte dem (Microsoft). Ejeren af termsættet bør derfor kigge nye termer igennem med jævne mellemrum.

Lav kolonnen og læg den på indholdstypen#

Lav en ny webstedskolonne af typen Managed metadata, der peger på termsættet, og læg den på indholdstypen. Webstedskolonner oprettes i Site settings under Site columns, og det kræver, at man er Site Collection Administrator (Microsoft).

Tre indstillinger gør forskel:

• Peg på hele termsættet (Use a managed term set). Peges der i stedet på en enkelt term, viser kolonnen kun den og de termer, der ligger under den.
• Tillad nye værdier (Allow Fill-in). Det er først her, at det åbne termsæt får virkning. En åben indsendelsespolitik hjælper ikke, hvis kolonnen ikke tillader, at der skrives nye værdier. Er termsættet lukket, kan Allow Fill-in slet ikke slås til.
• Ét valg. Tillader kolonnen flere værdier, kan biblioteket ikke sorteres efter den. En artikel hører hjemme i én kategori, og så er der heller ikke tvivl om, hvilken kategoriside den skal stå på.

Markér også kolonnen som påkrævet på indholdstypen, så ingen artikel kommer ind uden kategori.

Udover Kategori tilføjer jeg to kolonner til indholdstypen: Ejer (en person) og Gennemgås senest (en dato). De bruges i afsnittet om at holde vidensbasen i live.

Føj indholdstypen til biblioteket#

Indholdstypen skal ind i biblioteket Site Pages, ellers kan en ny side ikke få den. Fremgangsmåden er den samme som for en liste (Microsoft):

1. Åbn Site Pages → Library settings → Advanced settings og sæt Allow management of content types til Yes.
2. Vælg Add from existing site content types og tilføj Vidensartikel.
3. Vælg Change new button order and default content type. Sæt Vidensartikel som nummer 1, og fjern fluebenet under Visible ved de indholdstyper, der ikke skal bruges.

På den måde får nye sider i biblioteket kolonnen Kategori, og biblioteket kan vises med den.

Lav sideskabelonen#

Sider oprettes kun i biblioteket Site Pages (Microsoft), så skabelonen skal også bygge på artiklernes indholdstype.

1. Opret en side med den nye indholdstype. Tjek i biblioteket, at siden faktisk har Vidensartikel og ikke bibliotekets gamle standardtype.
2. Byg sidens struktur: overskrifter til det, en artikel i vidensbasen altid skal indeholde, og tekst under hver, der fortæller, hvad der skal stå.
3. Åbn pilen ved siden af Save and exit og vælg Save as template. Skabelonen dukker op i galleriet under Saved on this site (Microsoft).
4. I skabelongalleriet vælges Set default selection på skabelonen. Så er den valgt fra start, når nogen vælger + New → Page. Det gælder alle på webstedet.

Skabelonen ligger som en kladde i mappen Templates i biblioteket, og den bliver ikke udgivet. Tre begrænsninger er værd at kende:

• En ændring i skabelonen rammer ikke eksisterende sider. Retter man strukturen senere, skal de sider, der allerede findes, rettes for hånden.
• Skabelonen kan ikke bruges på andre websteder. Den kan heller ikke laves ud fra en forside.
• Sideskabelonen skal bygge på indholdstypen. Ellers får nye sider bibliotekets standardindholdstype og mangler kategorikolonnen.

I Graph-API’ets beskrivelse af en sideskabelon (i beta) har skabelonen en egen egenskab til indholdstypen (Microsoft), så det er skabelonen selv, der bærer typen. Derfor er det værd at tjekke siden, før den gemmes.

Lav kategorisiderne#

En kategoriside beskriver, hvad kategorien dækker, og giver overblik, når der er mange sider i den. Den skal have et kort afsnit øverst: hvad hører hjemme her, og hvad hører ikke. Under det kommer listen over siderne i kategorien.

Kategorisiderne laves med den almindelige Site Page, ikke med Vidensartikel. Ellers ville de have en kategori og dukke op i de lister, de selv skal vise.

Listen laves med webdelen Highlighted content. Webdelen viser indhold dynamisk, og den kan hente det fra et bibliotek, fra webstedet, fra flere websteder eller fra alle (Microsoft). Indstillingerne til en kategoriside:

• Source: This site, med typen Pages. Så hentes siderne fra webstedet gennem søgningen.
• Filter: Managed property. Vælg den egenskab, SharePoint har lavet til kolonnen Kategori, og sæt Contains til kategoriens navn. Navnet på egenskaben begynder med owstaxId efterfulgt af kolonnens interne navn, fx owstaxIdKategori. Mønstret i navnet er det, Microsoft bruger for en kolonne med termer i søgevejledningen (Microsoft). Selve filtret, Managed property med Contains og termens navn, viser Microsoft for enterprise keywords (Microsoft), ikke for en egen kolonne.
• Sort by: Managed property ascending på titlen, hvis listen skal stå alfabetisk. Standarden er Most recent. Ved en lang liste kan Most viewed være et bedre valg til en kategoriside.
• Layout: List eller Compact til lange kategorier. Cards fylder mere, end en liste over vejledninger har brug for.

Peger webdelen i stedet på biblioteket Site Pages som kilde (The page library on this site), bruges en CAML-forespørgsel, og så er det ikke søgningen, der leverer siderne. Her er begrænsningerne:

• Der kommer højst 200 sider med. Er der flere i en kategori, skal kategorien deles.
• En ny side dukker ikke op med det samme, når kilden er søgningen. Søgebaserede kilder viser kun indhold, der er indekseret, og det kan tage flere minutter efter, at siden er udgivet (Microsoft). Hvad der ellers kan holde en side ude af indekset, står i Når søgningen i SharePoint Online ikke finder det.
• Filtret gælder navnet på termen. Omdøbes kategorien i termlageret, skal webdelen rettes med.
• Caching. På sider, mange kommer forbi, anbefaler Microsoft Group-level caching på webdelen, så søgningen ikke køres for hver besøgende (Microsoft).

Lav forsiden#

Opret hurtige links (webdelen Quick links) på forsiden til alle kategorisiderne. Forsiden er niveau 1, og den bør kunne læses uden at rulle: en kort tekst om, hvad vidensbasen er til, og et link til hver kategori. En søgeboks øverst er en god genvej for dem, der kender ordet, men ikke kategorien.

Menuen på webstedet laves med hånden. De gamle navigationsmuligheder, der byggede menuen af termer (managed navigation), findes ikke i moderne websteder (Microsoft), så kategorierne i termlageret styrer ikke menuen. De kategorisider, der kommer til, skal lægges ind i menuen og i Quick links som en del af at oprette dem.

Menuen kan have op til tre niveauer, enten som kaskade eller som megamenu (Microsoft). På et kommunikationswebsted står der som standard Documents, Pages og Site Contents, og Microsoft anbefaler at slette dem, når webstedet åbnes for læserne, fordi læserne bryder sig om emnet og ikke om typen. Hold menuen til de kategorier og få links, der faktisk bruges. Der er teknisk en grænse på 500 punkter i navigationen, men Microsoft anbefaler højst 100 (Microsoft). Skal menuen ændres med script, står det i Navigationen på et SharePoint-websted med REST.

Søgning og visninger#

Webstedets søgeboks søger som udgangspunkt kun på webstedet, og søgeresultaterne kan indsnævres på de metadata, artiklerne har. Det er en af grundene til at bruge termer: søgningens filterpanel kan tilbyde kategorierne som filtre (Microsoft). Det kræver, at webstedet må vises i søgeresultater, hvilket er standard, men som en site owner kan slå fra (Microsoft).

Biblioteket Site Pages er forfatternes arbejdsbord, og det bør have to visninger ud over standardvisningen:

• Alle artikler. Grupperet på Kategori, med kolonnerne Ejer, Gennemgås senest og Modified.
• Skal gennemgås. Filtreret på Gennemgås senest mindre end [Today] og sorteret med den ældste dato først.

Brug en kolonne til kategorien frem for mapper. Mapper er slået fra i biblioteket som standard, og en side kan kun ligge i én. Hvorfor kolonnen er bedre, står i Mapper i biblioteket med sider i SharePoint.

Rettigheder og ejerskab#

Rettighederne følger de tre grupper fra webstedet. I en vidensbase er der mange læsere og få forfattere, og det er der to måder at gøre noget ved:

• Enkel. Forfatterne lægges i Members, læserne i Visitors. Alle, der kan redigere på webstedet, kan så også oprette og rette artikler.
• Stram. Sæt Members til Read på biblioteket Site Pages (Microsoft), og giv en gruppe med forfattere Edit på biblioteket. Så er det kun dem, der kan skrive.

Skal en artikel godkendes, før den vises, kan siderne sendes igennem et Power Automate-flow, der beder godkenderne om svar, hver gang en side oprettes eller rettes (Microsoft). Det koster tid pr. artikel, så det er først værd det, når fejl i artiklerne er dyre.

Ejerskab er to ting. Webstedet bør have mindst to Owners, så det ikke hænger på én person. Og hver artikel skal have en ejer i kolonnen Ejer, helst en person med navn og ikke en gruppe. Til webstederne som helhed har Microsoft tre politikker, der kan bruges sammen: ejerskabspolitikker, så hvert websted har ansvarlige ejere, politikker for inaktive websteder og periodisk bekræftelse af, at webstedet stadig er nødvendigt (Microsoft).

Hold den i live#

En vidensbase mister værdi hurtigere, end den bliver skrevet. En gammel artikel, der ser rigtig ud, er værre end ingen artikel. Derfor har indholdstypen kolonnerne Ejer og Gennemgås senest, og derfor har biblioteket visningen Skal gennemgås.

En artikel gennemgår fire trin. Når en forfatter vælger Save and exit, er siden en kladde, som kun redaktører kan se. Når den udgives med Publish, kan læserne finde den (Microsoft). Når datoen i Gennemgås senest nærmer sig, tjekker ejeren siden. Enten er den rigtig, og så udgives den igen med Republish og en ny dato. Eller den er forældet, og så slettes den med Delete page i Page details. Det er site owners og administratorer, der kan slette en side (Microsoft).

Læserne kan hjælpe. Nederst på en side kan de skrive kommentarer og trykke Like, og siden viser, hvor mange gange den er set (Microsoft). Webstedets statistik viser, hvilke sider der bliver læst, og hvilke der ikke bliver (Microsoft). En side, ingen læser, er enten dårligt placeret eller overflødig.

Faldgruber#

• Lokale termsæt kan ikke vælges fra den moderne kolonneoprettelse. Den moderne dialog viser kun globale termsæt. Et lokalt termsæt på webstedet kræver, at kolonnen oprettes fra de klassiske indstillinger, hvor man vælger Customize your term set (Microsoft). Et lokalt termsæt kan kun bruges i den site collection, det er oprettet i, og dets termer foreslås ikke i kolonnen Enterprise Keywords (Microsoft).
• Sideskabelonen skal bygge på indholdstypen. Ellers får nye sider bibliotekets standardindholdstype og mangler kategorikolonnen.
• En skabelon følger ikke med til et andet websted. Et moderne websted kan ikke gemmes som skabelon (Microsoft). Skal vidensbasen bygges flere steder, skal delene sættes op på hvert websted, eller sættes op med script.
• Et åbent termsæt vokser. Giv det en ejer, og kig nye termer igennem.
• Listerne på kategorisiderne følger søgeindekset. En side er ikke på listen, før den er indekseret.
• Gamle wikisider flyttes ikke af sig selv. Findes der klassiske wikisider, der skal med, peger Microsoft på guiden til at omdanne klassiske sider til moderne og på PnP PowerShell (Microsoft). Overvej først, om siderne skal med. En vidensbase er en god anledning til at lade det forældede blive tilbage.