Performance guide
The performance guide describes best practices for configuring selection rules in the system.
With large accounts, data retrieval speed depends directly on how efficiently you configure filtering conditions. Below are the key principles and recommendations for creating fast selection rules for planners, filters, reports and data tags.
Priority of system fields
System fields "Template", "Project", and "Object" (and only these) are processed faster because the system is specifically optimized for them.
- Narrow the selection. Always add a system field to the filter that significantly reduces the number of entities to check. For example, if you are searching for tasks by a custom field "X" that exists only in template "Z", include a condition for template "Z" — this will substantially speed up the query.
- Avoid redundancy. If you already specified a condition for the template, adding a condition for the process (in which that template operates) is pointless — it will not improve speed.
Logical operators: AND vs OR
Condition logic is one of the most critical performance factors.
- Use "AND". Conditions combined with "AND" run fast, especially if the chain includes filters on system fields.
- Minimize "OR". Using "OR" (especially at the top level of a filter, without common narrowing conditions) can slow down retrieval by tens or hundreds of times. Design logic to avoid "OR" conditions on large datasets whenever possible.
Field-specific considerations
Not all checks are equally "light" for the database.
- Concrete values vs "has data". Checking for a specific value (for example, "Field X = Cassiopeia") is faster than checking for field presence ("Field X: contains data").
- Field types. Multi-value fields (multi-select lists) take longer to check than simple fields that store a single value.
- "Warming up" new fields. In large accounts, queries using a new custom field will always be slow on the first run. The system needs time to optimize conditions that start being used regularly, so queries on such fields typically speed up after some time.
Permissions
Complex on-the-fly access checks are one of the most resource-consuming operations. Therefore, queries run faster for system administrators than for users: administrators don't have their access rights checked.
By "query" here we mean any action — from opening a task filter to running a report, rendering the Planner, etc.
Sorting and grouping on large volumes
Sorting and grouping add extra load on top of an already performed retrieval.
- Avoid heavy sorts. Sorting by custom fields and dates on result sets that return thousands of tasks greatly slows down display. When possible, use sorting by system fields or avoid sorting altogether.
- Do not group unless necessary. If you can avoid grouping — do so; it will speed up loading.