Exploring Field Parameters in Power BI

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.

Modelling

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.


Calculation Groups

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.

9 thoughts on “Exploring Field Parameters in Power BI

  1. great examples Kane.
    Only don’t understand how you connected the “Field Type” table to the “Columns” Field Parameter in the first example. Per Field Type you have 1 or more columns, 1:n relation. Did you then add a column to the generated Field parameter table, which is the unique key of the Field Type?

    Liked by 1 person

    1. Thanks Ron 😊,
      I used the sort order in the field parameter as a key to join the “Field Type” table. So the “Field Type” table mapped together the items in the field parameter with a type using the order column as the identifier.

      Like

      1. Hi Kane

        My brain gets stuck because i can’t get rid of mu thought there is a one to many relation from Field Type table to Fields Parameter table. Let me explain my thoughts.

        Ok, so you have a fields parameter containing all the needed fields of Customer and Product. Sort order field going from 1 to, let’s say, 15. 7 Customer fields, 8 Product fields
        Then you created a Field Type table, containing only two rows:
        – Customer Fields
        – Product Fields??
        But one row in the Field Type table, for instance ‘Customer Fields’ is related to 7 rows in Fields parameter.
        One to many relation. So in my belief you should add a column to the Field Type table, some number.
        For Customer it is filled with 1, for Product with 2.
        Then you adjust the Fields parameter table, add an extra column that contains 1 for Customer fields and 2 for Product fields. Then there you have the 1:n relation

        Looking forward to your reaction

        Like

      2. Hi Ron,

        I cant post a screenshot in the comment unfortunately but I will try and explain.
        The Field Type table has two columns, a key ( say 1- 15 ) and an attribute column (Customer Fields, Product Fields). So, Customer Fields might have keys 1-7 and Product Fields may have keys 8-15. So there are 15 rows in the Field Type table. Filtering to Customer Fields filters keys 1 to 7 which in turn filters only those fields in the field parameter. You actually get a one to one relationship but you can change this to be a one to many.

        Like

      3. Hi Kane, I just gave it a try.
        My FieldType table has two columns, fieldkey and attribute. Just like yours. But it only has two rows:
        Attribute Customer with fieldkey 1, attribute Product with fieldkey 2.
        Next I add a column to the FieldsParameter table, let’s call it parmkey, and fill it wit 1 for Customer Fields and 2 for Product Fields. Then I create a 1:n relation between fieldkey and parmkey. And it works.
        By the way, thnx for your valuabe examples.

        Liked by 1 person

      4. Glad you got it working, it’s nice that you can add columns to field parameters so have the freedom to join them with other tables however you wish. The only upside to the method I used is that you don’t need to add columns to the field parameter. In saying that, the method you used has a lower cardinality FieldType table and is a more traditional setup. Cheers

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s