5 ways to pass selections between Alternate States in Qlik Sense

At Bitmetric we continuously hone our skills, and we like to help you do the same. That’s why we regularly post a new Qlik certification practice question to our LinkedIn company page. Some time ago we asked the following Qlik Data Architect certification practice question about passing selections between different Alternate States.

Did you pick the right answer?

The correct answer is C

The correct answer to this question is {State1<Year=$::Year>}. However, there are more ways to transfer selections between states. We’ll cover those in the next section of this post. For those of you who aren’t familiar with Alternate States yet, you may want to check out these earlier posts first:

• Basics of Alternate States in Qlik Sense explains the basics of Alternate States, why they are useful and how to create and apply them

• Qlik Set Identifiers Alternate States are referred to in expressions with a set identifier. This post goes into detail on how that works

• Search the blog we may have written additional articles about Alternate States since this post was published, this link shows all related posts on our blog.

• Qlik Sense Set Analysis with the P() and E() functions one of the alternative ways to pass selections between Alternate States is using the P() and E() functions. This post explains how these functions work in Set Analysis

With that out of the way, let’s explore the alternatives for passing selections between Alternate States.

Methods for passing selections between Alternate States

We’ll cover the following 4 methods for passing selections between Alternate States:

• Explicit assignment with the double colon syntax

• Implicit assignment with the p() function

• Turn the selection around: merging with the * operator

• Passing the selection at the lowest granularity

• Using the Alternate State Actions extension

Of course, if you know of any other methods then do not hesitate to get in touch with us. We’re here to learn too! 😉

Let’s look at the various methods:

Explicit assignment with the double colon syntax

One method to share field selections across states involves the double colon syntax within Set Analysis. Although it’s commonly associated with the default state, $, this approach facilitates the transfer of selections from any given state to another. The format used is:

[State name]::

Take, for example, a dashboard that includes the default state $ and an Alternate State named StateA. To transfer the selection from the Quarter field in state $ to a revenue calculation in StateA, the following expression is used:

sum( { StateA <Quarter=$::Quarter>} Revenue)

In this expression, the segment Quarter=$::Quarter in the Set Analysis signifies substituting the Quarter field’s selection with that from the state $. It’s important to note that including the StateA Set Identifier is optional if the expression’s object is already positioned in StateA, as it will automatically inherit the state unless the expression specifies otherwise.

The animation below shows the outcome. The filter panes at the top are in the default state while the bar chart on the bottom is in StateA.

As mentioned before, the double colon syntax can be used to transfer the selection from any state to any other state. For example, the following expression transfers the Quarter selection in StateA to the expression in StateB:

sum( { StateB <Quarter=StateA::Quarter>} Revenue)

The p() function offers an alternative to the double colon syntax, let’s see how this works next.

Implicit assignment with the p() function

The p() function is used in Set Analysis to select all possible values in a field. It works very similar to the double colon syntax. Consider the previously used example where we transfer the selection on the Quarter field in the default state to the revenue calculation in StateA. We can achieve this with the p() function with the following expression:

sum( { StateA <Quarter=p( {$} Quarter)>} Revenue)

In this expression, the Quarter=p( {$} Quarter) part replaces the selection on the Quarter field with the possible values in the Quarter field in the default $ state. Note the use of nested Set Analysis within the p() function. In this case, we’re only using a Set Identifier, but if needed additional Set Analysis could be included.

The animation below shows the result. The filter panes at the top are, again, in the default state $ while the bar chart on the bottom is in StateA. As you can see, both options behave more or less similar in this scenario.

To transfer selections from a different state, we simply change the Set Analysis within the p() function. To transfer the selection on the Quarter field from StateA to StateB, we use:

sum( { StateB <Quarter=p( {StateA} Quarter)>} Revenue)

In the examples we’ve seen so far, both methods have the same result. We might conclude that both methods are identical. There is however a subtle difference.

The difference between $:: and p()

The difference between the colon syntax and the p() function becomes apparent when we make a selection on a different field than the field selection being transferred between Alternate States.

Consider the example below. The filter pane is in the default $ state, the bar charts below are in StateA. In the bar chart on the left the Quarter selection is copied using the colon syntax. In the bar chart on the right the p() function is used to transfer the selection. Watch what happens when we make a selection on the Year field:

The result between both methods is different! When the year 2024 is selected, only the quarters Q1 and Q2 are associated with that selection. The $:: (colon) method requires that we make an explicit selection in the field, or all values will be transferred. The p() method only transfers the possible, or implicit, values, so Q3 and Q4 are automatically excluded.

In the bar charts used in this example, it’s immediately clear that Q3 and Q4 are included for the year 2023. If instead of a bar chart a KPI object was used, this would be a lot less noticeable.

Which one is best?

You may wonder which option is best, and the answer to that is:

“It depends”

If you were to really push on the matter, at Bitmetric we think the p() method is usually the better option of the two, for the following reasons:

• It more clearly matches the result the user is expecting. In the example above, the user can clearly see that Q3 and Q4 are excluded from the selection. Why would these values suddenly be included in the selection again?

• It is more flexible. The $:: method only transfers the current selections in the specified field. The p() function allows for more flexible selections and searches because we can add additional Set Analysis. Of course, when this is used it should be clearly communicated to the user.

• It is more common and better understood. Certainly not a very good reason, but in our daily work we find that more developers are aware of the p() function than are aware of the $:: syntax. And those that know both don’t always know the difference. Hopefully this blog will change this somewhat, but when developing apps that might be maintained by others sometimes it’s best to just play it safe.

That being said, using either method can quickly become a hassle when dealing with many selections that need to be synchronized.

Transferring many selections between Alternate States

To transfer multiple selections with the double colon syntax, we have to apply it multiple times. For example, the following expression transfers both selections on the Quarter and Product fields from the default state to StateA:

sum( {StateA<Quarter=$::Quarter, Product=$::Product>} Revenue)

The same is true if we use the p() function:

sum( {StateA<Quarter=p( {$} Quarter), Product=p( {$} Product)>} Revenue)

You can imagine that this can get quite convoluted when dealing with many fields! Let’s see how to deal with that issue by looking at two possible solutions:

Turn the selection around: merging selections with the * operator

Sometimes, we want to synchronize nearly all fields, with only a few exceptions that shouldn’t be transferred. In that case, it’s often easier to turn the selection around by synchronizing all selections between states, except those fields that shouldn’t be synchronized.

Consider the example where we have three fields: Year, Quarter and Product. We want to synchronize Year and Quarter, and ignore Product. Instead of copying the selections for both fields, we can also turn it around:

sum( {StateA * $<Product=>} Revenue)

This Set Analysis expression results in the intersection between StateA and all selections in the default $ state, with the exception of selections made in the Product field.

The animation below shows the result:

In some cases, you may want to synchronize a lot of selections, while also excluding many other. In that scenario, the following solution may be useful:

Passing the selection at the lowest granularity

Like the previous method, this approach is also based on working smarter, not harder. Consider a very typical scenario when using Alternate States: using a single calendar to filter results in multiple states. Such a calender may contain fields such as Year, Quarter, Month, Date, etc.

We could transfer all these selections one by one:

sum( {StateA<Year=p({$} Year), Quarter=p({$} Quarter), Month=p({$} Month), Date=p({$} Date)>} Revenue)

There is nothing inherently wrong with this expression, it’s just very long. And, in the real world there may be many more calendar fields that the user could select.

Let’s rethink this a bit, all these time periods are just different aggregations of the lowest granularity in the Calendar table. In this case that’s the field %DateKey. (in a similar fashion, in the image below, all fields in the Products dimension are different ways group the %ProductKey)

Using this knowledge, we can write a smarter expression, one where we only pass the selections at the lowest granularity. For the earlier example, this results in the following expression:

sum( {StateA<[%DateKey]=p( {$} [%DateKey])>} Revenue)

This is a lot easier on the eye, and as an added benefit you will not have to update the expression in the case another calendar field is added to the sheet. For example, Week.

The animation below shows how the calendar selections are passed to the second state:

This has become a pretty long post, with lots of complex or confusing syntax, so we’ll end on a lighter note. The last option doesn’t require any complex expressions, while also giving the user quite a bit of flexibility:

Using the Alternate States Actions extension

This last method works different from the previous solutions, in that it’s not hard-coded into the expression but initiated by the user of the dashboard. The Alternate States Actions extension, developed by Christof Schwarz, adds buttons that let you copy selections between states, as well as clear individual states. This mimicks functionality that was available in QlikView, the predecessor to Qlik Sense.

The animation below shows the extension in action:

Currently the extension is limited to only copying the entire selection instead of individual fields. You can find this extension on Christof’s Github.

Wrapping up

To wrap up, the various methods for passing selections between Alternate States in Qlik Sense, including explicit and implicit assignments, merging selections, and utilizing the lowest granularity, offer practical solutions for enhancing dashboard functionality. The Alternate States Actions extension further simplifies working with Alternate States. Each method has their own pro’s and cons, but with these solutions in your arsenal you can probably solve every Alternate States challenge.

Until next time!

FAQ

More from the Bitmetric team