Writeback i Power BI: 4 veje fra rapport til handling

Af /

Writeback i Power BI betyder, at brugeren skriver data fra rapporten: en kommentar til en afvigelse, en rettelse af budgettet eller en godkendelse. Det lyder som en lille funktion, men det ændrer rapporten fra noget, man læser, til noget, man handler i. Der er fire veje i dag, og de adskiller sig mest på ét spørgsmål: hvor ender data?

Resumé og konklusion

  • Writeback er ikke en indstilling i Power BI. En semantisk model i import skrives ikke til. Writeback kræver en komponent, der skriver et andet sted hen, og ændringen ses først efter næste opdatering.
  • Translytical task flows er generelt tilgængelige, men kræver Fabric. Knappen kalder en User data function, som skal ligge i et workspace på en Fabric-kapacitet.
  • Power Apps og Power Automate kan skrive direkte i Business Central. Business Central-connectoren er Premium i begge, og visualet sender højst 1.000 rækker fra rapporten.
  • Skriv tilbage i kildesystemet, ikke i en sidedatabase. Business Central har rettigheder, bogføringsregler og revisionsspor. En sidedatabase bliver hurtigt en ekstra sandhed.
  • oneBC365 tilbyder ikke writeback i dag. Løsningen er bygget til læsesiden. Vejen til handling er et deep-link fra rapporten til den rigtige side i Business Central.

Hvad writeback i Power BI er, og hvad det ikke er

En Power BI-rapport læser fra en semantisk model. I import-tilstand er modellen en kopi, der fyldes ved hver opdatering. Den kan ikke skrives til. Writeback er derfor altid to ting: noget i rapporten, der samler input, og et andet system, der gemmer det.

Typiske ønsker hos en Business Central-kunde er en kommentar til en budgetafvigelse, en justering af næste måneds budget, en markering af debitorer til opfølgning eller en godkendelse af et indkøbsforslag. Fælles for dem er, at en beslutning tages på baggrund af rapporten og skal registreres et sted, hvor den har konsekvens.

Én ting skal være klar fra start. Skriver brugeren til en kilde, som en import-model læser, ses ændringen først efter næste opdatering. På Power BI Pro er det op til otte planlagte opdateringer om dagen. Microsoft skriver selv, at ændringer fra User data functions ses med det samme i Direct Lake og DirectQuery, men i import-rapporter først efter refresh.

Fire veje til writeback i Power BI

1. Translytical task flows

Translytical task flows blev generelt tilgængelige i april 2026. En knap i rapporten kalder en User data function, en Python-funktion i Fabric. Parametrene kommer fra knap-, liste- eller inputudsnit eller fra felter og mål i rapporten. Funktionen kan tilføje, rette og slette rækker i en Fabric SQL database, et warehouse eller filer i en lakehouse, og den kan kalde et eksternt API. Det står i Microsofts oversigt over translytical task flows.

Kravene er konkrete. User data functions skal ligge i et workspace på en Fabric-kapacitet, og en prøvekapacitet kan bruges til at teste. Funktionen skal returnere tekst, et kald må højst køre 240 sekunder, og parametrene må samlet fylde 4 MB. Knapperne kan først afprøves, når rapporten er publiceret, og de peger på et bestemt workspace, så de skal rettes manuelt ved flytning mellem workspaces. Microsofts oversigt nævner ikke licenskrav til rapportens læsere, så tjek det i jeres tenant.

2. Power Apps-visualet

Power Apps-visualet indlejrer en canvas-app i rapporten. Appen får rapportens aktuelle udsnit gennem objektet PowerBIIntegration, højst 1.000 rækker, og skriver videre via sine connectors, fx til Business Central eller Dataverse. Appen kan ikke sende data tilbage til rapporten, den skal deles separat, og ifølge Microsofts dokumentation af visualet understøttes den ikke i “embed for your customers” eller Power BI Report Server.

3. Power Automate-visualet

Power Automate-visualet er en knap, der starter et flow med rapportens udsnit som input. Flowet oprettes inde fra rapporten, og brugerne skal have ret til at køre det. Visualet behandler højst 1.000 poster og understøttes ikke i embedded analytics, Publish to web eller eksport.

Med Business Central-connectoren kan flowet bruge Create record (V3), Update record (V3) og Run action (V3). Connectoren er Premium i Power Automate og Power Apps og har en grænse på 300 kald pr. forbindelse pr. 60 sekunder.

4. Writeback-visuals fra tredjeparter

I AppSource findes visuals, der er bygget til writeback, typisk til budgetter, prognoser og kommentarer. De er ofte hurtige at komme i gang med og har en brugerflade, der ligner et regneark. Spørgsmålene er de samme hver gang: hvor gemmes data, i jeres tenant eller hos leverandøren, hvordan logges ændringer, og kan data komme tilbage i Business Central? Prismodellerne varierer, og jeres Power BI-administrator styrer, hvilke visuals der må bruges.

Grafikken herunder sammenligner de fire veje på det, der typisk afgør valget.

Writeback i Power BI: fire veje sammenlignet på destination, krav og grænser
Fire veje fra rapport til handling. Licenskrav skal altid tjekkes i jeres egen tenant.

Hvor data skal skrives hen

Det vigtigste valg er ikke værktøjet, men destinationen. Hovedreglen er at skrive tilbage i kildesystemet. En budgetrettelse hører til i Business Central, hvor finansbudgettet ligger. En opfølgning på en debitor hører til på debitoren. En periodisering hører til i en kladde, som bogholderen gennemser og bogfører.

Grunden er enkel. Business Central har rettighedssæt, valideringer, bogføringsregler og ændringslog. En sidedatabase har intet af det, medmindre nogen bygger det. Og det, der skrives i en sidedatabase, findes ikke i Business Central. Så har I to sandheder, og den ene kan ikke bogføres.

Et godt mønster er at skrive til et venteområde i Business Central frem for at bogføre direkte. API’et har fx journalLines, som kan oprettes, rettes og slettes. Rapporten opretter kladdelinjen, og et menneske bogfører den i Business Central med sine egne rettigheder. Til budgetter findes Business Centrals egen Excel-import på budgetsiden, som ofte er nok.

Der er undtagelser. Frie kommentarer til en rapport, som ikke hører hjemme i ERP’et, kan fint ligge i en Fabric SQL database. Men så skal det være et bevidst valg med en ejer, og ikke fordi det var nemmest.

Grafikken herunder viser løkken fra rapport til kildesystem og tilbage, og hvad der sker, når en sidedatabase kommer ind i stedet.

Løkken fra rapport til Business Central og tilbage til den semantiske model ved writeback
Skriv i kildesystemet, læs i modellen. En sidedatabase skaber en ekstra sandhed.

Governance: hvem må skrive hvad

Når en rapport kan skrive, bliver en læseadgang til en skriveadgang. Fire spørgsmål skal besvares, før knappen publiceres. Hvem skriver: brugeren selv eller en fælles forbindelse, som flowets ejer har oprettet? Hvad må der skrives: hvilke felter, hvilke beløbsgrænser, hvilke selskaber? Hvor logges det? Og hvem godkender, før det får økonomisk konsekvens?

Det er samme spørgsmål, som opstår, når en AI-agent får skriveadgang. Business Central MCP-serveren er read-only som standard, og skriveadgang slås til pr. API-side. Samme princip gælder her: tillad det mindst mulige, og start med at oprette kladder frem for at bogføre. En skabelon til at skrive det ned findes i agent-governance, og forskellen på styring i Power BI og på en dataplatform står i governance: styring og kontrol i begge verdener.

Sådan sætter du det op i Power BI

Et første forsøg bør være lille, skrive til Business Central og kunne rulles tilbage. Et eksempel er en periodiseringskladde fra en afvigelsesrapport.

  1. Opret en særskilt kladde i Business Central. Fx en finanskladde, der kun bruges til linjer fra rapporten, så de er lette at finde og slette.
  2. Tilføj Power Automate-visualet. Vælg de felter, der skal med: finanskonto, beløb, dato og dimension. Byg flowet inde fra rapporten med Business Central-connectoren, fx Create record (V3), så der oprettes en linje i kladden.
  3. Brug en forbindelse med snævre rettigheder. Kontoen bag forbindelsen skal kunne oprette kladdelinjer, men ikke bogføre.
  4. Del flowet som run-only. Kun de brugere, der må oprette linjer, får ret til at køre det, gerne via en Entra-gruppe.
  5. Fortæl brugerne om forsinkelsen. Linjen findes med det samme i Business Central, men rapporten viser først effekten efter bogføring og næste opdatering.

Hvad writeback i Power BI ikke løser

Writeback gør ikke Power BI til et planlægnings- eller budgetsystem. Grænsen på 1.000 rækker i Power Apps- og Power Automate-visualet og forsinkelsen i import-modeller betyder, at store budgetrunder stadig hører hjemme i et værktøj, der er bygget til det. Se planlægningsdata i Power BI for, hvordan planerne læses ind.

Licenserne kommer oveni. Translytical task flows kræver Fabric-kapacitet til funktionerne. Power Apps og Power Automate med Business Central-connectoren kræver som udgangspunkt Premium-licenser. Om jeres Business Central-licenser giver brugsret, afgøres af Microsofts licensvejledning for Power Platform, så tjek den, før I bygger. Hvordan licenser og kapacitet påvirker den samlede pris, gennemgår hvad koster det.

Og governance forsvinder ikke, fordi knappen er pæn. Hver skrivevej er en ny integration, der skal vedligeholdes, overvåges og tages med, når Business Central opgraderes.

Sådan understøtter oneBC365 det

oneBC365 tilbyder ikke writeback i dag. oneBC365-extensionen i Business Central eksponerer data som OData v4 API-sider, der er read-only og ikke tilføjer brugerflade eller proces i Business Central. Modellen er en import-model med RLS. Det er et bevidst valg: læsesiden skal være én sandhed med én definition af hvert tal, og skrivning hører til i kildesystemet med kildesystemets rettigheder.

Det, oneBC365 har i dag, er deep-links. Modellen bygger links fra rapporten direkte til den rigtige side i Business Central, så brugeren går fra afvigelsen til debitoren, varen eller bilaget og handler dér. Vil I bygge writeback oven på rapporterne, ligger hele løsningen som PBIP i Git, og I ejer koden. Så kan jeres BC-partner tilføje en af de fire veje, mens det semantiske lag forbliver det sted, AI-agenter og brugere læser fra.

Sådan kommer du i gang

  1. Skriv tre konkrete handlinger ned. Hvilke beslutninger tages i dag på baggrund af rapporterne, og hvor registreres de bagefter? Er svaret “i en mail”, er det en kandidat.
  2. Find destinationen for hver handling. Hvilken tabel eller kladde i Business Central skal ændres, og findes der en API-side, der tillader det?
  3. Tjek licenser og kapacitet. Har I Fabric-kapacitet, Power Apps- eller Power Automate-licenser med Premium-connectors? Svaret afgør, hvilken vej der er realistisk.
  4. Byg én knap, der opretter en kladdelinje. Ikke en bogføring. Lad et menneske godkende i Business Central, og mål, om den bliver brugt.

Relaterede artikler

Vil I se, hvordan deep-links fra rapport til Business Central virker på jeres egne tal? Book en demo, så viser vi det live på 30 minutter.

Scroll to Top