Using a hidden base prefilter alongside multiple prefilter groups

Here is an answer written by my colleague Claude AI. I think it answers your question: 

Yes, partly. You can make a hidden prefilter that is always applied. But the way Thinkwise combines prefilters means a prefilter can only remove rows, never add them back. So a "main" prefilter alone cannot stop the user's own items from disappearing when other filters are active. You need a small change in how you write the optional prefilters.

How Thinkwise combines prefilters

By default, active prefilters are combined with AND, so the query becomes [prefilter 1] AND [prefilter 2]. Since platform 2023.2 you can set a prefilter group to "match any" (OR). Then the active prefilters within that group are ORed, while different groups are still combined with AND. After the SF upgrade 2023.2, OR filtering can be enabled on a prefilter group, and this OR group behaviour relies on the Universal GUI. thinkwisesoftwarethinkwisesoftware

Hidden and locked prefilters are always ANDed with everything else. Thinkwise's position is that locked/hidden prefilters should always be applied to the query and can only be combined with an AND-operator, for security reasons. thinkwisesoftware

That gives you a query shaped like this:

main_prefilter AND (group 1) AND (group 2) AND (group 3)

If the user turns on a filter in group 1 that excludes one of their own items, that item disappears. The main prefilter cannot bring it back.

What you actually need

What you describe is:

own_items OR (group 1 AND group 2 AND group 3)

You can't express that with prefilter groups alone. The usual approach is to put the "own items" condition inside every optional prefilter query:

sql

-- Optional prefilter "Open status" (group 1)
t1.owner = dbo.tsf_user() or t1.status = 'open'

-- Optional prefilter "Region North" (group 2)
t1.owner = dbo.tsf_user() or t1.region = 'north'

Because each active filter is now "own item OR condition", the user's own records always pass every filter. Other records still have to satisfy all active filters. The result is exactly own OR (f1 AND f2 AND f3). To keep this maintainable, put the ownership check in a scalar function (e.g. is_own_item(t1.id)) or an expression column, and reference it from each prefilter.

Where the hidden main prefilter still helps

If by "main prefilter" you also mean a base scope, use a separate prefilter in its own group with the default state "On hidden". It is always applied and the user can't see or change it. For example: the user may only see records from their own department, and among those, their own items are always visible.

That gives you:

Group 0 (hidden):   department = user's department          → On hidden
Group 1 (optional): owner = tsf_user() or <filter 1a>       → Off/On
                    owner = tsf_user() or <filter 1b>
Group 2 (optional): owner = tsf_user() or <filter 2a> ...
Group 3 (optional): ...

You can configure groups 1–3 as normal, exclusive, or "match any" as you like. The ownership clause inside each filter still guarantees own items survive.

There's one gotcha with hidden prefilters in mandatory groups: even when the individual prefilters in a mandatory prefilter group are turned off, the group itself is still considered mandatory. So don't mark your optional groups as mandatory unless you really mean it. Also check variants, because prefilter states can be overridden per variant. thinkwisesoftware

Since this is for a custom component: if the component reads its data through the subject it's bound to, the prefilters apply automatically. If it queries Indicium separately, check that it uses the same subject or variant, or the prefilters won't be applied.