Subset filter in Apliqo UX


The 3 column charts in the screenshot show monthly sales forecast from 3 subsets in the row dimension: VIC stores, NSW stores and Like stores. Rather than creating multiple charts, is it possible to create only one chart but with a subset filter in the Dashboard Global Settings? Or any other way to achieve this? This may have a similar concept like in active form TM1rptrow with MDX subset filter.

Actually, this issue can easily be solved by adding 2 more dimensions in the cube, i.e., State and Store Group but I try to avoid this.



Hi @jliando

Currently you can only dynamically select row and column subsets for views and not for dashboards. However, what you want to do can easily be achieved in UX by adding a “helper dimension” to the dashboard filter and then using the settings service variables in the MDX for your rows or columns in the widgets displaying the chart.

As long as there is a defined naming convention for the element names in the helper dimension vs. the subset names it should be straightforward. To keep things simple for this example I will assume the element names in the helper dimension are the same as the subset names.

The helper dimension doesn’t have to be used in any of the widgets, in fact it doesn’t have to be used in any cubes at all. For your example let’s create a helper dimension called “Store Selection” and give it elements Vic stores, NSW stores, Qld Stores, etc. These element names should correspond exactly to subset names in the Store dimension (which I think from the screenshot is “Corp Profit Centre”).

Next add this new dimension to the dashboard filter. Click “Edit Mode” then the “+” to add a dimension to the global settings.

From the select dimension popup choose the “Store Selection” dimension.

Now you can use the context of whatever is selected in this dimension to pass into the widgets. Change the “List Type” in the widget(s) from “Subset” to “MDX” then depending on the name of the instance and dimensions your MDX will look something like …
{TM1SubsetToSet( [Corp Profit Center].[Corp Profit Center], "$<<7_Eleven.Store Selection.Store Selection>>" )}
The format for retrieving the context from the settings service (i.e. the filters) is $<<instanceName.dimName.hierName>>

You can also use this substitution variable to make dashboard and widget titles dynamic. You can probably also see that depending on the logic used to derive the members for the dynamic charts you probably don’t actually need to have subsets of the same name but you could just do it all on the fly with MDX.


Hi @cw-ch
Thank you for the tips and instruction, Scott. :+1:
I will try it and come back to you with the result.

It works! Many thanks @cw-ch.
So, this sintax can be used in MDX not just for a title. $<<7_Eleven.Store Selection.Store Selection>> .

Yes the substitution of the key $<<instanceName.dimensionName.hierarchyName>> for the context from the filter can be used in any text field in UX.


  1. The filter context is stored in the UX’s “settings service”. To rerieve and substitute the value the hierarchy doesn’t actually need to be in the global filter, the settings service will retrieve the last used value. (This is how context is passed between screens and follows the user around the application).
  2. The settings service actually stores 2 values for the currently selected member in each hierarchy.
    i) The principal element name
    ii) The display value
    In all display fields (e.g. Title, Info) the display value is automatically retrieved by the key <<instanceName.dimensionName.hierarchyName>>. For context passing and background fields (e.g. MDX) the key automatically resolves to the principal name. However, if you want to retrieve the display value when passing to MDX (e.g. in the case an attribute maps elements between 2 dimensions) then you can do this by using the alternate key <<instanceName.dimensionName.hierarchyName-alias>>
  3. Only global filter selections get stored in the setting service. In the case where an individual widget also displays filter(s) any changes won’t be passed back to the settings service

How do we access the user defaults stored in the Setting Service? I want a dashboard filter to always default to users default element, and if not populated the global default.

I read this question the 1st time and thought you were asking a (fairly basic) question about how the setting service works, but then I re-read and now not so sure that you don’t already know all that and are actually asking a more complicated question about how to use the default value regardless what the current setting service value is. As I’m not sure I will answer for both interpretations.

1st interpretation: How to set default values in the setting service
Global default values for key point of view hierarchies are defined in the contentStore cube }APQ UX Settings Service Dimensions. To do this at a minimum the dimension names for the key point of view dimensions for each instance need to be defined in the master list dimension }APQ UX Dimension. You can just manually edit the dimension and copy/paste the dimension names in using Arc and then manually populate the “IsUsed” and “IsUsedSettingService” flags and the default member value. Or you can set up the metadata syncing service to automate this. If using the metadata syncing then the only manual step you need to do as an administrator is to set the “IsUsedSettingService” flags. (You only really should do this for the key PoV dimensions which will be used in the filter a lot of the time).

Since you gave a link to the documentation then you already noticed that online documentation for the metadata syncing is something we are lagging behind on! The syncing service is done by a (Windows) command line execuitable which is compiled from a tm1py script. Here’s a link to the latest version. The zip contains the exe and a PDF with some pretty solid documentation of the parameters and options which can be used.

Once global default members have been set in the }APQ UX Settings Service Dimensions cube this automatically flows via rule into the }APQ UX Settings Service UserPreference cube. This is the cube that gets written back to via the provided “User Default Settings” UI. If you know in advance about individual users requiring different default values then you could preset these in the Settings Service User Preference cube. Otherwise just leave it up to the users to do it themselves.

On login UX will check in Settings Service User Preference cube and set the initial setting service value based on what is configured there. For any dashboard or view to use the setting service value what you need to do for any filter or fixed dimension is leave the “selected element” value blank.

Both @wwang and @crashedi know all of the above inside out and can help you with the setup if you have any issues or questions.

2nd interprretation: how to use the default value rather than the current setting service value
OK. Suppose you already knew all of the above and the real question is “regardless what the current settings service value is how could you make the filter value in a specific dashbord ALWAYS be what the user’s default value is?”

This scenario is pretty easily solveable, and probably solvable in multiple ways. But I think regardless of the specific solution it’s going to require a javascript function. Easiest solution I can think of would be a function that reads the user’s default value from the cube with tm1-ui-dbr and updates the setting service value back to the default value. If you wanted the dashboard to use the default PoV but leave the current setting service value unchanged when you navigate somewhere else then you would need something with more bells & whistles.

1 Like

Thanks @cw-ch I will check out the metadata sync. Both answers clear things up. The documentation does not mention that the default element must be blank for it to work, but that makes sense. The other thing I was missing, is that I can’t just refresh the page to test changes to the defaults since the settings are stored in the URL, I need to reopen the app completely.

This documentation gap has now been closed.