Forum Discussion
New queryBinary parameter in visuals
Hello all,
I have a PBI workspace with the git integration enabled.
I've recently (today) noticed that a number of PBI reports in the workspace have automatically updated - the visuals in the reports now include a `queryBinary` parameter in each config object within the `visualContainers` list for each `section`.
Does anyone have any idea what this is for? Should I just merge the automatic changes in?
4 Replies
- v-sathmakuri
Community Support
Hi ajohns3 ,
Could you check the suggestion provided above and let us know if you have any additional queries?
Thanks!!
- ajohns3
Advocate II
Hi v-sathmakuri ,
Happy to leave this open - I am still wondering what the new parameter is for. I'll link to anything relevant here if it comes up.
- ShivekMaharaj
Community Champion
Hi ajohns3,
I am seeing this as more of a report-definition / serialization change than a normal report-authoring change.
Microsoft documents that Power BI report definitions and their JSON schema versions evolve over time, and Fabric Git integration exports those report definitions into Git.
See the Power BI project report-definition documentation.
The interesting part in your case is that queryBinary appears without anyone manually editing the visual.
Robert_KP's finding is useful here as well: after Base64 decoding and decompressing the value, the contents appear to contain query information similar to the existing prototypeQuery plus additional binding/execution metadata.
However, I could not find queryBinary documented in Microsoft's current public PBIR/report-definition documentation, so I would avoid assuming that it is a property we should manually edit, remove, or derive ourselves.
For Git, I would handle it like this:
- Pick one affected report first.
- Sync/export the Fabric changes.
- Confirm the report still opens and behaves normally.
- Verify that the queryBinary additions are the only unexpected report changes.
- Commit those generated changes separately from your normal development changes.
- Then apply the same approach to the remaining reports if the behavior is consistent.
I would not repeatedly revert the property if Fabric keeps regenerating it, because that can leave your repository permanently showing differences against the service.I would also avoid manually modifying the Base64 payload. If this is service-generated report metadata, Fabric/Power BI should remain the owner of that serialization.
So my current interpretation would be:
queryBinary appears to be generated report/query metadata → it is not currently publicly documented enough to safely customize → validate one report → keep service-generated changes together in a dedicated commit → do not hand-edit or remove the payload unless Microsoft documents that as supportedThe other changes Robert_KP mentioned, such as TMDL culture updates and Dataflow Gen2 schedule metadata, make me even more suspicious that this may be part of a broader service-side serialization/schema update rather than individual users changing their items.
If someone from Microsoft can confirm the rollout, that would be ideal, but until then I would preserve the generated metadata rather than stripping it from Git.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
- Robert_KPNew Member
I'm seeing the same behavior in a Fabric workspace connected to Azure DevOps Repos through Git integration. Multiple reports suddenly show as Modified, with queryBinary added to their visual definitions without corresponding manual edits.
I decoded one example: it contains Gzip-compressed, Base64-encoded JSON. The Query portion matches the existing prototypeQuery, with additional binding and execution settings.
I'm also seeing changes in other item types:
- Semantic models: changes to definition/cultures/en-US.tmdl. I haven't inspected the differences yet because Fabric displays “Changes too large to display.”
- Dataflow Gen2: some .schedules files now include "enabledControlType": "UserDisabled". The existing "enabled": false and schedule configuration remain unchanged.
I'm not sure whether these changes are related. Could someone from Microsoft confirm whether this is an expected service-side update and whether these generated changes should be committed to Git?