Robot Framework variables are useful when:

  • strings change often in the tasks. With variables you only need to make these changes in one place.
  • creating system-independent tasks (${RESOURCES} instead of c:\resources, ${HOST} instead of Variables can be overwritten using command-line switches (--variable HOST: --variable RESOURCES:/opt/resources) or environment variables.
  • there is a need to have objects as arguments for keywords.
  • different keywords need to communicate. Assign a return value from one keyword to a variable and pass it as an argument to another.
  • values in the task data are long or complicated (${URL} is clearer than

Readability and flexibility

*** Settings *** Documentation Using variables for readability and flexibility. Library RPA.Browser.Selenium Suite Teardown Close All Browsers *** Variables *** ${I_FEEL_LUCKY_SEARCH_BUTTON} css:.FPdoLc > center:nth-child(1) > input:nth-child(2) ${SEARCH_URL} ${SEARCH_TERM} cute cat *** Tasks *** Search using hard-coded search URL and term Open Available Browser Search using variables Open Available Browser ${SEARCH_URL}${SEARCH_TERM} Search using environment variables Open Available Browser %{SEARCH_URL}%{SEARCH_TERM} # No modifications needed when changing the search URL or the term. # Configure the variables in Control Room. # Use devdata/env.json file for local testing. Search using local variables ${search_url} Set Variable ${search_term} Set Variable Robocorp Open Available Browser ${search_url}${search_term} Click an element using a hard-to-understand locator Open Available Browser Click Element css:.FPdoLc > center:nth-child(1) > input:nth-child(2) Click an element using a well-named locator variable Open Available Browser Click Element ${I_FEEL_LUCKY_SEARCH_BUTTON}

Read more about using environment variables with Robocorp.

Different types of variables

Variable name consists of the type identifier ($, @, &, %), curly braces ({, }) and the variable name between the braces. Use capital letters with global variables in the *** Variables *** section (${SEARCH_URL}). Use small letters with local variables that are only available in certain tasks or user keywords (${search_url}).

  • Scalar: ${var}
  • List: @{var}
  • Dictionary: &{var}
  • Environment: %{var}
*** Settings *** Documentation Using different kinds of variables. *** Variables *** ${STRING} cute cat ${INT_AS_STRING} 1 ${INT_AS_INT} ${1} ${FLOAT} ${3.14} @{LIST} one two three &{DICTIONARY} string=cat int=${1} list=@{LIST} ${ENVIRONMENT} %{PATH} *** Tasks *** Log variables Log Many ... ${STRING} # cute cat ... ${INT_AS_STRING} # 1 ... ${INT_AS_INT} # 1 ... ${FLOAT} # 3.14 ... ${LIST} # ['one', 'two', 'three'] ... ${LIST}[0] # one ... ${LIST}[1:] # ['two', 'three'] ... ${DICTIONARY} # {'string': 'cat', 'int': 1, 'list': ['one', 'two', 'three']} ... ${DICTIONARY}[string] # cat ... ${} # 1 ... ${DICTIONARY}[list][0] # one ... ${ENVIRONMENT} # entrypoints:bin:/Users/<username>/Projects/venv/bin...

The list (@{variable}) and dictionary (&{variable}) syntax is optional when assigning variables. You can use the list syntax when assigning a Table to a variable, but it is unnecessary.

When doing variable assignment, it's entirely valid to assign lists and dictionaries to scalar variables like this:

${my_list}= Create list 1 2 3 ${my_dict}= Create dictionary one=1 two=2

The reason to use the special syntax is that Robot Framework does some extra validation for you.

Validate that the keyword returns a list (or something list-like)

@{my_list}= Create list 1 2 3

Validate that the keyword returns a dictionary (or something dictionary-like)

&{my_dict}= Create dictionary one=1 two=2

With dictionary variables, the assignment does another thing: it turns it into a Robot Framework DotDict. A DotDict is otherwise identical to a normal Python dictionary but allows accessing values through dot-notation: ${my_dict.two}.

Note: If you assigned to @{my_list}, you can always access it through ${my_list}, and vice-versa. They refer to the same variable.

The second place where this syntax is used is when calling keywords. With list or dictionary variables, they are unpacked as arguments automatically. If you are familiar with the Python syntax *args and **kwargs, this is similar to that.

For example, here we call the first keyword in three different ways: with individual arguments, by unpacking a list, and by unpacking a dictionary:

*** Keywords *** An example keyword [Arguments] ${first_arg} ${second_arg} Log Got arguments ${first_arg} and ${second_arg} A second keyword ${as_list}= Create list 1 2 ${as_dict}= Create dictionary first_arg=1 second_arg=2 # All three of the following will log "Got arguments 1 and 2" An example keyword 1 2 An example keyword @{as_list} An example keyword &{as_dict}

This is also why it is used when FOR looping. These two examples are identical:

*** Keywords *** Loop through scalars ${name_one}= Set variable John ${name_two}= Set variable Robert FOR ${name} IN ${name_one} ${name_two} Mark Log Name is ${name} END Loop through list ${names}= Create list John Robert Mark FOR ${name} IN @{names} Log Name is ${name} END

If the second FOR loop used ${names} instead of @{names}, it would not loop the names inside the list but would instead only loop once and return the list itself.

So, in conclusion: We don't use the @-syntax when assigning a Table to a variable because it is optional, but it would work because a Table is list-like. We also have to use the @-syntax when looping over a Table, because we want to loop over the rows inside of it.

Assigning variables

*** Settings *** Documentation Assigning variables. Library Collections # You can create variables in a Python file and import them: #Variables *** Tasks *** Assign variables ${string} Set Variable Hello, world! # ${string} = Hello, world! @{list} Create List a b c # @{list} = [ a | b | c ] &{dict} Create Dictionary key1=val1 key2=val2 # &{dict} = { key1=val1 | key2=val2 } ${a} ${b} ${c} Create List a b c # ${a} = a, ${b} = b, ${c} = c ${cat_says} What Does The Cat Say # ${cat_says} = Meow! ${evaluate} Evaluate # ${evaluate} = 2020-09-08 ${inline_evaluation} ... Set Variable ... ${{ + datetime.timedelta(1)}} # ${inline_evaluation} = 2020-09-09 *** Keywords *** What Does The Cat Say RETURN Meow!

Expressions are evaluated using Python's eval function. All Python built-in functions are available. All unrecognized Python variables are considered to be modules that are automatically imported. It is possible to use all available Python modules, including the standard modules and any installed third party modules.

Built-in variables

${CURDIR}The path to the task data file directory.
${EMPTY}Like the ${SPACE}, but without the space. Used to pass empty arguments.
${EXECDIR}The path to the task execution directory.
${False}Boolean False.
${None}Python None.
${null}Java null.
${SPACE}ASCII space (\x20).
${TEMPDIR}The path to the temporary directory.
${True}Boolean True.
${/}The directory path separator. / in UNIX-like systems and \ in Windows.
${:}The path element separator. : in UNIX-like systems and ; in Windows.
${\n}The line separator. \n in UNIX-like systems and \r\n in Windows.

Runtime variables

${DEBUG_FILE}Debug file.
${KEYWORD_MESSAGE}The error message of the current keyword.
${KEYWORD_STATUS}The status of the current keyword, either PASS or FAIL.
${LOG_FILE}Log file.
${LOG_LEVEL}Log level
${OUTPUT_DIR}Output directory.
${OUTPUT_FILE}Output file.
${PREV_TEST_MESSAGE}The error message of the previous task.
${PREV_TEST_NAME}The name of the previous task, or an empty string if no tasks have been executed yet.
${PREV_TEST_STATUS}The status of the previous task: PASS, FAIL, or an empty string when no tasks have been executed.
${REPORT_FILE}Report file.
${SUITE_DOCUMENTATION}The documentation of the current task suite.
${SUITE_MESSAGE}The full message of the current task suite, including statistics.
&{SUITE_METADATA}The metadata of the current task suite.
${SUITE_NAME}The full name of the current task suite.
${SUITE_SOURCE}The path to the suite file or directory.
${SUITE_STATUS}The status of the current task suite, either PASS or FAIL.
${TEST_DOCUMENTATION}The documentation of the current task.
${TEST_MESSAGE}The message of the current task.
${TEST_NAME}The name of the current task.
${TEST_STATUS}The status of the current task, either PASS or FAIL.
@{TEST_TAGS}The tags of the current task in alphabetical order.

Environment variables available during a Control Room run

In Robot Framework syntax the environment variables are marked by % character. In Python syntax these variables can be accessed by os.getenv("ROBOT_ROOT", None).

%{RC_ACTIVITY_ID}The process step identifier
%{RC_ACTIVITY_NAME}The process step run name
%{RC_ACTIVITY_RUN_ID}The identifier of the process step run
%{RC_WORKSPACE_ID}The identifier of the workspace
%{RC_PROCESS_ID}The identifier of the process identifier
%{RC_PROCESS_NAME}The name of the of the process
%{RC_PROCESS_RUN_ID}The process run identifier
%{RC_PROCESS_RUN_NUMBER}The process run index number
%{RC_API_SECRET_HOST}The URL of the Control Room Secrets API
%{RC_API_SECRET_TOKEN}The API secret token for the Control Room Secrets API
%{RC_API_WORKITEM_HOST}The URL of the Control Room Workitems API
%{RC_API_WORKITEM_TOKEN}The API secret token for the Control Room Workitems API
%{ROBOT_ARTIFACTS}The absolute path to the Robot's artifacts folder, which is set in the robot.yaml file.
%{ROBOCORP_HOME}The absolute path to the Robocorp root folder. Used by Robocorp tools for various purposes.
%{ROBOT_ROOT}The absolute path to the Robot folder

I want to learn more!

Read more about variables in the Robot Framework User Guide.

Last edit: May 4, 2022