In short — when you filtered a task list by a custom field of the case, Portal searched two places at once (business case and sub/technical case) because it couldn't tell which case you meant. That was slow on large systems, and it could show you tasks that matched in the place you weren't asking about.
Now the column you picked decides where to search.
Do I need to do anything? Almost certainly not. Your dashboards and your saved filters are corrected automatically. There are two situations Portal can't work out on its own — they are listed at the end, and both are quick to check.
Fixed in 14.0.0
What was wrong
In Axon Ivy, one request is a business case. If parts of it are handled by sub-processes, those parts get their own cases underneath it. A task always sits in one of those cases.
A custom field can be stored on either one — which is why a task widget offers you two columns that look almost the same:
- Custom Case Field — the field on the case the task sits in
- Custom Business Case Field — the field on the business case
Filters made from those two columns were indistinguishable once saved, so Portal couldn't tell which case you meant. It searched both and merged the results.
Two searches instead of one, across the two largest tables in the system — on a big installation, slow. And because a match in either case was good enough, a task could turn up in your list even when the value you filtered on sat on the other case.
What changed
The column you picked now decides where the filter looks:
One search instead of two: faster, and the results come from the case you actually asked for.
What happens to the dashboards and filters you already have 🤔
They are corrected automatically the first time they are opened. Portal looks at the widget's columns, finds the column using the same field, and takes the answer from there.
Two situations have no answer to take, so they are worth a quick look after upgrading:
- The widget no longer offers that field for filtering - its column was removed, or filtering was switched off for it, in Column Management. With no column left to compare against, the filter keeps searching the case the task sits in. If it was meant to search the business case, you will see fewer results than before, sometimes none.
- The widget shows the same field as both columns. Portal cannot know which one the filter came from, so it chooses the business case.
Neither breaks anything — you still get results, they may just come from the other case. To correct one, open the widget's filter configuration and pick the field again.
For developers 👩💻👨💻
The case sub-query was built with CaseQuery.create(), which carries no case scope, so the engine joined tasks to cases on both CaseId and BusinessCaseId — a SQL UNION of two scans. Filters now carry the scope of their column and each picks one query:
Two details about the automatic correction. It happens when a filter is read and does not rewrite the stored JSON — the corrected type is used for the query, and it is persisted the next time that user saves the filter. And it cannot be applied to everyone from an admin account, because a saved filter can only be matched against the columns of the dashboards that user can see, in that user's own session.
If you want the stored data rewritten in place anyway, a one-off process that loads each user's saved filters and rewrites them works.
In our case it could map every filter to custom_business_case, because the project never used sub-case fields — no column lookup needed, which is what made it safe to run for all users at once.
