Ordering of measures and dimensions within explore field list?

(Max Beaumont) #1

Is there any way to control the ordering of fields within your explore field list, other than the default alphanumeric sort?

This is how one of my views in my explore currently looks:

This is how I want it to look. The only way I know how to achieve this is what I’ve done, adding prefixes like “Y” and “Z” to force these groups to the bottom of the list:

This works, but it doesn’t look good and may confuse the end users.

Is there an equivalent to the order_by_field functionality, where we can apply a sort key behind the scenes to control the ordering of fields?

(Chris Seymour) #2

Hey @MaxBeaumont,

One other way you could achieve this ordering without changing the appearance of the labels would be to add spaces to the front of the labels using the label parameter. The alphabetizing will take the spaces into account for the order, but the extra space won’t be surfaced in the labels themselves. I realize this is a somewhat hacky solution though, so I’ll let the product team know that it would be great to specify this ordering directly!

(Ravi Mody) #3

Hi, I just wanted to second this request, it would be great to be able to sort an explore list by the original ordering in a view, the current sorting may confuse end users!

(Ian) #4

Likewise, we have retention measures - 2,7,14,30,60,90,180 for example which leads to many many spaces to get them to appear in the order I need, works but not ideal!

(Chris Seymour) #5

Hey @ravimody and @IanT,

Thanks for your feedback! I can see how the workaround I suggested can be unwieldy especially for views with many fields, so I’ll pass along that detail to the product team as well.

(Stijn Lambert) #6


Just wanted to +1 this request …
Although the suggested “spaces” hack could offer a workaround, i assume this could interfere with the new localisation-feature … It would be great if we could define the order of our views ourselves, instead of relying on the alphabetical sort …


(jonathan.reinhard) #7

Hey @stijn,

I have added the +1 for you on the feature request.


(Laurent Stanevich) #8

+1 from me on this feature, as well.

If I can offer a suggestion on implementation – this has been a pretty common need in apps I’ve developed over time. I’ve generally found the most straightforward, robust approach to be allowing users to assign any given item a “rank index” – just an integer field that’s used as the primary sort key. That allows people to start off with broad “100”, “200”, “300” assignments to manage the overall prioritization, but still have a lot of room to slot in specific exceptions, if they need (a la BASIC :wink: ).