How to Rank Data Within Groups in Excel: COUNTIFS Method for Analysis

How to Rank Data Within Groups in Excel: COUNTIFS Method for Analysis

Learn­ing how to rank data with­in spe­cif­ic groups is a valu­able Excel skill that can help you orga­nize and ana­lyze infor­ma­tion more effec­tive­ly. By using the COUNTIFS func­tion, you can eas­i­ly deter­mine the rank­ing posi­tion of ele­ments with­in their respec­tive cat­e­gories with­out man­u­al cal­cu­la­tion, sav­ing time and enhanc­ing your data analy­sis capabilities.

This tech­nique is par­tic­u­lar­ly use­ful when work­ing with sales data, per­for­mance met­rics, or any dataset where you need to iden­ti­fy top per­form­ers with­in dif­fer­ent categories.

In my video, I demon­strate how to imple­ment rank­ing with­in groups using a prac­ti­cal example:

Understanding Rank in Groups

When ana­lyz­ing data, we often need to rank items not just over­all but with­in spe­cif­ic cat­e­gories or groups. For exam­ple, you might want to know which sales­per­son per­formed best in each region, or which prod­uct sold most in each store. This is where rank­ing with­in groups becomes essential.

In my demon­stra­tion, I work with a dataset that’s sort­ed by town (our group­ing vari­able) and col­or-cod­ed for eas­i­er visu­al­iza­tion. The data includes dif­fer­ent towns like Moria, Iron­forge, and Azmarin, with each town rep­re­sent­ing a dis­tinct group for our rank­ing purposes.

What makes this tech­nique pow­er­ful is that you can imme­di­ate­ly see how items rank with­in their spe­cif­ic cat­e­gories rather than just see­ing an over­all rank­ing that might be dom­i­nat­ed by one par­tic­u­lar group. This pro­vides much more action­able insights for decision-making.

Using COUNTIFS for Group Ranking

The core of this tech­nique relies on Excel’s COUNT_IFS func­tion, which allows us to count rows where mul­ti­ple cri­te­ria are met simul­ta­ne­ous­ly. This is per­fect for our group rank­ing because we need to check two things at once: whether a row belongs to the same group as our cur­rent row, and whether its val­ue is greater than or equal to our cur­rent row’s value.

The basic for­mu­la struc­ture looks like this:

=COUNTIFS(group_range, current_group, value_range, “>=”&current_value)

Let’s break down how this works in our example:

  • group_range — This is the col­umn con­tain­ing our group­ing vari­able (town names in col­umn A)
  • current_group — This refers to the town in the cur­rent row we’re eval­u­at­ing (A2 for the first data row)
  • value_range — The col­umn con­tain­ing the val­ues we want to rank (rev­enue)
  • current_value — The spe­cif­ic val­ue in the cur­rent row that we’re try­ing to rank

Step-by-Step Implementation

To imple­ment this rank­ing sys­tem in your own spread­sheet, fol­low these steps:

1. First, ensure your data is orga­nized with a clear group­ing vari­able (like town, region, cat­e­go­ry, etc.)

2. Cre­ate a new col­umn for your rank results

3. In this col­umn, enter the COUNTIFS for­mu­la, which will:

  • Check the group col­umn to find rows in the same group as the cur­rent row
  • Check the val­ue col­umn to find val­ues greater than or equal to the cur­rent row’s value
  • Count how many rows meet both cri­te­ria — this count becomes the rank

The for­mu­la uses absolute ref­er­ences (with F4 to cre­ate $ signs) for the ranges and rel­a­tive ref­er­ences for the cur­rent val­ues. This ensures that when you copy the for­mu­la down, it still refers to the cor­rect columns while adapt­ing to each row’s spe­cif­ic values.

Analyzing the Results

After apply­ing the COUNTIFS for­mu­la to our data, we can see that each item gets a rank with­in its group. In our example:

For the town of Moria, we have ranks from 1 to 5

For Iron­forge, ranks range from 1 to 4

For Azmarin, ranks go from 1 to 3

What’s par­tic­u­lar­ly note­wor­thy is that the ranks don’t have to appear in sequence in your spread­sheet. When we sort the entire dataset by rev­enue from largest to small­est, we can see that the high­est-ranked items from each town appear mixed togeth­er. For exam­ple, after the top per­form­ers from Moria, we might see Iron­forge’s top per­former, then more from Moria, then per­haps Azmar­in’s best.

This demon­strates how our rank­ing works inde­pen­dent­ly with­in each group, regard­less of where the items appear in the sort­ed list. The sec­ond-ranked item in Azmarin might appear as the tenth row in our sort­ed data, but it still cor­rect­ly shows as rank 2 with­in its group.

Practical Applications

This rank­ing tech­nique has numer­ous prac­ti­cal applications:

  • Sales analy­sis — Iden­ti­fy top-per­form­ing prod­ucts with­in each category
  • Employ­ee per­for­mance — Rank staff with­in depart­ments or regions
  • Tour­na­ment results — Rank com­peti­tors with­in age groups or divisions
  • Aca­d­e­m­ic per­for­mance — Rank stu­dents with­in class­es or subjects
  • Mar­ket analy­sis — Com­pare per­for­mance of stocks with­in indus­try sectors

By imple­ment­ing this group rank­ing sys­tem, you can quick­ly iden­ti­fy pat­terns that might oth­er­wise be obscured when look­ing at data as a whole. It allows you to make fair com­par­isons with­in rel­e­vant peer groups rather than across dis­sim­i­lar categories.

Additional Tips for Working with Group Rankings

When imple­ment­ing group rank­ings in your spread­sheets, con­sid­er these help­ful tips:

Col­or-cod­ing your data by groups (as shown in my video) makes it much eas­i­er to visu­al­ly iden­ti­fy the dif­fer­ent cat­e­gories and under­stand the rank­ings at a glance.

You can eas­i­ly mod­i­fy the rank­ing log­ic by chang­ing the oper­a­tor in the for­mu­la. For exam­ple, if you want to rank from small­est to largest instead, you would use “<=” instead of “>=” in your COUNTIFS formula.

For ties (when mul­ti­ple items have the same val­ue), this for­mu­la will assign the same rank to all tied items. If you need to han­dle ties dif­fer­ent­ly, you might need to use more com­plex for­mu­las or addi­tion­al columns.

Remem­ber that this tech­nique works with any type of numer­i­cal data you want to rank — sales fig­ures, scores, times, quan­ti­ties, or any oth­er mea­sur­able met­ric — as long as you have a clear group­ing variable.

Remove Top or Bottom Rows Automatically

Remove Top or Bottom Rows Automatically

Dynam­i­cal­ly remov­ing top and bot­tom rows in Pow­er Query can sig­nif­i­cant­ly stream­line your data clean­ing process when deal­ing with incon­sis­tent data imports. This tech­nique allows you to auto­mat­i­cal­ly elim­i­nate unnec­es­sary head­er rows or foot­er infor­ma­tion based on spe­cif­ic con­di­tions rather than fixed row counts, mak­ing your data trans­for­ma­tion process more robust and adapt­able to chang­ing source files.

The abil­i­ty to use con­di­tions rather than sta­t­ic num­bers is par­tic­u­lar­ly valu­able when work­ing with reg­u­lar­ly updat­ed reports that may con­tain vary­ing amounts of meta­da­ta or sum­ma­ry information.

In my video, I demon­strate how to imple­ment this dynam­ic row removal tech­nique that I learned at an Excel Lon­don Meetup:

Understanding the Problem with Static Row Removal

When import­ing data from text files, CSV files, or oth­er sources, you often encounter extra­ne­ous infor­ma­tion at the top and bot­tom of your dataset. These might include title rows, explana­to­ry notes, sum­ma­ry sta­tis­tics, or foot­er infor­ma­tion that aren’t part of the actu­al data you need to ana­lyze. Using Pow­er Query’s stan­dard “Remove Top Rows” or “Remove Bot­tom Rows” func­tions with a fixed num­ber works fine when your source data struc­ture nev­er changes, but becomes prob­lem­at­ic when the num­ber of these rows varies.

In the exam­ple shown in my video, we have mul­ti­ple rows of meta­da­ta before the actu­al head­er row (which con­tains “Date” as the first col­umn val­ue), and sev­er­al rows of addi­tion­al infor­ma­tion at the bot­tom of the data that need to be removed. There are also some miss­ing val­ues through­out the data that make sim­ple fil­ter­ing ineffective.

Dynamically Removing Top Rows Based on Conditions

The con­ven­tion­al approach to remov­ing top rows in Pow­er Query involves spec­i­fy­ing a fixed num­ber. How­ev­er, this can be prob­lem­at­ic when the num­ber of head­er rows changes. The dynam­ic solu­tion involves using a con­di­tion rather than a fixed count.

Here’s how to imple­ment this technique:

  1. Go to the Home tab in Pow­er Query Editor
  2. Select “Remove Rows” and then “Remove Top Rows”
  3. Instead of enter­ing a num­ber, mod­i­fy the for­mu­la to use the “each” key­word fol­lowed by a condition

The for­mu­la will look some­thing like this: each [Column1] <> “Date” (assum­ing “Date” is the head­er text in your first col­umn). This tells Pow­er Query to keep remov­ing rows until it finds a row where the first col­umn con­tains the text “Date”.

The Technical Details of the Table.Skip Function

Behind the scenes, Pow­er Query uses the Table.Skip func­tion when you remove top rows. This func­tion has a hid­den capa­bil­i­ty that isn’t obvi­ous from the user inter­face — it can accept either a count or a con­di­tion parameter.

When using a con­di­tion, the syn­tax changes from sim­ply pro­vid­ing a num­ber to using the format:

each [condition]

The con­di­tion is eval­u­at­ed for each row, start­ing from the top, and rows are removed until the con­di­tion is no longer true. This allows for dynam­ic adap­ta­tion to vary­ing source data structures.

Dynamically Removing Bottom Rows

Sim­i­lar­ly, we can apply the same con­cept to remove rows from the bot­tom of our dataset. This is par­tic­u­lar­ly use­ful when deal­ing with files that con­tain sum­ma­ry infor­ma­tion, notes, or oth­er foot­er data that should be exclud­ed from analysis.

The process for remov­ing bot­tom rows dynam­i­cal­ly is:

  1. Go to the Home tab in Pow­er Query Editor
  2. Select “Remove Rows” and then “Remove Bot­tom Rows”
  3. Replace the sta­t­ic num­ber with a con­di­tion using the “each” keyword

For exam­ple, you might use a for­mu­la like: each [Mer­chant] = “” to remove rows from the bot­tom where the Mer­chant col­umn con­tains an emp­ty text string. Or you might use each [Rev­enue] = null to remove rows where the Rev­enue col­umn con­tains null values.

Handling Different Types of Empty Values

When work­ing with bot­tom rows, it’s impor­tant to under­stand the dif­fer­ent types of emp­ty val­ues that might appear in your data:

  • Emp­ty text strings — rep­re­sent­ed by “” in formulas
  • Null val­ues — rep­re­sent­ed by null in formulas
  • Miss­ing val­ues — which might be null or emp­ty depend­ing on the data source

In the video demon­stra­tion, I show how to han­dle both emp­ty text strings and null val­ues as con­di­tions for remov­ing bot­tom rows. The key is to iden­ti­fy which col­umn and which type of emp­ty val­ue reli­ably indi­cates the foot­er sec­tion of your data.

Practical Applications and Benefits

This dynam­ic row removal tech­nique is par­tic­u­lar­ly valu­able in sev­er­al scenarios:

When work­ing with reg­u­lar­ly updat­ed reports where the struc­ture might change slight­ly between ver­sions, this approach ensures your Pow­er Query solu­tion remains robust. It’s also help­ful when deal­ing with data exports from sys­tems that include vary­ing amounts of meta­da­ta or when con­sol­i­dat­ing mul­ti­ple files that might have dif­fer­ent head­er structures.

The major ben­e­fits include:

  • More resilient data trans­for­ma­tion process­es that don’t break when source for­mats change slightly
  • Reduced need for man­u­al inter­ven­tion when pro­cess­ing new data
  • Abil­i­ty to han­dle files with incon­sis­tent struc­ture automatically
  • Greater flex­i­bil­i­ty com­pared to sta­t­ic row removal or sim­ple filtering

This tech­nique demon­strates the pow­er of M lan­guage in Pow­er Query, allow­ing for solu­tions that go beyond what’s imme­di­ate­ly avail­able in the user inter­face. By under­stand­ing and lever­ag­ing these more advanced capa­bil­i­ties, you can cre­ate more robust data trans­for­ma­tion processes.

Important Considerations

When imple­ment­ing this tech­nique, keep in mind a few impor­tant points:

The con­di­tion you use must reli­ably iden­ti­fy the bound­ary between the rows you want to keep and those you want to remove. Choose col­umn val­ues that are con­sis­tent­ly present (or con­sis­tent­ly absent) at these bound­aries. Also be aware that if your con­di­tion nev­er eval­u­ates to false, you could poten­tial­ly remove all rows from your dataset, so test­ing with rep­re­sen­ta­tive sam­ple data is essential.

Addi­tion­al­ly, remem­ber that this tech­nique works even when you have miss­ing val­ues in your actu­al data. As shown in the video, the rows are only removed when they match the spe­cif­ic con­di­tion you’ve defined, allow­ing rows with some miss­ing val­ues to be retained as long as they don’t match your removal condition.

Excel Pivot Table Hack: Display Percentages of Parent Row Totals

Excel Pivot Table Hack: Display Percentages of Parent Row Totals

Piv­ot tables offer a pow­er­ful way to ana­lyze data, par­tic­u­lar­ly when you need to under­stand pro­por­tions with­in hier­ar­chi­cal cat­e­gories. In this tuto­r­i­al, I’ll show you how to quick­ly add sums in a piv­ot table and dis­play val­ues as a per­cent­age of their par­ent row, allow­ing for imme­di­ate visu­al­iza­tion of how indi­vid­ual items con­tribute to their cat­e­go­ry totals.

This tech­nique is espe­cial­ly valu­able when ana­lyz­ing sales data across prod­uct cat­e­gories and indi­vid­ual items.

Watch my step-by-step video tuto­r­i­al below to see this process in action:

Setting Up Your Pivot Table

To begin cre­at­ing an infor­ma­tive piv­ot table with per­cent­age cal­cu­la­tions, we need to start with a sim­ple dataset that con­tains hier­ar­chi­cal infor­ma­tion. In my exam­ple, I’m using a dataset that includes cat­e­gories (such as fruits, veg­eta­bles, and sweets) along with the spe­cif­ic prod­ucts with­in each cat­e­go­ry and their cor­re­spond­ing rev­enue figures.

The process of cre­at­ing the piv­ot table is straightforward:

  1. Select your data range
  2. Nav­i­gate to the Insert tab in the Excel ribbon
  3. Click on “Piv­ot Table”
  4. Choose to place the piv­ot table on an exist­ing work­sheet (I select­ed cell F1 in my demonstration)
  5. Click “OK” to cre­ate the basic piv­ot table structure

Once your piv­ot table frame­work is estab­lished, you’ll need to struc­ture it prop­er­ly to show both cat­e­gories and their con­stituent prod­ucts. In the Piv­ot­Table Fields pan­el, drag the appro­pri­ate fields to build your hier­ar­chi­cal view.

Structuring Your Pivot Table

For prop­er hier­ar­chi­cal analy­sis, you’ll want to arrange your fields in a log­i­cal order. In the Rows sec­tion of the Piv­ot­Table Fields pan­el, add your Cat­e­go­ry field first, fol­lowed by the Prod­uct field. This cre­ates a nest­ed struc­ture where prod­ucts appear under their respec­tive categories.

For the val­ues sec­tion, we need to add the Rev­enue field twice — once to show the raw sum and once to show the per­cent­age of par­ent. Sim­ply drag the Rev­enue field to the Val­ues area twice. By default, Excel will sum these val­ues, which is exact­ly what we want for this analysis.

Changing the Layout

By default, Excel dis­plays piv­ot tables in com­pact form, but for bet­ter read­abil­i­ty, I pre­fer the tab­u­lar lay­out. To change this:

  1. Go to the Design tab under Piv­ot­Table Tools
  2. Click on “Report Layout”
  3. Select “Show in Tab­u­lar Form”

This adjust­ment sep­a­rates the Cat­e­go­ry and Prod­uct into dis­tinct columns, mak­ing your data more read­able and eas­i­er to ana­lyze at a glance.

Adding Percentage of Parent Row

Now comes the key part — trans­form­ing one of our rev­enue columns to show per­cent­age of par­ent row. This cal­cu­la­tion will show how each prod­uct con­tributes pro­por­tion­al­ly to its cat­e­go­ry total, and how each cat­e­go­ry con­tributes to the grand total. Fol­low these steps:

  1. Right-click on any cell with­in the sec­ond Sum of Rev­enue column
  2. Select “Show Val­ues As” from the con­text menu
  3. Choose “% of Par­ent Row Total”

This sim­ple change trans­forms the raw num­bers into per­cent­ages, giv­ing you imme­di­ate insight into the pro­por­tion­al con­tri­bu­tion of each item. For instance, in my exam­ple, you can now see that apples rep­re­sent approx­i­mate­ly 35% of all fruit sales, while the fruits cat­e­go­ry as a whole rep­re­sents about 41% of total sales across all categories.

Understanding the Results

After apply­ing the per­cent­age of par­ent row cal­cu­la­tion, your piv­ot table auto­mat­i­cal­ly adjusts to show mean­ing­ful pro­por­tions at every level:

  • Indi­vid­ual prod­ucts show their per­cent­age con­tri­bu­tion to their imme­di­ate category
  • Cat­e­go­ry subto­tals show their per­cent­age con­tri­bu­tion to the grand total
  • The grand total always equals 100%

In my demon­stra­tion, this clear­ly showed that sweets account­ed for approx­i­mate­ly 40% of total sales, veg­eta­bles for about 18%, and fruits for approx­i­mate­ly 41%. With­in each cat­e­go­ry, you can sim­i­lar­ly see the pro­por­tion­al con­tri­bu­tion of each product.

Finalizing Your Pivot Table

To make your piv­ot table more under­stand­able, it’s impor­tant to rename the col­umn head­ers to accu­rate­ly reflect what each col­umn rep­re­sents. In our case:

  1. Change the head­ing of the first sum col­umn to sim­ply read “Sum”
  2. Rename the sec­ond col­umn to “Per­cent­age of Parent”

These descrip­tive head­ers ensure that any­one view­ing your piv­ot table will imme­di­ate­ly under­stand what the num­bers rep­re­sent with­out need­ing addi­tion­al explanation.

With these adjust­ments com­plete, you now have a com­pre­hen­sive piv­ot table that not only shows the raw rev­enue fig­ures but also clear­ly illus­trates the pro­por­tion­al rela­tion­ships between cat­e­gories and their con­stituent prod­ucts. This dual-view approach pro­vides both absolute and rel­a­tive per­spec­tives on your data, enabling more nuanced analy­sis and decision-making.

This tech­nique is par­tic­u­lar­ly valu­able when ana­lyz­ing sales per­for­mance, bud­get allo­ca­tions, or any hier­ar­chi­cal data where under­stand­ing pro­por­tion­al rela­tion­ships is impor­tant. By visu­al­iz­ing both raw num­bers and per­cent­ages simul­ta­ne­ous­ly, you gain deep­er insights into your data struc­ture and can more effec­tive­ly com­mu­ni­cate those insights to others.

How to Calculate Hierarchy Levels in Power Query

How to Calculate Hierarchy Levels in Power Query

In this tuto­r­i­al, I demon­strate a prac­ti­cal appli­ca­tion of recur­sive func­tions in Pow­er Query to cal­cu­late hier­ar­chy lev­els in orga­ni­za­tion­al struc­tures or MLM sys­tems. Using a cus­tom func­tion with recur­sion, we can effi­cient­ly deter­mine each per­son­’s posi­tion in a hier­ar­chi­cal struc­ture based on their refer­rer rela­tion­ships, pro­vid­ing valu­able insights for orga­ni­za­tion­al analy­sis and reporting.

Under­stand­ing hier­ar­chy lev­els is essen­tial for visu­al­iz­ing report­ing struc­tures, track­ing MLM down­lines, or map­ping any par­ent-child rela­tion­ships in your data.

Understanding the Problem: Hierarchy Levels in Organizations

In many orga­ni­za­tion­al struc­tures, par­tic­u­lar­ly in mul­ti-lev­el mar­ket­ing (MLM) sys­tems or cor­po­rate hier­ar­chies, under­stand­ing the lev­el depth of each mem­ber is cru­cial. The lev­el rep­re­sents how many steps a per­son is from the top of the orga­ni­za­tion. For instance, in our exam­ple, John is at the top (lev­el 0), N is direct­ly below John (lev­el 1), and Thomas is below N (lev­el 2).

Our sam­ple data con­tains an ID col­umn that unique­ly iden­ti­fies each per­son and a Refer­rer col­umn that indi­cates who brought that per­son into the orga­ni­za­tion. The refer­ral rela­tion­ship estab­lish­es the hier­ar­chi­cal struc­ture we need to ana­lyze. Our goal is to cal­cu­late each per­son­’s hier­ar­chy lev­el auto­mat­i­cal­ly using Pow­er Query’s recur­sive capabilities.

Setting Up Power Query

To begin work­ing with our data, we need to import it into Pow­er Query where we can cre­ate and apply our recur­sive function:

  1. Select any cell in your data table
  2. Go to the Data tab
  3. Click From Table/Range to import your data into Pow­er Query

This imports your data con­tain­ing the ID and Refer­rer columns into the Pow­er Query Edi­tor, where we can start build­ing our solution.

Creating a Recursive Function to Calculate Hierarchy Levels

The core of our solu­tion is a cus­tom func­tion that can call itself (recur­sion) to track up through the hier­ar­chy until it reach­es the top. Here’s how to cre­ate it:

  1. In the Pow­er Query Edi­tor, go to the Home tab
  2. Click New Source > Oth­er Sources > Blank Query

Now we need to define our func­tion. Our func­tion will require two para­me­ters: the per­son­’s ID we want to cal­cu­late the lev­el for and the com­plete table of peo­ple data to ref­er­ence. The func­tion will:

  1. Find the row for the cur­rent person
  2. Get their refer­rer’s ID
  3. Check if they have a referrer
  4. If they don’t (they’re at the top), return 0
  5. If they do have a refer­rer, call the same func­tion for the refer­rer and add 1 to the result

The M code for our func­tion looks like this:

(per­son­ID, personTable) =>
let
per­son­Row = Table.SelectRows(personTable, each [ID] = personID){0},
per­son­AboveID = personRow[Referrer],
result = if per­son­AboveID = null
then 0
else @HierarchyLevel(personAboveID, per­son­Table) + 1
in
result

Make sure to name your func­tion Hier­ar­chyLev­el so that the recur­sive ref­er­ence to itself works prop­er­ly. The @ sym­bol in front of the func­tion name empha­sizes that we’re call­ing the same func­tion again.

Applying the Function to Our Data

After cre­at­ing our func­tion, we need to apply it to every row in our data table:

  1. Go back to your main query with the import­ed data
  2. Click Add Col­umn > Invoke Cus­tom Function
  3. Select your Hier­ar­chyLev­el function
  4. For per­son­ID, select the ID column
  5. For per­son­Table, we need to ref­er­ence the cur­rent table

When set­ting the per­son­Table para­me­ter, we ini­tial­ly might try to ref­er­ence a col­umn name, but this will gen­er­ate errors. Instead, we need to ref­er­ence the entire table from the pre­vi­ous step. In Pow­er Query, we can do this by refer­ring to the pre­vi­ous step name.

Once cor­rect­ly con­fig­ured, the func­tion will cal­cu­late the hier­ar­chy lev­el for each per­son in our table. Thomas, who is referred by N (ID 2) who in turn is referred by John (ID 1), will show as lev­el 2. John, who has no refer­rer, will be at lev­el 0.

Testing and Validating the Recursion

To ver­i­fy our func­tion works cor­rect­ly, we can exam­ine the cal­cu­lat­ed lev­els for each per­son in our organization:

  • John (ID 1): Lev­el 0 (top of hier­ar­chy, no referrer)
  • Anne (ID 2): Lev­el 1 (referred by John)
  • Thomas (ID 5): Lev­el 2 (referred by Anne)
  • Paul: Lev­el 3 (referred by Thomas)

We can fur­ther test by chang­ing refer­rer rela­tion­ships. For exam­ple, if we change Paul’s refer­rer from Thomas (ID 5) to some­one who is already at lev­el 3, Paul would then become lev­el 4. After mak­ing such changes in the source data, we can sim­ply refresh our Pow­er Query to see the updat­ed hier­ar­chy levels.

Handling Edge Cases in Your Hierarchy

Our recur­sive func­tion han­dles sev­er­al impor­tant edge cases:

  1. Top-lev­el mem­bers (those with null refer­rers) are assigned lev­el 0
  2. The func­tion will work for orga­ni­za­tions of any depth, con­tin­u­ing to recurse up the chain until it reach­es the top
  3. If the data con­tains cir­cu­lar ref­er­ences (Per­son A refers to Per­son B who refers back to Per­son A), the recur­sion could cre­ate an infi­nite loop — con­sid­er adding error han­dling for this sce­nario in real applications

In a real-world sce­nario, you might want to enhance this func­tion to han­dle more com­plex require­ments, such as detect­ing cir­cu­lar ref­er­ences or pro­cess­ing mul­ti­ple hier­ar­chies with­in the same dataset.

Loading the Results Back to Excel

Once you’re sat­is­fied with your hier­ar­chy lev­el calculations:

  1. In the Pow­er Query Edi­tor, go to Home > Close & Load
  2. Your data table with the new hier­ar­chy lev­el col­umn will appear in Excel
  3. Any time your hier­ar­chy changes, sim­ply refresh the query to recal­cu­late all levels

This pow­er­ful tech­nique allows you to main­tain an up-to-date view of your orga­ni­za­tion­al struc­ture with min­i­mal effort. The recur­sive approach effi­cient­ly han­dles even large hier­ar­chies with­out requir­ing com­plex for­mu­las or man­u­al tracking.

With this solu­tion in place, you can eas­i­ly build reports and visu­al­iza­tions that lever­age hier­ar­chy lev­el infor­ma­tion, enabling bet­ter insights into your orga­ni­za­tion­al struc­ture, MLM down­lines, or any hier­ar­chi­cal data you’re work­ing with.

How to Split Text by Position in Power Query

How to Split Text by Position in Power Query

Split­ting text by length in Pow­er Query can trans­form clut­tered data into orga­nized, usable infor­ma­tion with­out com­plex for­mu­las. This tech­nique allows you to break down text strings into sep­a­rate columns based on spe­cif­ic char­ac­ter posi­tions, mak­ing it espe­cial­ly use­ful when deal­ing with fixed-width data for­mats that con­tain mul­ti­ple pieces of information.

The real pow­er of this approach lies in its abil­i­ty to han­dle irreg­u­lar split­ting require­ments where each sec­tion has a dif­fer­ent length.

In my video, I demon­strate the com­plete process of split­ting text by length in Pow­er Query:

Understanding the Data Structure

When work­ing with text data that needs to be split, it’s essen­tial to first ana­lyze the struc­ture of your text. In the demon­stra­tion, I work with a dataset where each text string con­tains sev­er­al pieces of infor­ma­tion with vary­ing lengths:

  • Per­son infor­ma­tion (30 characters)
  • Delim­iter char­ac­ters (semi­colons, pipes) that need to be removed
  • Date infor­ma­tion (appear­ing as numbers)
  • Cur­ren­cy val­ues in dif­fer­ent formats

The chal­lenge lies in the fact that each sec­tion has a dif­fer­ent length, mak­ing stan­dard split func­tions less effec­tive. This is pre­cise­ly where Pow­er Query’s split by posi­tion fea­ture becomes invaluable.

Importing Data to Power Query

The first step in the process is to import your data into Pow­er Query. This can be done eas­i­ly by select­ing your data table and using the From Table/Range option in the Data tab. Once your data is in Pow­er Query, you’ll have access to pow­er­ful trans­for­ma­tion tools that aren’t avail­able in stan­dard Excel.

Pow­er Query pro­vides a user-friend­ly inter­face where you can see your data and apply var­i­ous trans­for­ma­tions step by step. This visu­al approach makes it eas­i­er to track changes and ensure that your data is being processed correctly.

Splitting Text by Position

With the data import­ed into Pow­er Query, we can now split the text col­umn based on spe­cif­ic posi­tions. Here’s how to do it:

  1. Go to the Home tab in Pow­er Query
  2. Select Split Col­umn and choose “By Posi­tions” (not “By Num­ber of Characters”)
  3. Enter the spe­cif­ic posi­tions where you want to split the text

In the exam­ple, I need­ed to split at posi­tions 0, 30, 31, 39, and 41. It’s impor­tant to note that Pow­er Query counts from zero for the first posi­tion, not one. These num­bers rep­re­sent the start­ing points for each sec­tion of text.

After press­ing OK, Pow­er Query cre­ates new columns based on these posi­tion splits. The result is five sep­a­rate columns, each con­tain­ing a dis­tinct part of the orig­i­nal text string.

Refining the Split Data

Renaming and Removing Columns

After split­ting the text, we need to orga­nize our data by giv­ing mean­ing­ful names to the impor­tant columns and remov­ing unnec­es­sary ones. In the for­mu­la bar, I renamed the columns to reflect their content:

  • “Text.1” became “Per­son”
  • “Text.3” became “Date”
  • “Text.5” became “Pay­out”

For columns con­tain­ing delim­iters or oth­er unwant­ed infor­ma­tion (in this case, “Text.2” and “Text.4”), we can sim­ply delete them by select­ing them with Ctrl+click and press­ing the Delete key.

Correcting Data Types

Once we have our prop­er­ly named columns, we need to ensure that each col­umn has the cor­rect data type. In the demonstration:

  • The “Date” col­umn was ini­tial­ly rec­og­nized as an inte­ger and need­ed to be con­vert­ed to the date data type
  • The “Pay­out” col­umn con­tained cur­ren­cy val­ues in dif­fer­ent for­mats that need­ed prop­er interpretation

Pow­er Query can auto­mat­i­cal­ly detect and con­vert data types, but some­times man­u­al inter­ven­tion is nec­es­sary. By click­ing on the data type icon in the col­umn head­er, you can force Pow­er Query to inter­pret the data as a spe­cif­ic type.

Working with Regional Settings

An impor­tant aspect of work­ing with dates and cur­ren­cy val­ues is under­stand­ing how region­al set­tings affect data inter­pre­ta­tion. In Pow­er Query, you can adjust these set­tings to match the for­mat of your data.

To access these set­tings, go to:

  1. Options and Settings
  2. Query Options
  3. Cur­rent Workbook
  4. Region­al Settings

In my demon­stra­tion, the region­al set­tings were set to “Eng­lish (Unit­ed King­dom)” which allowed Pow­er Query to cor­rect­ly inter­pret the pound (£) cur­ren­cy sym­bols regard­less of their posi­tion in the text. If your data uses dif­fer­ent region­al for­mats, you can adjust these set­tings to match your needs.

For indi­vid­ual columns, you can also click on the data type icon and select “Using Locale” to spec­i­fy both the data type and region­al for­mat for that par­tic­u­lar col­umn. This gives you fine-grained con­trol over how Pow­er Query inter­prets your data.

Finalizing the Transformation

After com­plet­ing all the nec­es­sary trans­for­ma­tions — split­ting the text, renam­ing columns, remov­ing unnec­es­sary columns, and set­ting the cor­rect data types — the final step is to load the trans­formed data back into Excel.

From the Home tab, select “Close & Load” to export your prop­er­ly orga­nized table back to Excel. The result is a clean, struc­tured dataset with sep­a­rate columns for per­son infor­ma­tion, dates, and pay­ment val­ues, all with the appro­pri­ate data types.

This tech­nique of split­ting text by posi­tion in Pow­er Query is par­tic­u­lar­ly use­ful when deal­ing with fixed-width data exports from lega­cy sys­tems, stan­dard­ized report out­puts, or any sit­u­a­tion where text strings con­tain mul­ti­ple data points at known posi­tions. By mas­ter­ing this approach, you can quick­ly trans­form dense, com­bined text fields into orga­nized and usable data.