Helpful Assistant, Not a Full Report Developer

The Important Part: Business Definitions Still Matter 

One interesting example was the Return Rate % measure. 

Copilot first created it as: 

Return Rate % = DIVIDE([Return Quantity], [Units Sold]) 

This is not necessarily wrong. It means return rate based on quantity: returned units divided by sold units. 

But return rate can also mean return value divided by sales value. After asking Copilot to explain this, it correctly separated the logic into two measures: 

Return Quantity Rate % = DIVIDE([Return Quantity], [Units Sold]) 

Return Value Rate % = DIVIDE([Total Returns], [Total Sales]) 

This is an important lesson. Copilot can generate DAX, but it does not automatically know the business definition used by the organization. The developer still needs to decide what the measure should actually mean. 

Validation Queries: A Strong Practical Use Case 

Another useful test was asking Copilot to create a DAX query to validate the measures. 

The prompt asked for a summary by Calendar Year and Product Category, including Total Sales, Total Discount, Total Returns, Net Sales, Total Cost, Gross Profit, Gross Margin %, Units Sold, Return Quantity, Return Quantity Rate %, and Return Value Rate %. 

Copilot generated a DAX query using SUMMARIZECOLUMNS and sorted the result by Year and Net Sales. 

This is a very practical use case. After creating measures, the developer can immediately test whether the numbers behave correctly by year, product category, channel, or any other business dimension. This makes Copilot useful not only for writing DAX, but also for checking it before using it in report visuals. 

Explaining DAX in Business Language 

Copilot was also helpful when asked to explain the measures. 

For example, it explained Net Sales as money earned from sales after subtracting discounts and returns. It explained Gross Margin % as the share of net sales kept after product costs. It also explained why DIVIDE is safer than the standard / operator in DAX, because it handles zero or blank denominators without breaking the visual. 

This may sound simple, but it is useful in real projects. Developers often need to explain measures to business users, document logic, or prepare handover notes. Copilot can create a clear first version of that explanation. 

Measure Descriptions and Semantic Model Quality 

Another strong use case was measure documentation. 

Copilot created short business-friendly descriptions for measures such as Total Sales, Net Sales, Gross Profit, Gross Margin %, Average Selling Price, Discount Rate %, and Return Value Rate %. These descriptions can be added to the semantic model so users understand what each measure means and when it should be used. 

This is important because measure descriptions are often skipped. They feel like extra documentation work. Copilot reduces this effort by generating a first draft that the developer can review and improve. 

A better documented semantic model is also easier to use with AI features. Clear names, good descriptions, and business-friendly measures make it easier for Copilot to understand what the user is asking for.