Creating and Applying Filters in Agentforce Builder

Filters are the practical governance tool in Agentforce Builder that turns policy into real access control. In theory, filters act like a door lock for topics and actions. In practice, you need to know exactly where to configure them, how to define conditions correctly, and how to apply them so they truly restrict what the reasoning engine can choose.

Filters are created in Agentforce Builder inside the Context panel, specifically under the Filters tab. This placement is intentional because filters are always based on variables, and variables live in the same context configuration space. When you create a filter, you are defining an access rule that the agent will use during topic selection and action execution.

A filter is built from one or more conditions. You can keep it simple with a single condition or make it more strict by combining multiple conditions. Each condition has three parts. First, you choose a variable. Second, you choose an operator that defines how the comparison works. Third, you set the value the variable must match or satisfy. This structure makes filters readable and testable because each rule is expressed as a clear requirement.

Agentforce supports using context variables, conversation variables, and custom variables inside filter conditions. That gives you a wide range of control. You can gate access using trusted system context, temporary session state, or business-specific signals you designed yourself. For example, a context variable might represent channel or user language, a conversation variable might represent a confirmed preference or a completed step, and a custom variable might represent authentication status, customer tier, or case priority.

Creating a filter is only half of the job. A filter does nothing by itself until it is applied to actual topics or actions. Applying filters happens through the Topics panel. In the Topics panel, you select the specific topic or action you want to control and attach the filter so that it becomes available only when the filter conditions are satisfied. The same filter can be applied to one item or to many, which is useful when you want a consistent governance rule across a group of sensitive actions.

Once the configuration is done, the most important step is validating that the filter truly limits the agent’s choices. A quick way to verify this is to confirm the filter is actually assigned to the relevant topics or actions in the Topics panel, because an unassigned filter will never take effect. Next, confirm that the variables referenced by the filter are being populated in your sessions, because a rule based on an empty or missing value may behave unpredictably. Then test two clearly different states, one where the condition should be true and one where it should be false. In a correct setup, the set of available topics and actions should change accordingly, and restricted actions should disappear from what the reasoning engine can select. Finally, try to “trick” the agent with different user phrasings. If the filter is working, the agent cannot bypass it through language, because the restricted action is not available for selection at all.

If these checks pass, your filter is functioning as a real control boundary rather than a soft instruction. This is what makes Agentforce enterprise-ready: rules are enforced by system design, not by hoping the model behaves.

Next, we will reinforce everything with exam-style thinking. Now that variables and filters are clear as a single system, we will walk through four common exam scenarios that combine variables and filters, so you can recognize the correct configuration instantly and avoid the typical traps where soft prompting is mistaken for hard access control.