Power BI Write-Back: Translytical Task Flows
How translytical task flows let a Power BI button write back to Fabric: user data functions, filter context, and which storage mode updates instantly.
Write-back is the request that has outlasted every version of Power BI. A user looks at a report, sees something wrong, and wants to fix it there rather than email somebody who opens a different system. For years the answers were PowerApps embedded in a report, a third-party visual, or a custom app alongside the report.
Translytical task flows are Microsoft's native answer. A button in the report calls a Fabric user data function, and that function writes to a Fabric data source.
Check the status before you plan around it. Microsoft's own sources disagree: the Power BI blog announced translytical task flows as *Generally Available*, while the Fabric Cosmos DB how-to page describes them as *public preview*. Both are Microsoft. Confirm on Microsoft Learn for your tenant before committing a delivery date.
How it actually works
Three pieces:
- A button in the report whose action type is set to Data function.
- A Fabric user data function - Python, living in a Fabric workspace - that performs the write.
- A Fabric data source the function writes to.
The part that makes this genuinely useful rather than a novelty: the report passes its current filter context to the function. The function receives the report's filter and selection context in the request payload, so it knows which rows the user was looking at. You are not writing a generic "update something" endpoint; you are writing one that already knows the scope.
That is what turns a button into an approval workflow, a status update, a forecast override or a data-quality correction.
What it can write to
User data functions can perform add, update and delete operations against:
- SQL database in Fabric
- Warehouses
- Lakehouse files
Microsoft's own recommendation is worth taking seriously: for most write-back scenarios, use a SQL database in Fabric as the underlying store, because SQL databases handle the heavy read/write pattern that reporting write-back produces. Lakehouse files are the wrong shape for a user clicking a button forty times an hour.
What the user sees afterwards
This is where storage mode decides the experience, and it is the question to settle before you build anything:
| Storage mode | After the write |
|---|---|
| Direct Lake | Updated values appear immediately |
| DirectQuery | Updated values appear immediately |
| Import | Appears after an automatic refresh triggered by the task flow |
If your report is import mode, the write happens straight away but the *visual* updates after a refresh the task flow triggers. That is a materially different user experience, and it is worth deciding deliberately rather than discovering in UAT.
Build order
From Microsoft's tutorial, the sequence is:
- Create a User Data Function item in a Fabric workspace.
- Write the Python function, using a connection alias to reach the SQL database.
- Publish the function and test it - on its own, before any report is involved.
- In Power BI, add a button, set its action type to Data function, select your function and connect it.
Testing the function independently in step 3 matters. When a button does nothing, you want to already know whether the function works.
Constraints worth knowing before you design
- The function must return a `str`. A user data function has to return a string type to be added to a report. Design your return value as the message you want the user to see.
- Report context is a payload, not magic. The filter context arrives in the request; your function has to read and use it.
- Check platform limits for your scenario. Community documentation from earlier in the preview listed restrictions including no PBIR/PBIP support and no Power BI Embedded support. That write-up is several months old and the feature has moved since, so verify the current limits on Learn rather than inheriting that list.
Where this is genuinely the right tool
Good fits share a shape: a small, scoped write, made by someone already looking at the relevant rows.
- Approvals - mark a row reviewed, approved or rejected
- Status updates - Microsoft publishes a tutorial specifically for this
- Forecast or target overrides - a planner adjusts a number in context
- Data-quality flags - mark a record as suspect for a data team to pick up
- Comments and annotations attached to the filtered selection
Poor fits are the ones where the report is doing a job an application should: bulk data entry, multi-step forms, anything needing validation richer than a function can express, or anything requiring a transaction across several systems.
The architectural question to ask first
Write-back changes what a report *is*. A read-only report can be rebuilt, moved or deprecated freely. A report that writes is part of a business process, and it inherits the obligations that come with that: who is allowed to write, what happens when two people write at once, what the audit trail looks like, and what happens to in-flight writes during a refresh.
None of that is a reason to avoid translytical task flows. It is a reason to treat the first one as a system design exercise rather than a report feature.
*Sources: Microsoft Learn - Understand translytical task flows; Create translytical task flow (tutorial); Create a status update workflow; Fabric user data functions overview; Translytical task flows with Cosmos DB. Also the Power BI blog announcement. Status and limits move - verify on Learn. Accurate as at 25 October 2026.*
Frequently Asked Questions
What is a translytical task flow in Power BI?
A translytical task flow lets a button in a Power BI report call a Fabric user data function, which writes back to a Fabric data source. The report passes its current filter and selection context to the function in the request payload, so the write is scoped to what the user was actually looking at.
What can Power BI write back to?
User data functions can add, update and delete records in a SQL database in Fabric, a warehouse, or lakehouse files. Microsoft recommends a SQL database in Fabric for most write-back scenarios, because SQL handles the heavy read and write pattern that reporting write-back generates.
Does the report update immediately after a write-back?
It depends on storage mode. Direct Lake and DirectQuery reports show updated values immediately. Import-mode reports show them after an automatic refresh triggered by the task flow, which is a noticeably different user experience and should be decided before you build.
What does a user data function have to return?
A string. User data functions must return a str type to be added to a report, so design the return value as the confirmation message you want the user to see.
Are translytical task flows generally available or in preview?
Microsoft's own sources disagree. The Power BI blog announced them as generally available, while the Fabric Cosmos DB how-to page describes them as public preview. Confirm the current status on Microsoft Learn for your tenant before committing to a delivery date.