Translytical task flows: write-back in Power BI, and the questions to ask first
Power BI report buttons can now run Fabric User Data Functions, including data write-back. Practical use cases, and the governance questions to answer before you build one.
Write-back in Power BI has been on wish lists for as long as I can remember. With the preview of translytical task flows, announced around Microsoft Build, a report button can now run a Fabric User Data Function. That function can update, add or delete records, or call another system, without the user leaving the report.
Until now, a Power BI report was a place to look at data. Now it can also be a place to change it. That is useful, and it is also where governance starts to matter in a new way.
What Microsoft announced
The Power BI team describes translytical task flows as a way to "automate action directly within the report". The building blocks are simple:
- A Fabric User Data Function holds the logic.
- A button in the report has its action set to run that function.
- Slicers and the report's filter context supply the inputs.
According to the May 2025 feature summary, you can "programmatically update, add, or delete records of data based on the filter context passed from the report". The documentation recommends SQL database in Fabric as the data source for most write-back scenarios, because it handles the heavy read and write load that reporting generates.
To try it, you turn on the Translytical task flows preview feature in Power BI Desktop under File, Options and settings, Options, Preview features. The documentation includes a step-by-step tutorial that writes back to a SQL database in Fabric.
Practical use cases
The announcement post walks through six scenarios.
- Modify data records. The example lets a user type a new discount value and click a button, and the function updates the records that match the current filters.
- Data annotation. Users select a data point, add a comment and see it appear in the report. In my view this is the most useful one: "why did sales drop in March?" belongs next to the number, not in an email thread.
- Dynamic notifications. Changing an offer status to "Accepted" sends an email to a partner contact.
- Approval workflows. A non-admin proposes a discount, an admin gets the request in a Teams channel and reviews it in a filtered admin report before applying it.
- Augment data on the fly. A function fetches extra data from an API, such as the latest contact details for a partner.
- Custom AI integration. The example calls the Azure OpenAI Responses API to generate suggestions based on what is selected in the report.
Annotation and controlled edits to small reference tables are where I would start. They solve real problems, the blast radius is small, and you learn how the pattern behaves before you let it touch anything important.
The governance questions to ask first
A button that changes data is an application, not a visual. Treat it that way. Before you put one in front of users, I would want clear answers to these questions.
Who can click the button, and what can they change? Report access and the right to change data are not the same thing. Decide who should be able to run each function, and check how that is enforced, before you publish.
What does the filter context actually pass? The discount example updates every record that matches the applied filters. That is powerful, and it is also how someone updates 4,000 rows when they meant to update 40. Your function should check what it receives and refuse anything that looks wrong.
Where is the audit trail? If a value changes, you need to know who changed it, when and from what. Build that into the function and the table design from day one. An append-only history table is cheaper than an argument about who changed a forecast.
Is the function safe? User Data Functions are code. Validate every input, use parameterised queries instead of building SQL strings, and handle the case where the database is unavailable. Return a clear message to the user either way.
Which system is the source of truth? If users write back to a SQL database in Fabric, while the same data also lives in an ERP or CRM, you have just created a second master. Be explicit about which data is owned in Fabric and which is not.
What happens when it calls something external? Sending emails, posting to Teams or calling an AI service from a report means the report now has side effects outside Fabric. Agree on who owns those integrations and how secrets and endpoints are managed.
Who maintains it? A report author can now ship logic that changes data. Decide whether User Data Functions go through the same review, source control and testing as the rest of your data platform code.
What to do next
This is a preview, so I would not build production processes on it yet. But it is worth learning now.
A sensible way to start:
- Enable the preview in Power BI Desktop and work through the official tutorial in a test workspace.
- Pick one low-risk scenario, such as annotations on a monthly sales chart.
- Write the function with input validation, parameterised SQL and a history table.
- Write down your answers to the governance questions above, even if they are short.
- Show it to one business user and see whether it changes how they work.
If the governance answers are hard to write, that is a signal. It usually means the process behind the data is not clear yet, and no button will fix that.
Takeaway
After two decades in data, I have seen many write-back workarounds, most of them fragile. Translytical task flows give Power BI a native, Fabric-based way to do it, and that is a real step forward. The harder part is deciding who may change what, and how you will know when they did.
Which process in your organisation would you trust to a button in a report first?
Sources
Enjoyed this? Get the next one by email
Occasional emails about Microsoft Fabric, SQL Server, Power BI and Synapse.