Like many, I was very excited to see the new Field Parameters feature that shipped in preview in the latest May 2022 release. It enables you to do some things that used to be complex in a really easy way.
I thought I would share some initial things I have discovered while exploring the feature. Some interesting use cases will start to appear I am sure once we get general availability and start using the functionality in projects.
The thing that got me most excited is that Field Parameters are compatible with data modelling! You can add columns and create relationships with the tables generated. This means you can easily connect new tables to filter field parameters with a slicer. Here I have a single “Columns” Slicer that can show either Customer table columns or Product table columns depending on the “Field Type” slicer selection. To set this up, I just created a “Field Type” table and connected it to the “Columns” Field Parameter using the ordinal ( which can make a handy key for creating relationships ).
Filtering your Field Parameters with a slicer allows you to save more precious space if you are exposing a lot of fields to users. You could expose an entire model of columns in a small area with a slicer for tables and a slicer for columns. I think the modelling capability really opens Field Parameters up to implement some interesting solutions. I’m looking forward to see some of the creative uses for them.
Interaction between Field Parameters
The ability to create relationships means we can connect Parameter Fields together. This allows you to do things like below where I am returning different metrics in one slicer depending on which column is chosen in the first slicer. To implement this I just created a table that mapped the desired combination of ordinals together and used it as a bridge between the two Parameter Fields.
Filtering the Model
Because the Field Parameters are disconnected tables there is a lot of freedom to implement this sort of modelling solutions without harming your perfect star schema. You can also easily add columns and relationships to Field Parameters that do filter your model though. In this example, I’ve made it so that when we filter by the Country Field Parameter, we also filter only customers who are Companies and when we Filter by the City Field Parameter, we also filter only customers who are people.
This is achieved by adding the Customer Type (from the Customer dimension) to the Field Parameter then creating a relationship with the Customer dimension.
We can reference one field parameter in another field parameter but measures don’t appear to work anymore out of the box once you do. Thankfully calculation groups work when added to Field Parameters though! This means we have an easy way to switch between different calculation groups.
There is some functionality crossover between Field Parameters and Calculation Groups so the question of what to use when arises. In my mind, the crossover is using measures in a slicer or axis. For this, Field Parameters are much simpler to setup and do not require an external tool. Format strings for the measures are easily dealt with as they carry through from the original measure but calculation groups still have the flexibility to customize format strings. Calculation Groups also have the benefit of allowing further logic to be applied for advanced uses such as only applying to a specific measure. So for simple uses Field Parameters are the best option and calculation groups are only needed for advanced cases when Field Parameters don’t suffice. Apart from this one crossover area, the functionality is completely different. Field Parameters allow you to change column inputs in visuals and Calculation Groups allow you to apply transformation logic to measures as a column filter. By combining the two we can allow users to choose different sets of transformation logic to apply to measures in visuals.
Its a unique feature, the simplicity of use and the fact that you can integrate it in a model with relationships and calculation groups, make it a powerful tool for solving complex requirements.