Skip to main content

Variables in a Workflow - Setting, Updating, and Passing Between Actions

Variables are the “live memory” of an RCOM Gateway workflow. They carry inputs into a job, hold intermediate results, and hand data from one action to the next. This guide shows you exactly how to create them, update them, pass them between actions, and debug them confidently.

What is a variable..?​

A variable is a named place to store a value so your program can use and change it later—think of it like a labeled box that holds data. A variable can be of different types including String, Int, Bool, DateTime, Decimal, Guid, List, Dictionary, GhostData, etc.

Key ideas​

  • Name (identifier): The label you use to refer to the value (e.g., count, userName).
  • Value: The actual data stored (e.g., 42, "Alice", true).
  • Type: What kind of data it holds (String, Int, Bool, DateTime, Decimal, Guid, List, Dictionary, etc).
  • Scope & lifetime: Where in the code the variable is visible and how long it exists (inside a function vs. globally).

In an RCOM Gateway workflow, a variable is a named value that lives in the job’s execution context and moves data from one step to the next. Think of it as the workflow’s short-term memory: actions read variables, transform them, and write new or updated variables for downstream actions.

Types​

  • Global variables (client-level): Configure once and use across Gateway, great for base URLs, keys, facility IDs, etc.

    • Set them at Settings → Client Settings → Client Settings → Edit → Details → Manage Global Data.
    • They’re available to all workflows, dashboards, endpoints, and event processors.

  • Access-group scoped variables: Similar to Global variables, but mapped to a selected access group, which means they are only available for users or processes that are under the selected access group.

    • Define per group at Settings → Client Settings → Groups → Edit Group → Manage Variables
    • Only assets bound to that group can read them.

  • Runtime (event) variables: These arrive with each event (REST, MQTT, timers, object changes) or are created inside a workflow (e.g., with SetVar). They exist only during that job and are the main way actions pass data.

    • This includes any variable accessible under the current job context.
    • These variables might be present in different jobs, but will have different values based on scope.
info

Example event payload fields like deviceId, location, and timestamp can be mapped into a workflow so they appear as parameters/variables at runtime.

The workflow context: where variables live during execution​

Every job has an isolated context holding:

  • Input parameters: When you design a workflow, declare input Parameters (name + type) so an Event Processor can inject data cleanly.
  • Global/access-group variables: Variables globally available or scoped for the process.
  • Intermediate action outputs: Any RESULT_VAR you define inside (output of an action) is a variable that can be used next actions.
  • Custom variables: You can use the SetVar action to define custom variables with defined values.
  • Any retrieved/computed structures (lists/dictionaries, API results, Object data, etc.)

Actions read from and write to this context as they run; it’s how data flows between actions. Variables in the Context can be accessed by any action.

info

Variables are unavailable in preceding actions. Consider this workflow:

JsonPathValue > CastInt > Condition > CreateObject > SetVar > CustomScript > SetObjectAttributes

The JsonPathValue action creates a variable available to all subsequent actions. However, the variable created by CreateObject is only accessible by actions that follow it (e.g., SetVar > CustomScript > SetObjectAttributes). Actions before CreateObject cannot access this variable because it has not yet been created.

Creating and setting variables inside a workflow​

A. Extract values from JSON​

Use JsonPath (string) or JsonPathValue (typed) to pull fields from payloads/variables into new variables. Typical pattern:

  • JsonPath → Cast* (e.g., CastInt, CastBool) if needed
  • Store the result as a named variable for downstream steps

B. Created as action output​

Any workflow Actions that provide you with an output, save it as a variable for later use in the workflow.

C. Set/override custom variables explicitly​

Use SetVar to assign any value (string, number, bool, list, dictionary, complex objects) to a named variable in the context.
Purpose: “Assign values to variables.”

tip

For platform-wide constants, prefer configuring Global Variables or updating them with UpdateGlobalVar when truly needed at the client level. Keep per-job data in the workflow context.

Updating variables as the flow progresses​

  • Overwrite: Run SetVar again or SetDictionary in case of updating dictionaries with the same name to replace the value (e.g., after validation).
  • Re-shape: Use CastDictionaryList, SplitString, or similar helpers to convert formats before saving back (handy for tabular/row lists or delimited strings).
  • Structure: Prefer lists/dictionaries for complex payloads so downstream actions can consume them cleanly. (This also makes debugging in Context easier.)

Passing variables between actions (the dataflow pattern)​

  • Action A reads from parameters/variables, produces an output.
  • It writes that output into the context (often via SetVar, or as the action’s result).
  • Action B references the same variable name.

That’s it-the context is the shared bus for your job.

info

Where the first values come from: either Global/Group settings or Variable Mapping from the Event Processor (Static/Dynamic). After that, each action can transform and reset variables as needed.

End-to-end mini-example​

Goal: Receive JSON

{ 
    "name": "Tray", 
    "qty": "10", 
    "fragile": "true" 
}

normalize types, and prepare a dictionary for a create/update step.

  • Parameters: name (String), qty (Int), fragile (Bool), declare them in the workflow.

  • Variable Mapping (Event Processor): map JSON fields dynamically to those parameters.

  • Normalize/derive:

    • If the payload arrives as strings, use JsonPathValue + casts to produce typed vars (CastInt(qty), CastBool(fragile)), then SetVar → ATTRS as a dictionary:
      {"NAME": name, "QTY": qty, "IS_FRAGILE": fragile}.

  • Use downstream: pass ATTRS to your create/update action.

Throughout, all intermediate values live in Context, ready for the next action.

Inspecting & debugging variables​

When a job runs, open Workflows → Workflow Jobs and pick a job:

  • Logs: step-by-step execution.
  • Context: every runtime variable as the workflow saw/produced it, perfect for tracing inputs, casts, and mappings.

From a job’s detail, click Context to see values like GLOBAL_VARS, your parameters, and anything you set with SetVar, HttpRequest, etc. Name variables clearly to make this page effortless to read.

note

Troubleshooting flow: If a job fails, check Status → Logs → Context to confirm variables were passed and typed as expected, then adjust workflow logic or source data and re-run.