Exam Scenarios: Achieving Determinism with Variables and Filters in Agentforce

These four exam-style scenarios test the same core idea: determinism in Agentforce is not achieved by writing stronger instructions for the language model. It is achieved by combining variables, which represent state, with filters, which enforce hard access control over topics and actions. Variables tell the system what is true right now. Filters convert that truth into a strict set of allowed choices for the reasoning engine. The result is predictable behavior that cannot be bypassed by clever user phrasing.

In the first scenario, the business rule is that a shipping label can be generated only when the order is actually ready to leave the warehouse. The problem is that without strict control, the agent might attempt to generate a shipping label simply because the user asked, even when the order is not in the correct stage. The goal of determinism is that the action Generate Shipping Label becomes available only when the order status is exactly Ready for Dispatch. To achieve this, you need a variable that represents the current order status. In most implementations this is a custom text variable called OrderStatus, populated from the output of an action such as Get Order Details. Once OrderStatus is available, you create a filter whose condition requires OrderStatus to equal Ready for Dispatch, and you apply that filter directly to the Generate Shipping Label action. The result is hard control: the reasoning engine cannot select Generate Shipping Label unless the order is in the correct status, and no user phrasing can unlock it prematurely because the action is not available in the choice set.

In the second scenario, the system must route critical sessions to a live agent, but handle non-critical sessions by creating a support case. The problem is that without governance, an agent might choose the wrong operational path, either escalating too often and overwhelming human teams, or failing to escalate when urgency demands it. The goal of determinism is that critical priority always enables Route to Live Agent, while non-critical priority enables Create Support Case. The state is captured in a variable such as SessionPriority, which can exist as a trusted context value from the session or as a custom variable filled by an assessment action. You then create a filter that allows Route to Live Agent only when SessionPriority is Critical, and a complementary filter that allows Create Support Case only when SessionPriority is not Critical, or when it is explicitly Normal. Applying these filters to the corresponding actions creates strict branching. The result is that the reasoning engine has a predictable route: in critical sessions it can only escalate, and in normal sessions it can only create a case. The agent is no longer “deciding” based on tone or guesswork; it is following enforced access logic.

In the third scenario, the user shares preferences that must remain stable throughout the conversation, even if the user changes topics mid-session. The problem is that agents often lose continuity: they forget the user’s preferred language or accessibility requirements and start asking again or switching behavior. The goal of determinism is session-level consistency, where the agent keeps using the same language and continues respecting the same requirements until the session ends. The required variables here are conversation variables, because these values are specific to the current interaction and should not be treated as system-level truth. A conversation variable such as PreferredLanguage stores the chosen language, and another conversation variable such as MobilityAssistance stores whether additional accessibility support is needed. These values can be captured by an action like Capture Preferences and mapped into the variables as outputs, or they can be set through conversational logic during the interaction. Filters may be used selectively to unlock certain accessibility-related topics or actions only when MobilityAssistance is true, while PreferredLanguage is typically used most effectively inside instructions so responses remain consistent in the chosen language. The result is controlled continuity: the agent does not reset when the topic changes, and the user experiences a stable, consistent service style across the session.

In the fourth scenario, a verified customer identifier must be passed between organizations or agents using the Agent API, but it must remain read-only and hidden from the language model. The problem is that enterprise workflows often depend on a verified GUID or similar identifier, yet exposing it to the model introduces privacy risk, because the model could accidentally include it in a user-facing response or handle it in ways you do not want. The goal of determinism is that the verified identifier is treated as authoritative session context, can be used as an action input reliably, and cannot be altered or leaked through generation. This requires a read-only context variable such as dollar sign Context VerifiedCustomerGUID, set at session start or provided during message delivery through the Agent API. Then you create filters for sensitive actions, such as profile updates or any operation that may touch private data, requiring that the verified GUID exists or that an authentication state is confirmed. You apply those filters directly to the sensitive actions. In addition, you ensure the identifier is not exposed to the language model, so the model can still operate safely while the execution layer can still use the value for calls. The result is strict control and strong security: sensitive actions are unlocked only when verified context is present, and the model cannot leak the identifier because it is not allowed to use it in generation.

Across all four scenarios, the exam-level lesson is consistent. Variables establish state. Filters enforce access boundaries based on that state. The reasoning engine operates only within what filters allow, making behavior predictable and testable. This is how Agentforce turns probabilistic language generation into a governed system suitable for enterprise operations.

Next, it is critical to understand what filters actually restrict in the architecture. Filters limit access to topics and actions. Many exam traps are built on confusing these two layers, such as applying restrictions at the wrong level. The next topic is a clear architectural breakdown of topics and actions, and how the reasoning engine selects between them inside the allowed space.