Custom Variables: Creation and Settings in Agentforce

Custom variables in Agentforce are your main tool when built-in context is not enough. Context variables come from the system and the channel, conversation variables live only inside the current session, but custom variables are designed by you to match real business logic. They let the agent behave like a controlled process executor, not just a conversational assistant. With custom variables, the agent can store business signals, make decisions based on structured values, and pass data between actions without relying on fragile text extraction.

Custom variables are created in Agentforce Builder, inside the Context panel. This is where you define the data contract of your agent: what information the agent can reference, what values can be provided externally, what can be updated during execution, and which values the language model is allowed to use while responding.

When you create a custom variable, the first important choice is the data type. Agentforce supports core types that are deliberately simple and predictable: Text, Boolean, and Number. Text is useful for string values such as language, category, status, or routing codes. Boolean is ideal for flags like verified, escalation required, or eligible for refund. Number is useful for numeric signals such as order amount, priority level, or counters. These types make filtering and decision logic more reliable because they are easy to validate and interpret consistently.

After choosing the data type, the real power comes from the variable settings. These settings turn a variable into a governance control point.

One key setting is allow value to be set by API. This determines whether the variable can receive its value from external systems through an API. This is essential when you connect Agentforce to operational data sources like a CRM, an order management system, a routing engine, or a prioritization service. In this model, the variable becomes a controlled input signal. Your system provides the value, and the agent can make decisions based on that value rather than guessing from the user’s message.

Another critical setting is allow LLM to use the value. This decides whether the language model can see and use the variable’s value while reasoning and generating responses. This is one of the most important safety levers in Agentforce. Not every variable should be visible to the model. Some variables contain sensitive or internal information such as unique identifiers, backend record keys, internal customer IDs, routing tokens, or other technical values that should not appear in user-facing output. In those cases, you can keep the variable available for actions and mapping, but restrict the language model from using it. The result is safer behavior: the agent can still execute workflows, but the model cannot accidentally expose confidential details in natural language.

This is how custom variables connect directly to security. Agentforce safety is not only about restricting which actions are available. It is also about controlling what information enters the model’s “thinking space.” If an identifier is needed only for an action call, it belongs in the technical execution layer, not in the generative layer. Limiting LLM access reduces the risk of leakage, accidental disclosure, and incorrect use of internal values.

A third practical capability is assigning and mapping variables. Custom variables frequently act as the wiring between actions. They can be used as inputs to actions, and they can store outputs from actions through mapping. This is how multi-step flows become reliable. One action can write a result into a variable, and the next action can use that variable as its input. The agent does not need to re-ask the user or re-infer the same information. The process becomes structured, repeatable, and much more deterministic.

In short, custom variables are not just “extra fields.” They are a control surface. The data type makes values predictable. API access defines what can be supplied from external systems. LLM access controls what the model can use and potentially reveal. Mapping turns variables into a data pipeline that connects actions into a consistent workflow.

The next logical step is to see how this works end to end. Next, we will focus on how variables connect actions through input and output mapping, and how to design action chains where data flows cleanly from one step to the next, producing predictable outcomes without repetitive questions or fragile text parsing.