Rollebaserede tilladelser til sociale medier: Sådan sætter du 6 roller op i dit bureau

Rollebaseret adgangskontrol (RBAC) betyder, at rollen bestemmer, hvad nogen kan, ikke personen. Til et social media-team har du brug for seks roller, ikke tyve: creator, editor, approver, publisher, analyst, admin. Afgræns hver person til bestemte klientkonti, så ingen ser arbejde, der ikke er deres, og hold så styr på, hvem der godkendte hvad.

Bureauer fejler typisk i én af to retninger. Enten deler alle ét login, eller også venter hvert opslag på ejeren. Begge dele kan fikses på en eftermiddag.

TLDR: Seks roller, afgrænset pr. klient, med godkendelser som portvagt og alle sign-offs på skrift. Undtagelser pr. person er det, der gør hele modellen umulig at vedligeholde.

De seks roller, der dækker næsten alle teams

Rolle	Kan	Kan ikke
Creator	Udkast til opslag, uploade materialer	Publicere, forbinde konti
Editor	Redigere ethvert udkast i scope, sende til godkendelse	Godkende eget arbejde
Approver	Godkende, afvise, kommentere på udkast	Redigere forbundne konti
Publisher	Planlægge og publicere godkendte opslag	Godkende, tilføje brugere
Analyst	Læse tal, eksportere rapporter	Røre ved indhold
Admin	Forbinde konti, administrere brugere og roller	Intet, så hold det til to personer

To regler forhindrer, at det hele rådner. Ingen godkender eget arbejde, og admin ligger hos præcis to personer, så der altid er en backup og aldrig et udvalg.

Modstå tilladelser pr. person. I det øjeblik du har "Sarah, men hun må også godt publicere om torsdagen", har du et setup, ingen kan revidere seks måneder senere. Håndter undtagelsen med en midlertidig rolleskift, og sæt den så tilbage.

Scope: den del, bureauer får galt i halsen

En rolle alene er ikke nok. En creator på Klient A må ikke kunne se Klient B. Det er scope, og det er det første, der knækker, når et bureau vokser ud af ét fælles login.

Scope på tre akser:

• Klient eller brand. Den hårde grænse. Contractors får præcis én.
• Kanal. Nogen kan eje Instagram og TikTok uden at røre LinkedIn-virksomhedssiden.
• Fase. Adgang til udkast betyder aldrig adgang til at publicere.

Det kræver ægte adskillelse, ikke et filter. Hvis en contractor kan skifte kontovælgeren og havne i en anden klients indbakke, har du en standardvisning frem for isolation. Workspaces er sådan Mydrop trækker den linje: hver klient er sit eget rum med egne medlemmer, kalender og forbundne konti.

Klient-stakeholders er et andet problem. De fleste af dem bør slet ikke være brugere. En klientportal uden login lader dem gennemgå og godkende eget indhold uden en plads, en adgangskode eller et tilladelsesniveau, du vedligeholder for evigt, når projektet er slut.

Godkendelser er portvagten, ikke karrierestigen

Tilladelser bestemmer, hvem der kan handle. Godkendelser bestemmer, hvornår. Hold de to adskilt, ellers begynder du at gøre folk til admins bare for at frigive et fredagsopslag.

Styr efter risiko, ikke efter jobtitel:

Indhold	Reviewere
Skabelonbaserede, tilbagevendende opslag	Én editor
Ny kampagne eller ny påstand	Klient eller brand-ansvarlig
Reguleret, juridisk eller krise	Navngiven juridisk reviewer, ingen fallback

Giv de to første rækker en fallback-approver, så en ferie ikke stopper publiceringen. Den tredje række skal reelt blokere. Godkendelsesworkflows holder opslaget, indtil sign-offs lander, hvilket gør "godkendt" og "publiceret" til én registrering i stedet for to lister, du afstemmer i hånden.

Hvad din audit-log skal registrere

"Hvem ændrede det her?" dukker altid op på det værst tænkelige tidspunkt, og en log, der kun gemmer den nuværende tilstand, kan ikke svare på det.

Registrer fem ting pr. handling:

1. Hvem gjorde det, som en navngiven person og aldrig en fælles konto.
2. Hvilken rolle de havde på det tidspunkt. Folk skifter roller, og en log, der først finder rollen ved læsning, omskriver stille og roligt historien.
3. Hvad der ændrede sig, med den tidligere version stadig læsbar.
4. Hvornår, med tidszone.
5. Hvilken godkendelse det blev publiceret under.

To praktiske regler. Gem godkendelsesregistreringer længere end driftslogs, for det er godkendelsen, nogen reelt spørger efter. Og gør dem søgbare på klient og datoperiode, for sådan ankommer hver audit-forespørgsel.

At sammenligne leverandører på det her er nemt: Bed hver enkelt om at trække godkendelseshistorikken frem for et bestemt opslag fra tre måneder siden. Enten findes den i demoen, eller også gør den ikke.

Hvad du skal tjekke, før du køber

De funktioner, der adskiller en ægte tilladelsesmodel fra en indstillingsside:

• Roller definerbare pr. klient, ikke én global rolle pr. bruger.
• Isolation, der overlever kontovælgeren, testet med et rigtigt contractor-login.
• Godkendelsesrouting med navngivne reviewere og en defineret fallback.
• Eksporterbar godkendelseshistorik for et enkelt opslag.
• Revieweradgang uden en plads, så klientens sign-off ikke koster en licens.
• SSO og directory-provisioning, hvis IT ejer din brugerliste. De fleste sociale værktøjer reserverer det til enterprise-planer, så spørg i første samtale frem for ved kontraktfasen.

Planable og Sprout Social håndterer begge godkendelser i flere trin med definerede roller. Mydrop samler per-klient-workspaces, roller, kommentarer direkte på udkastet, godkendelsesporte og review-linket uden login i ét system, hvilket er den kombination, bureauer oftest samler fra to separate værktøjer. For resten af det operationelle setup omkring det, dækker social media-bureauer den bredere stack.

Sæt det op i denne uge

Tre trin, i denne rækkefølge:

1. List enhver, der kan publicere i dag. Inkluder tidligere contractors og det fælles login. Listen er altid længere, end nogen forventer.
2. Giv hver person én enkelt rolle og ét enkelt klient-scope. Ingen undtagelser i første omgang.
3. Flyt klient-stakeholders over på review-links og slet deres brugerkonti.

Sæt en 90-dages påmindelse i kalenderen til at køre trin et igen, for forældet adgang er den fejl, der kommer tilbage hver gang. Du kan starte gratis og have roller og klient-workspaces kortlagt, før næste kampagne går i gang.