Vi utvecklar Power BI-lösningar för återföring av data till Microsoft Fabric med hjälp av Translytical Task Flows – så att ditt team kan redigera planer, omplanera uppgifter och godkänna poster direkt i den rapport de redan tittar på. Lösningarna är integrerade i Power BI, styrs av Fabric och utformade för att fungera kontinuerligt i produktionsmiljön – inte bara i en demoversion.
Era rapporter visar på problemet. Men de gör det inte möjligt för någon att åtgärda det.
Power BI är utformat för att läsa data, inte skriva in dem. Så fort någon behöver uppdatera en prognos, omplanera en uppgift eller godkänna en post lämnar de rapporten – och rapporten upphör då att vara den enda tillförlitliga källan. Translyticals uppgiftsflöden på Microsoft Fabric överbryggar den klyftan direkt i plattformen. Frågan är om logiken för återskrivning är tillräckligt väl utformad för att man ska kunna lita på den i produktionsmiljön.
Planer och prognoser som fastställdes vid den senaste exporten
Ett tal uppdateras i ett kalkylark, men rapporten visar fortfarande förra månadens siffra. Någon måste komma ihåg att importera den på nytt, och tills dess baseras alla beslut som fattas utifrån instrumentpanelen på inaktuella uppgifter.
Ändringar i schemat sker utanför schemat
En uppgift flyttas fram två dagar, en resurs blir dubbelbokad, och ingen märker det förrän det dyker upp som en konflikt en vecka senare. Rapporten som skulle ha upptäckt detta kan bara visa planen – den gör det inte möjligt för någon att justera den och se följdeffekterna i realtid.
Godkännanden och korrigeringar finns i e-postmeddelanden, inte i dokumentet
Någon godkänner en budgetpost genom att svara på ett e-postmeddelande. Detta syns aldrig i rapporten. När revisorn frågar vem som godkände vad och när finns svaret inte i systemet – det finns i någons inkorg.
De återföringsfunktioner vi utvecklar åt våra kunder.
Vi är specialiserade på Power BI-återföring i Microsoft Fabric – närmare bestämt Translytical Task Flows och Fabric User Data Functions. Det innebär att skrivvägen är integrerad i den plattform där din rapport redan körs, och inte ett påbyggt verktyg med ett eget separat datalager som måste underhållas. Från ett enda redigerbart fält till en helt interaktiv visualisering av schemaläggning bygger vi flödet från början till slut: utlösaren, valideringslogiken, skrivningen och uppdateringen tillbaka till rapporten.
Translytiska arbetsflöden och Fabric-funktioner för användardata
Den inbyggda Microsoft-vägen för skrivning: en kontroll i din rapport aktiverar en Fabric User Data Function, som validerar indata och skriver till Fabric SQL Database, ett Fabric Warehouse eller ett Fabric Lakehouse. Ingen separat mellanprogramvara att driva, inget separat identitetssystem att hantera – det körs på den Fabric-tenant du redan har. Typiska arbetsflöden inkluderar:
- Återskrivning av redigerbara fält – ett värde som matas in direkt i ett rapportobjekt valideras och skrivs till den underliggande Fabric SQL-databasen
- Uppdatering av godkännandestatus – när en åtgärd för godkännande eller avslag utförs i rapporten sparas beslutet, tidsstämpeln och den som godkänt åtgärden tillbaka i posten
- Villkorad återskrivning – måltabellen eller valideringsregeln ändras beroende på det angivna värdet (t.ex. belopp som överstiger ett tröskelvärde markeras för granskning)
- Massuppdateringsflöden – en enda åtgärd tillämpar en ändring på flera valda rader, med validering för varje rad
Anpassade visualiseringar för återföring
Vissa användningsfall kräver mer än bara en knapp och ett textfält – de kräver direkt interaktion. Vi utvecklar anpassade Power BI-visualiseringar med dra-och-släpp-funktioner som anropar Fabric User Data Functions vid varje ändring, vilket ger användarna feedback i realtid innan något skrivs ut. Typiska exempel är:
- Interaktiv Gantt-planering – dra en uppgift för att omplanera den, ändra storleken för att justera varaktigheten och se resurskonflikter markeras i realtid medan du drar, redan innan ändringen sparas
- Planeringsdiagram i tabellformat – redigera budget- eller prognosvärden direkt i en matris, där totalsummorna räknas om medan du skriver
- Kommentarer och anteckningar – lägg till en anteckning till valfri datapunkt direkt i diagrammet; anteckningen sparas tillsammans med användarens namn och tidsstämpel
Validering och styrning
Varje skrivning genomgår en validering på serversidan inuti Fabric User Data Function – det är inte bara en kontroll i det grafiska gränssnittet som kan kringgås. Säkerheten på radnivå respekteras, varje ändring förses med en tidsstämpel och avvisade skrivningar återger en tydlig orsak istället för att misslyckas utan någon meddelande. Vanliga mönster inkluderar:
- Validering enligt affärsregler innan någon skrivning bekräftas (t.ex. inga dubbelbokningar av resurser, inga negativa budgetposter)
- Revisionsloggning av vem som ändrade vad, när och från vilken rapport
- Den semantiska modellen uppdateras automatiskt efter en lyckad skrivning, så att alla användare ser uppdateringen omedelbart
Hur det fungerar.
1. Arkitektur och systemförberedelser
Innan vi skriver någon kod fastställer vi vad er Fabric-tenant redan stöder, var måldata ska lagras (Fabric SQL Database, Warehouse eller Lakehouse) och vad valideringsreglerna måste omfatta. Detta dokumenteras och överenskoms med er innan utvecklingen påbörjas. Ett återskrivningsflöde som bygger på otydliga regler ger upphov till opålitliga data.
2. Bygga och testa
Vi bygger användardatafunktionen, utlösaren på rapportsidan och – vid behov – det anpassade visualiseringselementet, och testar dem sedan mot er Fabric-miljö med realistiska data. Vi testar både normala flöden och gränsfall: samtidiga redigeringar av samma post, en skrivning som inte klarar valideringen och ett nätverksavbrott mitt i en sparning. De flesta fel vid återskrivning i produktionsmiljön beror just på dessa scenarier.
3. UAT och godkännande
Ni testar arbetsflödet mot verkliga scenarier från er dagliga rapportering. Vi åtgärdar eventuella problem, dokumenterar kända begränsningar och bekräftar att validerings- och uppdateringsfunktionerna fungerar enligt överenskommelse innan godkännande.
4. Överlämning och dokumentation
Fullständig överlämning inklusive en skriftlig beskrivning av varje funktions ingångsvärden, valideringslogik och skrivmål – tillräckligt tydlig för att ditt team ska kunna förstå och underhålla systemet utan vår hjälp. Inkluderar 3 månaders felkorrigering. Löpande support erbjuds via ett ramavtal.
Vad våra kunder skriver tillbaka.
Interaktiv planering av uppgifter och resurser
En planerare drar en uppgift i ett Gantt-diagram till ett nytt datum. När hen drar markeras överlappande bokningar på samma resurs omedelbart. När uppgiften släpps validerar en Fabric User Data Function den nya tidsplanen mot alla andra bokningar för den resursen och skriver in ändringen i Fabric SQL-databasen. Om det föreligger en verklig konflikt avvisas skrivningen med en tydlig motivering istället för att planen tyst förstörs.
Redigering av budget och prognoser
En ekonomichef justerar ett prognosvärde direkt i en Power BI-matris. Ändringen valideras mot den godkända budgetramen och sparas i det underliggande Fabric Warehouse. Alla andra som tittar på rapporten ser det uppdaterade värdet vid nästa uppdatering – utan export, utan återimport och utan något separat planeringsverktyg.
Arbetsflöden för godkännande
En begäran visas i en rapport med knapparna ”Godkänn” och ”Avvisa”. När en begäran godkänns utlöses en Fabric User Data-funktion som skriver in beslutet, den som godkänt begäran och en tidsstämpel i posten, samt uppdaterar statusen så att den syns för alla i kedjan nedströms. Hela beslutshistoriken lagras i samma tabell som rapporten hämtar data från.
Datakorrigering vid källan
En användare upptäcker ett felaktigt värde när hen granskar en rapport och rättar till det direkt, istället för att skapa ett ärende och vänta på att någon annan ska åtgärda det uppströms. Korrigeringen valideras och skrivs direkt in i källtabellen som drivs av Fabric.
Kommentarer och anteckningar
En granskare lägger till en anteckning vid en specifik datapunkt – en förklaring till en avvikelse eller en markering för uppföljning. Kommentaren registreras med användarens namn och tidsstämpel och visas för nästa person som öppnar samma rapport.
Transparent prissättning.
Vi arbetar enligt principen Time & Material. Du betalar för faktiskt arbetade dagar till ett fast dagspris. Inga överraskningar med fasta priser, ingen omfattning som ökar utan ditt godkännande.
| Flödestyp | Typisk omfattning | Indikativ kostnad (netto) |
|---|---|---|
| Ett enda redigerbart fält eller en godkännandeåtgärd | 2–4 dagar | 1 600–3 200 euro |
| Anpassad visuell återkopplingsfunktion (t.ex. interaktivt Gantt-diagram med konfliktdetektering) | 6-12 dagar | 4 800–9 600 euro |
| Dagspris | från €800/dag (netto) - 100% fjärrkontroll | |
Återföring ingår ofta i ett större Power BI eller Tyg uppdrag - kombinerade uppdrag drar nytta av ett enda dagspris för hela omfattningen.
Vi ville att användarna skulle kunna omplanera produktionsuppgifter direkt i rapporten och omedelbart upptäcka konflikter – utan att behöva exportera till ett kalkylblad och skicka det vidare via e-post. Resultatet blev en Gantt-vy där man, när man drar en uppgift, ser konflikten redan innan man släpper musknappen, och den fungerar fortfarande utan problem i produktionen flera månader senare.
— Driftschef, tillverkning, Tyskland
Varför just vi?
Inbyggt i själva tyget, redan från början
Vi bygger uteslutande på Translytical Task Flows och Fabric User Data Functions, istället för att vidarebefordra skrivningar via ett separat datalager från en tredje part. Det innebär att dina data förblir inom den Fabric-tenant som du redan förvaltar, skyddar och betalar för – ingen ytterligare plattform att licensiera, inget separat system som lagrar en kopia av dina data.
Vi hanterar de svåraste fallen
Ett skrivåterföringsflöde som fungerar i en fem minuter lång demo slutar ofta att fungera första gången två personer redigerar samma post, eller när en skrivning misslyckas halvvägs. Vi bygger in validering på serversidan, konflikthantering och tydliga felmeddelanden i varje funktion, så att när något går fel – och det kommer det att göra – ser användaren varför, istället för att få en tyst, felaktig skrivning.
Specialister, inte generalister
Writeback för Power BI och Fabric är vår specialitet. Vi är inte ett allmänt BI-konsultföretag som ibland bygger ett writeback-flöde – detta är vår huvudsakliga specialisering, från det enklaste redigerbara fältet till helt anpassade drag-and-drop-visualiseringar med validering i realtid.
Vanliga frågor och svar.
Behöver vi en Microsoft Fabric-licens?
Ja – Translytical Task Flows körs på Fabric User Data Functions, vilket kräver Fabric-kapacitet (en provkapacitet räcker för att komma igång). Vi kontrollerar din nuvarande licensiering och meddelar dig i förväg om något ytterligare behövs innan vi börjar bygga.
Vilka datakällor kan användas som mål för återskrivning?
Fabric SQL Database, Fabric Warehouse och Fabric Lakehouse är de skrivmål som stöds. Om dina data för närvarande finns någon annanstans kommer vi att ge råd om det mest praktiska sättet att överföra dem till Fabric inom ramen för projektets omfattning.
Går det att skapa ett anpassat visuellt element med dra-och-släpp-funktion, till exempel ett Gantt-diagram som går att schemalägga?
Ja – det här är en av våra mest efterfrågade funktioner. Användarna drar en uppgift för att flytta den till en annan tidpunkt eller ändra dess storlek, ser konflikter markeras direkt medan de drar, och ändringen bekräftas och sparas så fort de släpper uppgiften.
Vad händer om en skrivning misslyckas?
Funktionen ”Fabric User Data” anger en tydlig orsak till felet – en valideringsregel som inte uppfyllts, en motstridig ändring, ett behörighetsproblem – istället för att avbryta processen utan någon meddelande. Användaren ser orsaken direkt i rapporten.
Kan ni dokumentera flödena så att vi själva kan underhålla dem?
Ja. Varje uppdrag omfattar skriftlig dokumentation av varje funktions ingångsvärden, valideringslogik och skrivmål, formulerad på ett lättförståeligt språk. Ert team bör kunna förstå vad en funktion gör och göra mindre justeringar utan att behöva kontakta oss.
Hur lång tid tar ett writeback-projekt?
Ett enskilt redigerbart fält eller en godkännandeprocess tar vanligtvis 2–4 dagar, inklusive testning och dokumentation. En anpassad visuell återkopplingsfunktion med realtidsvalidering, till exempel ett interaktivt Gantt-diagram, tar vanligtvis 6–12 dagar beroende på komplexiteten. Vi lämnar en skriftlig beskrivning av projektets omfattning innan vi påbörjar arbetet.
Kombineras ofta med Power BI-återföring.
Power BI-rådgivning
En återföring är bara så användbar som den modell den bygger på. Vi utformar den semantiska modellen och DirectQuery-konfigurationen som ser till att din rapport hålls synkroniserad så fort en skrivning genomförs.
Microsoft Fabric
Translyticals arbetsflöden förutsätter en välstrukturerad Fabric-miljö. Om den underliggande Fabric SQL-databasen, datalagret eller Lakehouse-miljön ännu inte är klar, konfigurerar vi den som en del av samma uppdrag.
Power Automate
Vissa writeback-händelser bör utlösa en efterföljande process – ett meddelande, en godkännandekedja eller en statusuppdatering någon annanstans i Microsoft 365. Vi kopplar Fabric-writeback-händelser till Power Automate-flöden där det behövs.
Är du redo att göra dina rapporter redigerbara?
Berätta för oss vad som behöver kunna redigeras – ett fält, ett godkännande, en hel schemavy – så återkommer vi med en preliminär beskrivning av omfattningen och en kostnadsuppskattning inom 24 timmar.
Eller mejla oss direkt på info@leaplytics.de
Relaterade tjänster: Power BI-rådgivning - Microsoft Fabric - Power Automate - Power Apps