Skip to main content
Needs feedback

Make the activated detail tab smarter when switching rows to support different variants

Related products:Universal UIIndicium Service TierUI/UX
  • May 22, 2026
  • 3 replies
  • 37 views
P
Captain
Forum|alt.badge.img+8

Often there are situations where you want to show a different tab-variant as a detail tab based on a specific property of the selected row in the main grid. This is possible by making multiple references and let the context procedure only show the detail tab with the tab-variant based on the property value.

When there are multiple detail tabs for the main subject, this has one major downside though: Normally the GUI remembers the activated detail tab when the user switches rows in the main grid. However when the context procedure switches the reference for a different tab-variant, it activates the first visible detail tab.

This creates inconsequent behaviour for the user when switching rows in the main grid because sometimes it does keep the same detail tab activated and sometimes it doesn’t. From the user perspective, the different references to the same detail tab are the same thing.

To improve the behaviour of cases when the activated detail tab becomes hidden by a context procedure, the GUI/Indicium should prefer activating the first visible detail tab of the same target table as the previous activated detail tab (before activating the first visible detail tab).

An alternative (instead of checking if it is the same target table) could be that it activates the first visible detail tab with the same translation value.

 

3 replies

Arie V
Community Manager
Forum|alt.badge.img+12
  • Arie V
  • Community Manager
  • July 24, 2026

​@PeterKeeris Could you clarify for what use case you are switching between different Variants of a Detail subject using a Context procedure?

And do you do this for multiple Subjects with multiple Variants as Detail tab? If it’s only a single Subject with multiple Variants, your Idea would be resolved if you order these Subject Variants to be the first Detail tabs, right?

At first impression, this feels a bit gimmicky to implement and I wonder if you’re perhaps working around another limitation of our platform.

Arie V
Community Manager
Forum|alt.badge.img+12
  • Arie V
  • Community Manager
  • July 24, 2026
Updated idea statusNew→Needs feedback
P
Captain
Forum|alt.badge.img+8
  • PeterKeerisCaptain
  • Author
  • Captain
  • August 13, 2026

I think our main use case is when we want to show different columns in the grid for the detail.

So the actual limitation is that we currently cannot have a flexible grid (while for a form you can make it flexible with a layout procedure). Maybe something could be made that in the context procedure of a main subject you can influence the ‘grid layout procedure’ for the detail subject to make it flexible without needing double references.

Having said that, the specific use case that triggered me to create this idea was a main subject that is a view that selects all rows from a specific table but also adds a hardcoded row ‘_All_’. All details of this view (so multiple tables) are double references with other reference columns so that for the ‘_All_’ row you are not filtered by the reference. 

 

For the first use case you are right that it is resolved when the double references are the first details pages. Only when a different detail is in front it doesn’t work. But keep in mind that the detail order sometimes is very important, so it is not always wanted to put the double references in front. For the second use case this is not possible because it are multiple target tables which all are double.

Terms & ConditionsAccessibility statement