Get topics that matches conditions

Searches the whole topic collection and puts the matches into the stash. This is the op for questions that start with "all topics where", such as every change scheduled for next week or every open incident in a set of categories.

Use Load Related Topic instead when the search is anchored to one topic and you want its parents or children. That op walks relationships; this one runs a query.

Two limits sit behind every field below. The result is capped at 100 topics and there is no field to raise it. And the query is filtered by what the user running the rule may view, so the same rule returns different topics for different people, and the whole collection when it runs with no user at all.

Fields

Select topics in categories

Multi-select of the categories to search in. Leave it empty to search every category the acting user may view.

Picking categories narrows that set, it does not widen it. A category the user has no view permission on returns nothing however explicitly you select it, and no message says so.

Select topics in statuses

Multi-select of statuses. Empty means status is not considered.

The list offers every status in the system and is not narrowed by the categories you picked above, so you can select a status that belongs to a category you are not searching. It matches nothing and says nothing.

Exclude selected statuses?

Turns the status list into an exclusion: everything except those statuses comes back.

With no statuses picked, this checkbox does nothing at all. That combination looks like "exclude nothing" and behaves like it, so a rule configured this way quietly returns the full set.

User assigned to topics

Restricts the search to topics a user is assigned to. Two choices, plus blank.

Value	Effect
blank	no assignee filter
Any	no assignee filter
Current	only topics assigned to the user the rule is running as

Current needs a user in context. Event and web rules have one. A rule started by the scheduler usually does not, and in that case the filter is dropped entirely rather than matching nothing, so you get every topic instead of none.

When the user exists but has no topics assigned, the result is an empty list, which is the correct answer and is easy to confuse with the previous case.

This filter is applied last and overwrites any mid restriction you wrote into the condition field below. Do not use both to select the same thing.

Advanced JSON/MongoDB condition for filter

A raw query document, written as JSON, merged into the search. Use it for anything the pickers cannot express: date ranges, custom fields, or or-groups.

{"created_by": "foo_user"}

{"$and": [
  {"planned_start": {"$gte": "${week_start}"}},
  {"planned_start": {"$lt": "${week_end}"}}
]}

${var} placeholders are expanded before the query is parsed, so stash values can drive the search. The substituted text has to leave valid JSON behind: a variable holding a quote or a newline breaks the document, and a variable that fails to resolve leaves the literal ${...} in place as a value that will never match.

Two hard limits. Forward slashes cut the value short, so dates written 2026/01/01 and any regular expression written with slash delimiters will not survive; use dashes and plain patterns. And a condition that does not parse is written to the log and then ignored, which means the op returns the unfiltered set rather than failing. A search that suddenly returns far too much is nearly always a broken condition.

Field names in the condition are the stored names, and nested values use dotted paths such as category_status.name.

One path is not yours to set. The list of categories the user may view is applied after the condition and replaces any category.id you write, without a word about it. mid goes the same way whenever User assigned to topics resolves to a real user.

Fields

Comma-separated list of the topic fields to return, for example mid,title. Bare names, no ${}.

Empty returns the entire topic document for each of up to 100 topics, which is a lot of stash to carry for the rest of the rule. Name what you read.

Nothing is added for you. Ask for mid if you intend to act on the results.

Who the search runs as

The query is cut down to the categories the acting user has view permission on, and cut down again by whatever record-level restrictions that user carries. Nothing reports what was held back, so two people running the same rule get different counts and no explanation for the difference.

When the rule runs with no user in context, the search is made as the built-in root account and none of that filtering applies. A rule that looks well-scoped while you test it from the web can return far more than you expected once the scheduler is the one running it.

What lands in the stash

Set Return Key on the op's Options tab or the result is discarded and the op does nothing useful. The variable receives a list of topic records, empty when nothing matched.

Each record is flat. Nested parts of the topic arrive as dotted key names such as category.name and category_status.name rather than as nested structures. A field holding several values keeps one key and collects the values under it, so the names never carry positions.

The 100-row cap is applied after filtering and before you see anything. There is no count of how many were left behind, and no error. If the answer might exceed 100, narrow the query rather than paging, because there is no paging control on this form.

Nothing sorts the result either. The 100 you get are the first 100 the database hands back, in no order you can rely on, which is not the same as the 100 newest. A rule that reads the first record and acts on it is reading an arbitrary topic.

The op reads only. It never writes to a topic, and on a rollback pass it runs again unchanged, refilling the same variable, unless you clear Run Rollback on the op's Options tab.

Combining with other ops

Walk the result with the FOREACH stash[ variable ] op, which hands you one record per pass, or test whether there was anything at all with IF var condition THEN using IS EMPTY and NOT EMPTY.

Feed mids into Change Topic Status for bulk transitions, or into Send a notification to chase the owners of everything the query found.

Compute the date boundaries for the condition with Get Date and store them with SET VAR before this op runs. The condition field expands whatever is already in the stash, and nothing more.

When you have a starting topic rather than a query, use Load Related Topic.

Examples

Everything open in a set of categories, assigned to whoever triggered the rule.

Select topics in categories    Incident, Problem
Select topics in statuses      Closed, Cancelled
Exclude selected statuses?     [x]
User assigned to topics        Current
Fields                         mid,title,category_status.name
Return Key                     my_open_items

Changes planned inside a window computed earlier in the rule.

Select topics in categories    Change
Select topics in statuses      Scheduled
Exclude selected statuses?     [ ]
User assigned to topics        Any
Advanced JSON/MongoDB condition for filter
  {"$and":[{"planned_start":{"$gte":"${week_start}"}},
           {"planned_start":{"$lt":"${week_end}"}}]}
Fields                         mid,title,planned_start
Return Key                     upcoming_changes

Topics created by one account, with the whole document kept because the next op reads custom fields.

Select topics in categories    Request
Advanced JSON/MongoDB condition for filter
  {"created_by": "foo_user"}
Fields
Return Key                     foo_requests