OS2sofd - Om OS2sofd: https://www.sofd.io/ - Brugervejledning: https://www.sofd.io/brugervejledning/ - Implementeringsdrejebøger: https://www.sofd.io/implementation-guides/ - Drejebog: OPUS-kommune: https://www.sofd.io/implementation-guides/opus-loen-integration/ - Drejebog: SD-kommune: https://www.sofd.io/implementation-guides/sd-loen-integration/ - Drejebog: Opgradering til 2026R2 (IDM): https://www.sofd.io/implementation-guides/opgradering-2026r2-idm/ - Brugerstyring: https://www.sofd.io/idm/ - Forudsætninger og forberedelse: https://www.sofd.io/idm/prerequisites/ - Processer og hændelser: https://www.sofd.io/idm/processes/ - Personinaktivering: https://www.sofd.io/idm/person-inactivation/ - Konfiguration: https://www.sofd.io/idm/configuration/ - Teknik: https://www.sofd.io/teknik/ - Arkitektur: https://www.sofd.io/teknik/arkitektur/ - Datamodel: https://www.sofd.io/teknik/datamodel/ - Login og SAML: https://www.sofd.io/teknik/login/ - API: https://www.sofd.io/teknik/api/ - OData (læsning): https://www.sofd.io/teknik/api/odata/ - REST-API: https://www.sofd.io/teknik/api/rest/ - Fremtidig API-udvikling: https://www.sofd.io/teknik/api/strategi/ - Batchkørsler: https://www.sofd.io/teknik/batchkoersler/ - Integrationer: https://www.sofd.io/integrationer/ - FK Organisation: https://www.sofd.io/integrationer/fk-organisation/ - IST Tabulex: https://www.sofd.io/integrationer/ist-tabulex/ - KMD I2: https://www.sofd.io/integrationer/kmd-i2/ - On-premise agenter: https://www.sofd.io/agents/ - Brugerkonto Agent: https://www.sofd.io/agents/user-account-agent/ - AD Writeback Agent: https://www.sofd.io/agents/ad-writeback-agent/ - AD Replikator Agent: https://www.sofd.io/agents/ad-replikator/ - AD indlæsningsintegration: https://www.sofd.io/agents/ad-indlaesningsintegration/ - OPUS indlæsningsintegration: https://www.sofd.io/agents/opus-indlaesningsintegration/ - Indlæsning af skoleelever: https://www.sofd.io/agents/skoleelev-indlaesning/ - OS2vikar - Brugerkonto Agent: https://www.sofd.io/agents/os2vikar-agent/ - Download: https://www.sofd.io/downloads/ - Ændringslog: https://www.sofd.io/changelog/ - Support og kontakt: https://www.sofd.io/support/ ## KMD I2 Integrationen til **KMD I2** sørger for, at brugerne i I2 automatisk følger medarbejdernes ansættelser, så adgangene ikke skal oprettes, rettes og lukkes manuelt. Kildedata kommer fra OS2sofd. Se [Datamodel](../../teknik/datamodel/) for begreberne person, tilhørsforhold og enhed. Selve tildelingen af roller i I2 kan enten udledes automatisk af organisation og stilling i OS2sofd, eller styres som rolletildelinger i OS2rollekatalog. De to modeller beskrives nedenfor, og kommunen vælger den, der passer til, hvordan adgangene ønskes administreret. Integrationen driftes som et centralt middleware-modul (se [Arkitektur](../../teknik/arkitektur/)). Der skal ikke installeres noget hos kommunen. ## Hvad integrationen gør Én gang i døgnet, om natten, sammenholdes medarbejderdata med det, der står i I2, og forskellene rettes: - **Nye medarbejdere oprettes** i de institutioner, de er ansat i, med de roller deres stilling eller rolletildeling giver. - **Ændringer slår igennem.** Skifter en medarbejder navn, mail, telefonnummer, stilling eller institution, opdateres adgangen i I2. - **Medarbejdere, der ikke længere skal have adgang, lukkes.** Det gælder både ved fratrædelse og ved skift til en anden del af organisationen. Fordi hver kørsel er en fuld sammenligning og ikke kun en behandling af dagens ændringer, rettes der også op på forskelle, der er opstået udenom integrationen. Der kan altså ikke opstå en situation, hvor en enkelt fejlet ændring bliver hængende for evigt. Kørslen sker om natten, fordi ansættelsesændringer sjældent skal slå igennem i I2 inden for samme time. Tidspunktet kan tilpasses efter behov. ## Hvilke oplysninger overføres Pr. medarbejder overføres: | Oplysning | Bemærkning | | --- | --- | | CPR-nummer | Bruges som nøgle, så medarbejderen kan genkendes i I2 | | Navn | Er der registreret et kaldenavn, bruges det. Alternativt kan I2 selv stå for navnene | | Arbejdsmail | Medarbejderens primære mailadresse. På skoleområdet kan skolemailen bruges | | Mobil- og arbejdstelefon | Medarbejderens primære numre. Har medarbejderen ingen, kan der sendes et fast omstillingsnummer i stedet | | Roller i I2 | Se afsnittet om de to modeller | | Start- og slutdato | Udledt af ansættelsen | Har en medarbejder flere ansættelser, der giver adgang til samme institution, får medarbejderen én adgang med alle de roller, ansættelserne tilsammen giver, og med den samlede periode. Der bliver altså ikke dubletter i I2. Fremtidige ansættelser sendes med deres fremtidige startdato, så adgangen ligger klar og aktiveres til tiden. ## To modeller for rolletildeling ### Model 1: styret af organisation og stilling i OS2sofd Institutionerne udpeges ved at markere de tilsvarende enheder i OS2sofd med institutionsnummeret fra I2. Rollen udledes derefter af medarbejderens stillingsbetegnelse ud fra et regelsæt, der opsættes sammen med kommunen. Det kan fx være, at stillingsbetegnelser der indeholder "leder" giver en lederrolle, og at øvrige giver en almindelig medarbejderrolle. Modellen understøtter også et niveau over institutionerne, typisk et dagtilbud eller et skoleområde. Markeres en enhed som et sådant område, får medarbejdere placeret der adgang til **alle** institutioner under området, med en rolle der kan være en anden end institutionsrollen. Det er mekanismen, der giver fx en dagtilbudsleder eller en områdeadministration adgang på tværs. Fordelen ved modellen er, at der ikke skal tildeles noget manuelt: adgangene følger automatisk af ansættelsen. Til gengæld forudsætter den, at stillingsbetegnelserne er tilstrækkeligt ensartede til, at der kan laves regler ud fra dem. ### Model 2: styret af rolletildelinger i OS2rollekatalog Her læses i stedet, hvem der er tildelt hvilke roller til hvilke institutioner, i OS2rollekatalog. Rolletildelingen bliver dermed en almindelig rolletildeling på linje med kommunens øvrige systemer, med den godkendelses- og attestationsproces der i forvejen anvendes, og den kan uddelegeres til fx en leder eller en institutionsadministrator. Fordelen er præcis kontrol og et fuldt overblik over, hvem der har adgang og hvorfor, samlet i rollekataloget. Til gengæld skal adgangene tildeles aktivt, og modellen forudsætter, at OS2rollekatalog er i drift. Modellen håndterer også et særskilt skoledomæne, hvis skolebrugerne og skolemailen er adskilt fra det administrative domæne. ## Når en medarbejder skal ud af I2 Kommunen vælger, hvad der skal ske, når en medarbejder ikke længere skal have adgang: - **Adgangen slettes** i I2. - **Adgangen får en slutdato**, så historikken bevares i I2, og adgangen lukker af sig selv. Valget gælder for hele kommunen og træffes i opstarten. Det kan ændres senere. ## Sikkerhedsnet Integrationen er bygget, så den ikke kan gøre skade på de dele af I2, den ikke er sat op til at håndtere: - **Institutioner, der ikke er taget med, røres ikke.** Der arbejdes alene i de institutioner, der er sat op i OS2sofd eller i rollekataloget. Derfor kan integrationen indføres institution for institution eller område for område. - **Adgange, institutionerne selv har oprettet i I2, røres ikke, når der ikke er et grundlag for dem.** Er medarbejderen ikke berettiget til adgang i den institution ud fra ansættelsen eller rolletildelingen, lades adgangen stå, også selvom den efter integrationens logik ellers skulle lukkes. Adgangen fremgår i stedet af rapporten, så den kan håndteres manuelt. Er medarbejderen derimod berettiget, overtages adgangen, så der ikke står en manuelt oprettet adgang som dublet ved siden af den automatiske. Fra det tidspunkt behandles adgangen som alle andre, og den bliver dermed også lukket, når grundlaget for den ophører. - **Prøvekørsel.** Integrationen kan sættes til at vise, hvad den *ville* gøre, uden at ændre noget i I2. Det bruges i idriftsættelsen, så resultatet kan godkendes, inden der ændres data, og igen hvis der senere laves større ændringer i opsætningen. ## Rapport Efter hver kørsel kan der sendes en mailrapport til en eller flere modtagere i kommunen. Den viser pr. institution: - hvilke medarbejdere der er oprettet - hvilke der er ændret, og hvad der blev ændret - hvilke der er lukket - hvilke manuelt oprettede adgange der blev sprunget over Rapporten er den nemmeste måde at holde øje med, at datagrundlaget er, som det skal være. Er der fx uventet mange lukninger en dag, er det typisk et tegn på, at noget mangler i opsætningen eller i data, og så kan det håndteres, inden det bliver et problem. ## Hvad kan tilpasses | Mulighed | Formål | | --- | --- | | Hvilke ansættelsesvilkår der medtages | Så fx kun fastansatte og timelønnede kommer med, og ikke øvrige tilknytninger | | Vikarer | Vikarer kan udpeges automatisk og få deres egen rolle i I2 | | Rollemodellen | Hvilke stillinger giver hvilke roller, både i institutionen og på områdeniveau | | Navne | Om integrationen vedligeholder navnene i I2, eller I2 selv slår dem op | | Fast telefonnummer | Bruges for medarbejdere uden registreret nummer | | Lukning | Sletning eller slutdato | | Rapportmodtagere | En eller flere mailadresser | | Kørselstidspunkt | Standard er en gang i døgnet om natten | ## Forudsætninger - **OS2sofd i drift** med den nødvendige datakvalitet: korrekte ansættelser med korrekt organisatorisk placering, retvisende stillingsbetegnelser, og primær mail og telefon registreret på medarbejderne. Datakvaliteten i I2 følger direkte datakvaliteten i OS2sofd. - **Adgang til KMD's I2 API.** Den bestilles hos KMD. Vær opmærksom på, at KMD kan have egne vilkår eller omkostninger forbundet med API-adgangen. - **Institutionsnumrene fra I2 skal være kendte**, så institutionerne kan kobles sammen med organisationen. - **En besluttet rollemodel**: hvilke medarbejdere skal have hvilke roller i I2. Det er typisk den del, der kræver mest af kommunen i opstarten, og den laves i fællesskab. - **Ved model 2**: OS2rollekatalog i drift.