11 March 2024

5 ways to pass selections between Alternate States in Qlik Sense

Share this message
Passing 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.

Passing selections between Alternate States in Qlik Sense

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:

      • 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.

      With that out of the way, let’s explore the alternatives 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:

      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.

      Using the $:: syntax in Alternate States in Qlik Sense

      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.

      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.

      Using the p() function with Alternate States

      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 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 difference between $:: (colon) and p() when passing selections between Alternate States in Qlik Sense

      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.

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

      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.

      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:

      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:

      Intersecting selections in Alternate States in Qlik Sense

      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:

      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)

      Lowest granularity in fact table

      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:

      Passing selections between Alternate States at the lowest granularity

      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:

      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:

      Alternate States Action buttons

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

      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!

      Deciding on the best method to pass selections between Alternate States in Qlik Sense depends largely on your specific needs and the complexity of your dashboard. If your goal is simplicity and direct transfer of selections, the explicit assignment with double colon syntax or the implicit assignment with the P() function might be your best bet. These are straightforward and suitable for most common scenarios. However, if you’re dealing with a dashboard that requires syncing almost all selections except a few, or you want to simplify the process by focusing on the lowest level of granularity, then merging selections with the * operator or utilizing the lowest granularity might be more effective. It’s also important to consider the user experience and the clarity of the resulting data visualization when choosing your approach.

      The performance implications of each method can vary depending on the size of your dataset and the complexity of your Qlik Sense application. Generally, methods that involve less computation, like direct transfers of selections, are expected to perform faster than those requiring more complex logic, such as merging selections or dealing with the lowest granularity in large datasets. However, Qlik Sense is designed to handle large volumes of data efficiently, so any performance differences would likely be minimal in most cases. It’s always a good practice to test your application with the expected data volumes to ensure that the user experience remains smooth and responsive, adjusting your approach as needed based on performance outcomes.

      Efficiently troubleshooting issues with complex selections across Alternate States in Qlik Sense requires a methodical approach and a solid understanding of both the data model and the selection mechanisms. Initially, ensure that your data model is robust and well-structured, as this forms the foundation for effective Alternate State functionalities. A common pitfall is overlooking the data model’s impact on selection behaviors, leading to unexpected results.

      When an issue arises, start by isolating the problem. Break down the selection expressions to their simplest form and test each component individually. This step-by-step verification helps identify exactly where the breakdown occurs, whether it’s in the set analysis syntax, the data model relationships, or the interpretation of Alternate States themselves.

      We’ll cover troubleshooting methods in a future blog post, so sign up to our newsletter to stay up to date with our latest blog posts!

      Take your Qlik skills to the next level!

      Since 2013, the Masters Summit for Qlik is the premier advanced training for Qlik. Join us in Vienna and take your Qlik skills to the next level.

      Join the team!

      Do you want to work within a highly-skilled, informal team where craftsmanship, ingenuity, knowledge sharing and personal development are valued and encouraged? Check out our job openings.

      Expressions Friday Qlik Test Prep Qlik

      How can we help?

      Barry has over 20 years experience as a Data & Analytics architect, developer, trainer and author. He will gladly help you with any questions you may have.