Skip to main content

About filters

Filters help you control what data is included in workflows, exports, and access control policies. They let you be more specific, only showing or acting on data that matches your set conditions.

You can create filters from a workflow, an export, or directly on the Access control policy page. Once created, the filter appears in the Filter section of the policy row.

Here’s how filters behave:

  • If you remove a filter from a workflow, it disappears from the access control policy too.
  • If you delete it on the access control policy page, it’s also removed from the workflow.
  • You can’t delete a filter if it’s still used in a policy.

Objects - filter conditions

Filters use conditions to match specific data. You can mix and match conditions using:

  • ALL (AND logic): All conditions must be true.
  • ANY (OR logic): At least one condition must be true.

You can build logic like:

  • Job title is Manager
  • Department is not any of HR, Finance
  • Start date is known
  • Status starts with Active

This gives you robust control over when actions happen or what data is visible.

Conditions2.png
Conditions.png

Ancestors in filters

If you create a self-referencing foreign key, for example, linking a user to their manager, Applaud automatically adds a hidden “ancestor” property. This makes it possible to filter on hierarchical relationships (like “show all reports under this manager”), even though you won’t see the ancestor property in other platform areas.

For example:

  • You create a Manager foreign key linking a user to the same model.
  • Applaud adds a hidden property: Manager ancestors[].

You can then use this hidden property in your filters to create smart, cascading access or visibility rules.

When you create this foreign key to the property, it returns to the same model.

ForeignKey.png

...Applaud creates this ancestor property.

AncestorIds.png

Property-specific filters

Sometimes you only want a filter to apply to specific fields. For example, you might want users with a specific role to see someone’s job title but not their salary.

In this case, you:

  1. Add both properties to the filter.
  2. Create a policy that gives access to just those properties.
  3. Assign the policy to the relevant role.

This makes filters incredibly flexible and secure, giving people access to the correct data.

Task you can perform here:

See more:

Reference:

Sections in this article