rss.livelink.threads-in-node

Best Practices for Zero-Record Handling in Fabric Pipelines

RMori95610 — Fri, 13 Nov 2026 10:44:26 GMT

Hi Fabric Community,

We are building a Microsoft Fabric pipeline to retrieve deleted lead records from the Adobe Marketo Deleted Leads REST API and store them in a Bronze Lakehouse.

Our goal is to implement a reliable, maintainable solution using primarily no-code/low-code Fabric features.

We have successfully tested the following pipeline, but would like to confirm whether this architecture follows Fabric best practices or if a simpler approach is available.

1. Current Pipeline Architecture

REST Copy Activity

　- Retrieve all pages using nextPageToken / moreResult

　- Save raw JSON files in Run ID-specific folders

↓

Dataflow Gen2

　- Receive the Pipeline Run ID as a parameter

　- Read and parse the corresponding JSON file

　- Expand the result arrays

　- Append records to a Bronze Lakehouse table

↓

Wait Activity (60 seconds)

↓

Lookup Activity

　- Count records for the current Pipeline Run ID

↓

If Condition

　├─ 0 records

　│ → Mark Bronze as successful (0 records)

　│ → Skip Silver processing

　│

　└─ 1 or more records

→ Mark Bronze as successful

→ Execute Silver processing

Before the REST Copy Activity, we obtain an OAuth access token and a Paging Token based on the extraction start datetime.

We use a one-hour overlap to reduce the risk of missing records. Since the deleted leads have already been deleted, we retrieve all available records after the specified start datetime without applying an end datetime.

2. Why We Chose This Architecture

① REST Copy Activity does not provide the actual deleted lead count

The Deleted Leads API returns a JSON response containing a result array and pagination metadata.

Although REST Copy Activity successfully retrieves and saves the paginated JSON responses, its rowsCopied value does not match the actual number of deleted lead records.

Therefore, we decided not to use rowsCopied for zero-record detection.

② We use Dataflow Gen2 to parse JSON and append records to Bronze

Dataflow Gen2 parses the JSON responses, expands the result arrays, and converts the deleted lead records into tabular data.

We use Append rather than Replace because we want to retain historical deletion records in the Bronze layer.

Each record includes a batch_id column containing the Pipeline Run ID, allowing us to identify records ingested during a specific pipeline execution.

Duplicates caused by overlapping extraction windows will be handled in the Silver layer.

③ We added a Wait Activity because Lookup initially returned zero records

When we executed Lookup immediately after Dataflow Gen2, it sometimes returned zero records even though Dataflow had successfully appended records to the Lakehouse table.

After adding a 60-second Wait Activity, Lookup returned the expected record count.

We suspect this is related to synchronization latency between Lakehouse Delta tables and the SQL analytics endpoint.

④ We adjusted Dataflow Gen2 to handle empty results

When no deleted leads were returned, Dataflow Gen2 initially failed because the expected attributes column was missing.

We modified the Power Query transformation to define the expected table schema explicitly, allowing Dataflow Gen2 to complete successfully even when there are zero records.

3. Questions

Q1. Is this pipeline architecture considered a best practice in Microsoft Fabric?

Is the combination of REST Copy Activity → Dataflow Gen2 → Wait → Lookup → If Condition a recommended approach for this type of ingestion and conditional downstream processing?

Are there simpler or more maintainable alternatives using standard Fabric activities?

Q2. What is the recommended way to handle Lakehouse SQL analytics endpoint synchronization latency?

Adding a fixed 60-second Wait Activity resolved our immediate issue.

However, we are concerned that a fixed delay may not be reliable as data volumes or workloads increase.

Is there a recommended mechanism to detect when newly appended Lakehouse records become available through the SQL analytics endpoint, rather than relying on a fixed wait time?

Q3. Is there a better way to detect zero records without converting the JSON into a Lakehouse table first?

We initially considered using the Marketo API's moreResult property to determine whether deleted lead records were available.

However, we understand that moreResult indicates whether additional pages need to be retrieved, rather than whether the result contains records.

In some cases, the API can return an empty result array while moreResult=true, meaning subsequent pages may still need to be retrieved.

Therefore, checking only moreResult or the first page's record count could incorrectly classify the extraction as empty.

In addition, the REST Copy Activity's rowsCopied does not reflect the actual number of deleted lead records.

For these reasons, our current approach is to:

Retrieve all pages until moreResult=false.

Parse and expand the JSON result arrays using Dataflow Gen2.

Append the data to the Bronze Lakehouse table.

Use Lookup Activity to count records associated with the current Pipeline Run ID.

Skip Silver processing only when the final record count is zero.

Is there a more efficient no-code/low-code approach to count the actual records across all paginated JSON responses and determine whether the result is empty, without first loading the data into a Lakehouse table?

We want to avoid both missed records and incorrect zero-record detection.

Any recommendations on best practices for this scenario would be greatly appreciated.

Thank you in advance for your insights!

How do you pick the Fabric capacity size for dev, test and prod?

jubinsoni — Fri, 13 Nov 2026 00:51:21 GMT

We run dev, test and prod on one shared capacity, and I have been using the Capacity Metrics app to look at CU usage per workspace. Prod refreshes in the morning cause most of the peaks, while dev is mostly idle. I am planning to split dev onto its own smaller capacity but am not sure how to size it. How do you decide the SKU for each environment, and is it safe to pause the dev capacity outside work hours (scheduled refreshes, pipelines, mirroring)?

Loading Information Protection - PBI desktop

anikmandal — Thu, 12 Nov 2026 20:14:54 GMT

Hi Team,
I am not able to open any report on my pbi app , whenver I am trying to open a report, it throws an error: "The file's sensitivity label can't be verified. Please try later". Is there a resolution for this I need to do on my side?

I am on the Nov 2026 version of the application. Any help here is greatly appreciated.

Security Configuration Changed

Talha_Mughal — Thu, 12 Nov 2026 15:10:55 GMT

Every time I make a change to my warehouse in OneLake, such as adding or renaming a column, the semantic models built on that warehouse show this error:

“Direct Lake security configuration has changed. Wait a few minutes and try again.”

The error can persist for several hours, preventing me from accessing the models and continuing to build reports. Has anyone experienced this issue or know how to resolve it?

dbtJob in subfolder workaround?

leppekj — Wed, 11 Nov 2026 21:14:44 GMT

Hello!

I would like to run a dbt job against a dbt project that sits in a subfolder of a shared GitHub repo, not at the repo root. Since I'd like to have a single repository linked to Fabric, rather than one repository with the notebooks and a separate one for the dbt code.

In the dbt job item in the UI by default, it says “Folder path: Root folder” prominently but I found no way to change it in the portal.

Through the REST API I can read the item definition (getDefinition). The DataBuildToolJob item definition lists folderPath as an optional string, “Path to the dbt project folder”.

dbt-content.json has a project.folderPath field, and updateDefinition accepts a change to it. I tested three values:

"", with the project in a subfolder and no root dbt_project.yml: error 20418, “The project yaml file was not found in the dbt project.”
warehouse/dbt/demo_project, where dbt_project.yml is in that folder: error 20418 again.
/warehouse/dbt/demo_project: error 2011, “The folder path must be a relative path, not an absolute path.”

So Fabric validates the field, but a relative path to the project folder did not find the yaml file.

Instead what does work is a dbt_project.yml at the repo root with model-paths and seed-paths pointing into the subfolder (where another dbt_project.yml file exists), and folderPath left empty.

Questions:

The GitHub guide says dbt_project.yml must be at the repo root. What does the folderPath field in the item definition do?
Is this root pointer file a reasonable workaround, or other options?
Is a subfolder layout planned for the Git setup of dbt jobs?

Sorry if the Tag is incorrect but it forces me to choose one.

Something exciting is afoot.

FabricPam — Wed, 11 Nov 2026 22:45:07 GMT

Can you piece it together? Comment with your guesses and then check back at 8am PT on November 16th for the answer!

What are the best practices for organizing workspaces in Microsoft Fabric?

codeautomation — Wed, 11 Nov 2026 18:04:05 GMT

I'm exploring Microsoft Fabric and would like to understand how experienced users organize and manage workspaces in real-world environments.

As projects grow, maintaining a structured workspace environment becomes important for collaboration, security, and deployment management.

I'd appreciate insights on a few questions:

How do you structure workspaces for development, testing, and production?
What are the recommended practices for managing workspace roles and permissions?
How do you organize different teams and projects within a Fabric environment?
When should we use deployment pipelines?
What are the common workspace management mistakes that should be avoided?

I'd love to hear practical recommendations and lessons learned from people managing Microsoft Fabric environments at scale.

Daily snapshot exceeds Direct Lake limits on F64: recent detail + monthly aggregate, or better?

paulos — Wed, 11 Nov 2026 17:51:44 GMT

I'm designing a Direct Lake on OneLake model on an F64 and would like a sanity check from people who have done this at scale.

The fact table is a daily snapshot of account balances, one row per account, product and day. It grows by around 2 billion rows a year and we keep many years, so it is well past the 1.5 billion rows per table guardrail and I do not want to split it into a pile of yearly tables.

When I look at how the measures use it, there are only two patterns:

- "current balance" style measures that read one single day, the latest one

- an average balance KPI whose denominator is the balance summed day by day over a date range, sometimes several years

So the old data is only ever needed as a sum of one column over days.

My plan is two Direct Lake tables:

- a "recent" table with the last couple of months at full daily detail

- a "monthly" table with that one column summed per closed month, at the same keys

and the KPI does SUM(recent[col]) + SUM(monthly[col]). The daily history stays in the lake and the model never reads it.

Questions:

1. Has anyone run this in production on Direct Lake? Anything that surprised you?

2. Is there a better pattern for "recent detail plus long history" in Direct Lake, given there are no hybrid tables and no user-defined aggregations?

3. The weak spot is a date range that starts or ends in the middle of an old month, where I lose day precision. If the business insisted on exact days for old periods, would you attach the daily history as a DirectQuery table in the same model, or is there another way out?

Unable to Activate Microsoft Fabric Free Trial in New Entra Tenant

Vrishanika — Wed, 11 Nov 2026 16:31:30 GMT

Hello Fabric Community Members,

I am preparing for the Microsoft DP-700 (Fabric Data Engineer Associate) certification and trying to activate the Microsoft Fabric 60-day free trial for hands-on practice.

Unfortunately, I am unable to activate the Fabric trial, even though my Power BI Individual Trial is successfully activated.

Error messages:

"A Fabric trial isn't available for your account. See the Microsoft documentation for eligibility requirements."
"Something went wrong. Sorry, we are unable to start trial at this time. Please try again later or contact support."

My environment details:

Azure subscription: Azure Free Account
Available Azure credits: CHF 166
Microsoft Entra tenant: Newly created Default Directory
Tenant creation date: 11 November 2026
Tenant region: Switzerland North
Account type: New organizational UPN (@tenantname.onmicrosoft.com)
User type: Member
License type: Free account
Power BI Individual Trial: Active (60 days)
Microsoft Fabric trial: Unable to activate

Troubleshooting already performed:

Created a new personal Microsoft email account.
Created an Azure Free subscription.
Created a new Microsoft Entra tenant and organizational user.
Verified that the user type is Member.
Signed in to Fabric using the new organizational UPN.
Tried activating the Fabric trial using Switzerland North.
Tried creating a workspace and Lakehouse to trigger trial activation.
Still receiving the same Fabric trial eligibility error.

Microsoft documentation followed:

https://learn.microsoft.com/en-us/fabric/fundamentals/free-trial-account-personal-email

https://learn.microsoft.com/en-us/fabric/fundamentals/fabric-trial

My questions to the community:

Is there any restriction on activating Fabric trials in newly created Microsoft Entra tenants?
Does having an active Power BI Individual Trial affect Fabric trial eligibility?
Is there any additional tenant configuration required to activate a Fabric trial?
Is Switzerland North supported for Fabric trial activation?
Has anyone recently experienced the same issue and successfully resolved it?

I am looking for a free Fabric environment specifically for DP-700 exam preparation.

Any guidance or suggestions would be greatly appreciated.

Thank you!

Best Practices for Implementing Marketo REST API Pagination in Microsoft Fabric

RMori95610 — Wed, 11 Nov 2026 10:19:45 GMT

Hi,community

We are currently building a data ingestion pipeline in Microsoft Fabric to load data from Adobe Marketo Engage into a Lakehouse.

The Marketo Program List API uses maxReturn (maximum 200 records) and offset for pagination.

We plan to use date filters to incrementally retrieve updated Programs. However, we would also like to implement pagination to handle cases where more than 200 records are returned within a single extraction period.

We would appreciate your advice on the best practices for implementing this in Microsoft Fabric.

1. Current Architecture

We are currently building the following pipeline:

Use a Web Activity to obtain an access token for the Marketo API.
Use another Web Activity to retrieve the Program list and check whether any records exist within the specified date range.
Use an If Condition to check the number of records:
- 0 records: Skip Bronze/Silver processing and complete the pipeline successfully.
- 1 or more records: Use a Copy Activity to retrieve data from Marketo and save it in JSON format to the Bronze Lakehouse.
After the Bronze data is successfully saved, use Dataflow Gen2 or similar processing to load the data into the Silver layer.

In the Bronze layer, we would like to preserve the original JSON data returned by Marketo as much as possible.
We also maintain pipeline execution results in a separate logging table.

2. Two Approaches We Are Considering

Option 1: HTTP Copy Activity + Until Loop

Keep the existing HTTP connection and control pagination within the pipeline.

Start with offset=0.
Check the number of returned records using a Web Activity or similar method.
Use a Copy Activity to save the retrieved JSON data to the Bronze Lakehouse.
If 200 records are returned, increase offset by 200 and retrieve the next page.
Stop when fewer than 200 records are returned.

We plan to save each page as a separate JSON file.

Option 2: REST Copy Activity with Built-in Pagination

Replace the HTTP Copy Activity with a REST Copy Activity and use its built-in pagination functionality to automatically update the offset.

Configure Pagination Rules in the REST connector.
Automatically increment offset (0, 200, 400, etc.).
Stop when the API response contains an empty result array or another appropriate end condition.
Save the retrieved data to the Bronze Lakehouse.

Our understanding is that this approach would allow pagination to be handled within the Copy Activity without adding an Until loop to the pipeline.

3. Questions

Q1. Which approach would you recommend?

From the perspectives of implementation simplicity, maintainability, and error handling, which approach is considered best practice in Microsoft Fabric?

Q2. Can REST Copy Activity meet our requirements?

Can REST Copy Activity automatically increment offset by 200 and save the retrieved JSON responses to Bronze Lakehouse Files without modifying their original structure?

Q3. What is the recommended way to handle zero-record responses?

Currently, we use a Web Activity to check the record count and an If Condition to skip downstream processing when no records are found.

If we use REST Copy Activity, should we keep this preliminary check, or is there a simpler recommended approach?

We would appreciate any recommendations or configuration examples for implementing this scenario.
Thank you in advance for your help!

Lakehouse Tables

alkandeniz — Wed, 11 Nov 2026 09:00:19 GMT

Hi everyone,

When I deploy items (such as Lakehouses and Notebooks) from my Dev workspace to my Prod workspace in Microsoft Fabric (using Deployment Pipelines), the Lakehouse item itself is successfully created in the Prod environment, but the tables inside the Lakehouse are not visible/missing. Is this expected behavior due to deployment pipelines only transferring metadata/definitions rather than actual data, or am I missing a configuration step?

What is the best practice to populate or sync the Lakehouse tables in the Prod workspace after deployment?

Thanks

Workspace Monitoring Failure

aliciafavitia — Tue, 10 Nov 2026 17:43:50 GMT

We have a premium capacity workspace and have never used workspace monitoring before. We turned it on and Fabric provisioned the Monitoring items in the workspace, but ingestion never began. Teammate opened settings and audit logs was turned off, attempted to check the box and save but a failure icon appeared with no error message.

Building an End-to-End Analytics System - Lakehouse | Part 4 | Learn Microsoft Fabric With Me [2026]

ShivekMaharaj — Tue, 10 Nov 2026 17:32:31 GMT

Welcome to Part 4 of Learn Microsoft Fabric With Me [2026].

In this lesson, we move from understanding Microsoft Fabric workloads individually to building a practical end-to-end analytics solution using the Lakehouse architecture.

In this video, I cover:

The end-to-end analytics scenario and architecture

Sample data and data models
Data ingestion and transformation flows
Lakehouse storage
Importing and working with notebooks
Creating shortcuts for Silver and Gold zones
Incremental data loading
Building business aggregates
Analyzing data with Power BI
Working with the SQL Endpoint
Orchestrating ingestion and transformation
Scheduling Fabric workloads
An introduction to Data Mesh concepts in Microsoft Fabric

We begin by understanding how the different components of the solution fit together and how data moves through the overall architecture.

From there, we work through the ingestion and transformation process, using Microsoft Fabric capabilities to organize data across different layers of the Lakehouse. This includes creating shortcuts, executing notebooks, loading data into the Silver Zone, implementing incremental loading, and preparing Gold Zone data for analytics.

We then move into the analytical layer, where the transformed data can be accessed through Power BI and the SQL Endpoint.

The lesson also explores orchestration and scheduling, showing how the individual ingestion and transformation steps can be connected into a repeatable end-to-end workflow.

Finally, we introduce Data Mesh concepts in Microsoft Fabric and how they relate to organizing and managing data across larger analytics environments.

The goal of this lesson is to demonstrate how the different capabilities within Microsoft Fabric can work together as part of a complete analytics solution rather than being used as isolated tools.

By the end of this lesson, you should have a clearer understanding of how to structure an end-to-end Lakehouse analytics workflow in Microsoft Fabric, from ingestion and transformation through to orchestration and analysis.

Connect with me on LinkedIn
Check out my Complete Fabric Tutorial on YouTube

Fabric workspace naming and folder conventions: what has scaled for your team?

jubinsoni — Tue, 10 Nov 2026 17:30:51 GMT

Hi everyone,

Our tenant has grown to a few hundred workspaces and finding anything is getting harder. We are considering a convention that puts the domain, the layer and the environment in the workspace name, for example:

Finance - Gold - PROD Finance - Gold - TEST Finance - Silver - DEV Sales - Reporting - PROD

What I would like to hear about

Do you encode the environment and the medallion layer in the workspace name, or keep those in folders and tags instead?
How do you use workspace folders for items such as notebooks, pipelines and reports, and do you enforce a standard structure?
Who owns the naming rules, and how do you handle renaming an existing workspace without breaking links, shortcuts or deployment pipelines?

Examples of conventions that worked, and ones you regretted, would be very helpful. Thanks!

syncing workspace from GitHub with large files

vladenache — Tue, 10 Nov 2026 13:37:46 GMT

Hello

The team and I are having a problem with one of our environments. It is used in a specific snowflake ingestion, and has some jar files needed for spark to connect to snowflake. These were already big to begin with, but switching to runtime 2.0 and thus spark 4.1, we need to upgrade the existing jars and now they are too big for Fabric to sync with!

Cannot commit to Git nor Sync from a Git branch containing such a big environment file. Fabric won't allow it. This is not a Git issue, as it allows files up to 2-4 GB (depending on the version), but a Fabric platform issue. It was present a couple of months ago, Microsoft solved it and incresead the size of the files that could be sync-ed by Fabric, but now apparently we overstepped that borderline also.

Anybody can help with this? Copy data activity is not an option for us currently, we need a notebook activity.

Thanks

Unable to Change Existing Lakehouse SQL Endpoint Collation from Case-Sensitive to Case-Insensitive

svattikuti — Tue, 10 Nov 2026 12:38:47 GMT

Hi Community,

I am facing an issue with collation settings in Microsoft Fabric and would appreciate any guidance.

When our workspace and Lake houses were initially created, we did not explicitly configure the SQL endpoint collation. As a result, the Lakehouse SQL endpoints were created with the default case-sensitive collation.

Recently, we started exposing this data to a web application, and the case-sensitive behavior is causing data mismatches and search issues because users expect case-insensitive searches and comparisons.

To address this, I updated the workspace/Lakehouse collation setting to:

Latin1_General_100_CI_AS_KS_WS_SC_UTF8

However, the existing SQL endpoint still appears to retain its original case-sensitive behavior. Queries continue to behave as though the original collation is in effect.

My questions are:

Can the collation of an existing Lakehouse SQL endpoint be changed after it has been created?
If not, is there a supported way to migrate an existing Lakehouse to a case-insensitive collation without recreating all objects?
Are there any recommended workarounds for achieving case-insensitive joins, filters, and searches in Fabric Lakehouse SQL endpoints?
Has anyone successfully resolved a similar scenario where downstream applications required case-insensitive behavior?

Any best practices or recommendations would be greatly appreciated.

Thank you!

Dataflow Gen2 still points to DEV environment after deployment to TEST - Can this be automated?

AnkitaSaxena-82 — Tue, 10 Nov 2026 12:38:01 GMT

Hello everyone,

I'm looking for best practices around automating environment promotion for Dataflow Gen2 in Microsoft Fabric.

Current Scenario

I have 4 Dataflow Gen2 pipelines that were developed and tested in our DEV workspace. I recently moved them to our TEST workspace using our deployment process through deployment Pipelines.

After deployment, I noticed that the dataflows are still pointing to the DEV environment rather than automatically switching to the corresponding TEST resources.

What is currently happening?

Dataflows were created in DEV.
Dataflows were deployed/moved to TEST.
In TEST, the dataflows are still referencing DEV resources (source and/or destination).
The only workaround I currently see is:
- Manually removing the destination.
- Re-adding the TEST destination.
- Republishing the dataflow.

What I would like to achieve

I would like to automate the environment switching process so that when a Dataflow Gen2 is promoted from DEV to TEST:

DEV connections automatically become TEST connections.
DEV Lakehouse/Warehouse destinations automatically become TEST destinations.
No manual reconfiguration is required after deployment.
The process can be managed consistently across multiple dataflows.

Questions

Is there a recommended approach for automating this in Microsoft Fabric?
Are deployment rules, parameters, or environment variables supported for Dataflow Gen2 connections and destinations?
Can this be achieved through:
- Fabric Deployment Pipelines?
- Git integration / CI-CD?
- Fabric REST APIs?
- VS Code-based configuration management?
How are other teams managing DEV → TEST → PROD promotions for Dataflow Gen2 while avoiding manual destination remapping?

Any guidance, examples, or recommended architecture patterns would be greatly appreciated.

Thanks in advance!

Are Notebook Built-in Resources included in Fabric deployment pipeline deployments?

bribri — Tue, 10 Nov 2026 11:50:17 GMT

I’m setting up a Development → Test deployment pipeline in Microsoft Fabric.

I enabled Git support for my notebook’s Built-in Resources folder and committed the resource files. The notebook itself deployed to the Test workspace, but the files in Resources/builtin did not appear there.

Could you confirm the current behavior?

Are files in a notebook’s Resources/builtin folder excluded when deploying through Fabric deployment pipelines?
Is this also the expected behavior for generally available features?
Is there a recommended supported way to deploy these resource files to Test and Production, or a planned timeline for pipeline support?

Environment

Fabric deployment pipeline: Development → Test
Git provider: GitHub
Notebook Built-in Resources Git setting: enabled
Result: notebook deployed, resource files did not appear in the target workspace

Thanks!

Fabric Apps (Preview): Do Data App viewers need Power BI Pro on capacities below F64?

Josua_Potschien — Tue, 10 Nov 2026 10:25:03 GMT

Hi everyone,

I have a question about viewer licensing for Fabric Apps (Preview).

Setup

Fabric capacity: F8
Fabric App of type Data App, which queries a semantic model via the Execute Queries REST API
Semantic model is on the same F8 capacity
Test users have only a Fabric Free license (no Pro, no PPU, no trial, no E5) and Workspace Viewer, Build permission on the semantic model

Observation
The test users can open the app and query data from the semantic model without any Power BI Pro license.

Why I’m unsure
The general Fabric licensing docs say that on F SKUs below F64, users need Pro or PPU to view Power BI content. However, neither the Fabric Apps overview nor the Fabric Apps pricing page mention any viewer license requirements.

Questions

Is this the intended behavior, or is license enforcement just not active yet during the preview?
Will viewers of Data Apps on capacities below F64 need Pro or PPU after GA?
Is there an official statement or roadmap item on this?

This is quite relevant for us when sizing customer scenarios (Pro licenses vs. a larger capacity), so any official input would be much appreciated.

Thanks!

Direct Lake Semantic Model Compute Usage Reduction

codybmb — Tue, 10 Nov 2026 01:01:29 GMT

Hello,
I'm hoping to get some advice on compute reduction, when it comes to Direct Lake Semantic Models.
We've just given the end users access to the reports and the interactive compute usage is higher than we expected.

Someone on my team has suggested trying to replace some of the larger fact tables with aggregate tables, which is going to take so significant rework, as they're referenced in most of the reports. We would still need to keep the unaggregated tables in the model anyway because we need that level of detail for some of the reports.

I had 2 ideas on potential ways to reduce CU:
- Run a notebook after the model refreshes in the morning, to warm up some of the more commonly used tables. (I'm not sure if this will help with compute reduction or only improve performance.)
- Try optimizing some of the DAX measures in the reports. Some of them seem to be over-engineered and could definitely be written better.

For some additional context:
- We're on a F64 capacity
- We have built one central dimensional model, which service approximately 50 reports
- We have approximately 250-300 daily report users
- Auto refresh has been disabled (Refresh is triggered at the end of the ingestion pipeline in the early morning)

If anyone has any suggestions, it would be much appreciated. Hopefully I've given enough context.
Thanks!