The Power BI GROUPBY DAX function groups a table by one or more columns and applies aggregation functions. This reference covers syntax, enterprise use cases, performance tradeoffs, and comparison with SUMMARIZE.
Key Facts
- GROUPBY is a DAX table function that groups rows by specified columns.
- Use iterator functions (SUMX, COUNTX) inside GROUPBY — standard aggregates (SUM, COUNT) do not work.
- GROUPBY must reference CURRENTGROUP() for aggregation — this is its key difference from SUMMARIZE.
- GROUPBY is used inside ADDCOLUMNS expressions, not standalone.
- SUMMARIZE is preferred for most grouping scenarios — GROUPBY is for specific intermediate aggregation cases.
Power BI GROUPBY Function Guide
Power BI GROUPBY Function: Enterprise Reference
The Power BI GROUPBY DAX function groups a table by one or more columns and applies aggregation functions. This reference covers syntax, enterprise use cases, performance tradeoffs, and comparison with SUMMARIZE.
Key facts
- GROUPBY is a DAX table function that groups rows by specified columns.
- Use iterator functions (SUMX, COUNTX) inside GROUPBY — standard aggregates (SUM, COUNT) do not work.
- GROUPBY must reference CURRENTGROUP() for aggregation — this is its key difference from SUMMARIZE.
- GROUPBY is used inside ADDCOLUMNS expressions, not standalone.
- SUMMARIZE is preferred for most grouping scenarios — GROUPBY is for specific intermediate aggregation cases.
GROUPBY Syntax
GROUPBY takes a table as its first argument, followed by grouping columns, then ADDCOLUMNS-style column definitions using CURRENTGROUP() for aggregation.
GROUPBY vs SUMMARIZE
SUMMARIZE is the standard DAX function for grouping a table by columns and adding aggregated measures. Use it for most grouping scenarios.
GROUPBY is designed for use inside ADDCOLUMNS when you need to aggregate over intermediate table results. It is less common and more specialized than SUMMARIZE.
- Use SUMMARIZE when adding measures from the data model.
- Use GROUPBY when aggregating a result table generated by ADDCOLUMNS or another table function.
- Never use standard aggregates (SUM, COUNT) inside GROUPBY — use SUMX, COUNTX, AVERAGEX instead.
- Always reference CURRENTGROUP() as the table argument for iterators inside GROUPBY.
Common GROUPBY Patterns
A common GROUPBY pattern groups an intermediate ADDCOLUMNS result and applies a second-level aggregation. This is useful for ranked or percentile calculations.
Performance Considerations
GROUPBY iterates over the result table row-by-row. For large tables, this can be slower than SUMMARIZE. Profile with DAX Studio before using GROUPBY in production models.
- Prefer SUMMARIZE + CALCULATE for most enterprise grouping scenarios.
- Use VertiPaq Analyzer to check model size after adding GROUPBY calculations.
- Test GROUPBY measures in DAX Studio to measure query time before publishing.
Frequently Asked Questions
What does the GROUPBY function do in DAX?
GROUPBY groups a table by one or more columns and applies aggregation functions using CURRENTGROUP(). It works similarly to SUMMARIZE but is designed for use inside ADDCOLUMNS expressions.
When should I use GROUPBY vs SUMMARIZE?
Use SUMMARIZE for most grouping scenarios — it is more flexible and supports external measures. Use GROUPBY only when you need to aggregate over intermediate results inside ADDCOLUMNS.
What aggregations work with GROUPBY?
GROUPBY supports SUMX, AVERAGEX, MINX, MAXX, COUNTX, and other X-suffix iterators applied to CURRENTGROUP(). Standard aggregation functions like SUM and COUNT do not work directly inside GROUPBY.
Does GROUPBY work in calculated columns?
No. GROUPBY returns a table and must be used in a table expression context — typically inside ADDCOLUMNS or as a source for CALCULATE. It is not valid in a calculated column expression.
What are common errors with GROUPBY?
The most common error is using standard aggregation functions (SUM, COUNT) instead of iterator functions (SUMX, COUNTX) inside GROUPBY. Always wrap aggregations in an iterator with CURRENTGROUP() as the table argument.
Get Expert Help
EPC Group architects have completed 1,500+ Power BI deployments. Call (888) 381-9725 or request a 30-minute discovery call.
Related Resources
Continue exploring power bi insights and services
Why Organizations Choose EPC Group
EPC Group is a Houston-based Microsoft consulting firm with 29 years of enterprise implementation experience and over 10,000 successful deployments across Power BI, Microsoft Fabric, SharePoint, Azure, Microsoft 365, and Copilot. We serve organizations across all industries including Fortune 500, federal agencies, healthcare, financial services, government, manufacturing, energy, education, retail, technology, and global enterprises.
What sets EPC Group apart is our governance-first approach. Every engagement begins with a security and compliance assessment. Our team of senior architects brings hands-on delivery experience across HIPAA, SOC 2, FedRAMP, and CMMC environments. We own outcomes, not hours.
- Fixed-fee accelerators with predictable pricing and defined deliverables
- Senior architect engagement on every project, not rotating juniors
- Compliance-native delivery for regulated industries
- End-to-end coverage from strategy through 24/7 managed services
- 11,000+ enterprise engagements refined into repeatable, risk-controlled patterns
Call (888) 381-9725 or email contact@epcgroup.net for a free assessment.
Power BI Strategy: 2026 Considerations for Power BI Groupby
Row-level security (RLS) and object-level security (OLS) in Power BI Premium and Fabric F-SKU capacities are the single most-overlooked compliance control in HIPAA, SOC 2, and FINRA-regulated environments. RLS scoped via service principal authentication (rather than embedded UPN passes) is the only pattern that survives a SOC 2 Type II auditor privilege-walk test. EPC Group includes service-principal RLS as a default in every regulated-industry Power BI engagement.
Power BI Copilot grounds itself on the semantic model, NOT the underlying source data. That means Copilot answers are only as accurate as the DAX measure definitions, the field metadata (display folders, descriptions, hierarchies), and the synonyms taxonomy. In practice, the difference between a Copilot deployment that drives 32% time-savings and one users abandon within 90 days is whether the semantic model was Copilot-prepared.
Decision factors EPC Group evaluates
- Direct Lake mode adoption for Fabric-resident semantic models
- License optimization audit (Pro vs Premium Per User vs F-SKU)
- Row-level security via service principal authentication
- Capacity sizing decision (F2/F4/F64+) tied to peak concurrent users and refresh window
- Copilot grounding quality assessment of semantic-model metadata
For a tailored read on this topic in your specific tenant, contact EPC Group at contact@epcgroup.net or +1 (888) 381-9725. Engagement options at /pricing.