No-code-apps

En no-code-app kan samle en afgrænset intern opgave i formularer, poster og visninger. Vælg opgaven først, og undersøg derefter data, adgang og ansvar for drift. At en app er hurtig at bygge, gør den ikke nødvendigvis enkel at overtage.

Afgør, om opgaven passer til en app

Beskriv, hvem der opretter en post, hvem der arbejder videre med den, og hvilket resultat brugerne skal kunne se. En intern oversigt over udstyr og reparationer kan være en kandidat, hvis medarbejdere skal registrere fejl og følge status.

Lad en ansvarlig person træffe beslutning om reparation og udgift. Ændringer af betalingsoplysninger eller væsentlige afgørelser om personer kræver en særskilt vurdering.

Afgræns den første version. Skriv også, hvem der retter en forkert post, og hvordan arbejdet fortsætter, hvis appen er utilgængelig.

Sammenlign platforme på den samme opgave

Microsoft Power Apps rummer to forskellige udgangspunkter. En modelbaseret app bygger på Dataverse-tabeller og relationer og kræver et passende miljø, rettigheder og licens. En canvas-app giver større frihed i brugerfladen og kan bruge andre datakilder.

Deling af appen afgør ikke alene adgangen til data og forbindelser. Undersøg Power Apps, hvis teamet kan placere både datamodel og administration i den relevante Microsoft-opsætning.

Google AppSheet bør vurderes på den konkrete opgave og de datakilder, teamet vil bruge. Bed om at få vist, hvordan appen håndterer adgang, data og følsomme handlinger, og kontrollér de aktuelle muligheder i produktets dokumentation. Sørg også for, at adgangen til datakilden passer til brugernes behov.

Airtable bør vurderes på den konkrete opgave og de adgangsbehov, teamet har. Bed om at få vist, hvordan brugere får adgang til appen og de tilknyttede data, og kontrollér de aktuelle muligheder og vilkår i produktets dokumentation.

Platformene er kandidater til vurdering, ikke en rangliste. Bed om at få den samme opgave vist med de roller og datakilder, I faktisk har brug for.

Match appens form til arbejdsgangen

En modelbaseret app passer særligt til datatunge, procesdrevne opgaver, hvor brugerne bevæger sig mellem relaterede poster. Formularer, visninger, diagrammer og dashboards kan sammensættes omkring tabellerne. Relationer mellem tabeller gør det muligt at navigere mellem poster og undgå unødvendig gentagelse af data.

I en modelbaseret app bestemmer de valgte komponenter i høj grad brugerfladen, mens en canvas-app giver udvikleren kontrol over layoutet. Modelbaserede apps har en ensartet, responsiv brugeroplevelse på tværs af enheder. Det kan være relevant, hvis flere interne apps skal opleves på en genkendelig måde.

Med løsninger kan modelbaserede apps flyttes mellem udviklings-, test- og produktionsmiljøer. Det bør indgå i platformsvurderingen, hvis appen skal gennem flere miljøer, før den bliver tilgængelig for brugerne.

Fordele og ulemper ved modelbaserede vs. canvas-apps i Power Apps

Se appadgang og dataadgang hver for sig

I Power Platform autentificeres brugere med Microsoft Entra ID, og licensering er et første adgangskrav til Power Apps-komponenter. Hvem der må oprette apps og flows, styres af sikkerhedsroller i miljøet. Hvem der kan se og bruge en app, styres også af, at appen deles med brugeren.

Deling fungerer forskelligt for app-typerne: Canvas-apps deles direkte med en bruger eller en Microsoft Entra-gruppe, men adgangen er stadig underlagt Dataverse-sikkerhedsroller. Modelbaserede apps deles via Dataverse-sikkerhedsroller. Miljøer kan fungere som sikkerhedsgrænser, når forskellige apps eller data kræver forskellige rammer.

Forbindelser er endnu et led, når en app bruger connectors. De konkrete forbindelser, tilhørende legitimationsoplysninger og serviceberettigelser afgør, hvilke tilladelser der gælder. Vurder derfor ikke kun, hvem der kan åbne appen, men også hvilke forbindelser den bruger, og hvilke tilladelser de medfører.

Dataverse kan understøtte både en enkel sikkerhedsmodel med bred adgang og mere detaljerede modeller med adgang til bestemte poster eller felter. Omfanget af styringen bør passe til data og arbejdsgang; en mere detaljeret model er ikke automatisk nødvendig for enhver intern app.

Beslut på data, adgang og ejerskab

Skriv, hvad én post betyder, og hvordan den forbindes med andre poster. I eksemplet kan udstyr og reparationer være forskellige typer poster.

Beslut, hvem der kan oprette, læse, rette, slette og eksportere dem. Prøv rettigheder med almindelige brugerkonti, og kontrollér også adgang til datakilden.

Hvis appen behandler personoplysninger, skal formålet være klart, oplysningerne begrænses til det nødvendige, og adgangen beskyttes. Registrér desuden appens ejer, datakilder, forbindelser og ansvar for fejl. Vælg først en løsning, når teamet kan forklare, hvordan den afgrænsede opgave fungerer, og hvem der kan vedligeholde den.

Gør databeskyttelse til en del af afgrænsningen

Databeskyttelsesprincipperne omfatter lovlighed, rimelighed og gennemsigtighed. Formålet med indsamlingen skal være klart og sagligt, og senere brug må ikke være uforenelig med det formål. Det giver et konkret grundlag for at vurdere, om en opgave og dens oplysninger hører hjemme i appen.

Dataminimering betyder, at både behandling og opbevaring begrænses til det nødvendige for formålet. Oplysninger skal holdes ajour, og urigtige oplysninger skal slettes eller berigtiges. Når behandling ikke længere er nødvendig, skal oplysninger anonymiseres eller slettes.

Integritet og fortrolighed betyder, at oplysninger ikke må komme til uvedkommendes kendskab, gå tabt eller blive beskadiget. Brug principperne til at afgrænse, hvilke oplysninger appen behøver, hvem der skal kunne arbejde med dem, og hvornår de ikke længere skal opbevares.

Checkliste til sikkerhed og databeskyttelse i no-code-apps