Filters in Agentforce: Controlling Access to Topics and Actions with Conditions

Filters in Agentforce are the primary mechanism for governing what an agent is allowed to do. Variables provide state and facts about the current situation, but filters turn those facts into hard boundaries. They decide which topics and actions are available to the agent at any given moment, regardless of how the user phrases a request. This is what makes agent behavior predictable in enterprise environments.

Filters are created for both topics and actions so they are available only when specific conditions are true. A filter is not a polite suggestion to the model. It is an access rule. If the condition is not met, the topic or action simply does not appear in the agent’s available set. The reasoning engine can only choose from what is available, which means the agent cannot “accidentally” take the wrong path just because the prompt sounded convincing or ambiguous.

One of the most powerful aspects of filters is that access can be restricted using any variable. That includes context variables coming from the platform, conversation variables created during the session, and custom variables you define for your business process. In practice, this means you can enforce access rules based on almost any signal you trust. The user’s language, the order status, the channel type, the priority level, the customer segment, or a verification flag can all become conditions that control what the agent can select.

This design delivers three major benefits at the same time: determinism, privacy protection, and operational predictability.

Determinism improves because filters shrink the agent’s decision space. When the conditions are the same, the set of allowed topics and actions is the same. That makes outcomes repeatable. Instead of hoping the model will consistently pick the right step, you ensure the right step is the only available option in that state.

Privacy protection improves because many real-world risks come from executing the wrong action, not from generating the wrong sentence. If an action can expose personal data, modify an order, or trigger a sensitive workflow, it must be blocked until the correct conditions are met. Filters enforce least privilege at runtime, so the agent can only access what is appropriate for the current context and verification level.

Predictability improves because behavior can be explained and audited as rule-based access control rather than “the model decided.” When the agent behaves consistently, it becomes easier to test, easier to maintain, and easier to trust. You can validate outcomes by checking conditions instead of diagnosing unpredictable generative behavior.

A clear business example is requiring authentication before sensitive actions. Imagine actions like changing a delivery address or issuing a refund. A user might ask directly, “Please change my address,” or “Refund my order.” Even if the agent wants to be helpful, an enterprise system must verify identity and eligibility first. Filters solve this with a simple gating rule. You can require a variable such as CustomerAuthenticated to be true before the sensitive action becomes available. Until that condition is satisfied, the agent can explain the verification process and perform safe steps, but it cannot execute the high-risk operation. The user’s wording cannot bypass this, because the action is not available for selection in the first place.

This is the core value of filters. They make safety and determinism enforceable at the system level, not negotiable at the instruction level. The agent behaves correctly not because it “promised” in text, but because it is technically constrained to operate within allowed boundaries.

Next, we will move from concepts to configuration. We will break down how to create filters step by step by defining conditions using a variable, an operator, and a value, and by combining those conditions into clear access rules for topics and actions.