Skip to main content

Creating Variables in Swantide Workflows

Use this article as your guide to creating Variables to make your workflows dynamic and create the ability to inject customizations to the metadata components on deploy

Engineering Swantide avatar
Written by Engineering Swantide
Updated this week

What Are Variables?

Variables in Swantide workflows make your workflows dynamic and customizable. They act as inputs that inject deployer selections into your metadata components. In other words, variables are the “questions” you ask deployers when they set up a workflow deployment, and their answers shape how the metadata is created or updated in Salesforce, things like:

  • Open text strings (e.g., allowing the deployer to name a component)

  • Numeric values (e.g., defining a flow's attribute of 30 days)

  • Any type of Salesforce metadata (e.g., selecting a field, object, or layout from the target org)

By defining variables, you can build workflows that are flexible, reusable, and customized to the target Salesforce.


The Add Variable Screen

When you click + Add Variable, you’ll see a series of fields and attributes. Here’s what each one means:

Variable Input Prompt

The variable input prompt will be the text shown to the deployer. This is the “question” you’re asking them to answer or select. For example, if you are creating a variable for them to select a field, you may make the prompt "Select the field that you'd like to add to the page layout."


Top-Level Attributes

Directly beneath the variable input prompt, there are a few top level attributes used for more advanced Workflows:

  • Is Multi Select (Tuple Mode)
    Defines if a variable should behave as a tuple — i.e., create sets of variable inputs where each input is related to the other in its set

    • Example: If deployers need to select an object and a field together, and they should be able to select many object-field sets, you would enable this.

    • ⚠️ Not typically used in standard workflows.

  • Is Hidden from User Selection
    Allows variables to exist without user input.

    • Common in advanced workflows where hidden variables are used alongside visible ones to create more dynamic behavior.

    • ⚠️ Not typically used in standard workflows.

  • + Add Variable Usage
    Only applies if “Is Multi Select” (tuple mode) is enabled. Defines how tuple pairings are used.

    • ⚠️ Only used in Touples Workflows where the top-level "Is Multi Select" is checked


Input Fields Section

  • Variable Input Type
    Defines the type of "answer" deployers can input. You are putting parameters on the deployer's response. The Workflow builder allows you to select from a list of available variable input types when you are defining the variable. This list includes every metadata type in Salesforce as well as open text, number, boolean, date, currency, and raw json options.

    • The PRIMITIVE_STRING type indicates that the deployer can input a text string as the variable input response - this could be if the variable is asking the deployer to name a new field as an input to a field metadata component

    • The PRIMITIVE_NUMBER type indicates that the deployer can input a number value as the variable input response - this could be if the variable is asking the deployer to indicate the number of days a new opportunity should be created after as an input to a flow metadata component

    • The CustomObject type will show the deployer a list of all objects in their salesforce environment for them to pick from - this could be if the variable is asking the deployer to select an object for a new field metadata component to be created on

  • Is Required
    Determines if deployers must provide a response in the variable input. Most variables are required.

  • Is Multi Select (Answer Level)
    Separate from tuple mode. This option allows deployers to provide multiple answers of the same type.

    • Example: If you’re asking which page layouts a field should be added to, the prompt would be "select the page layout(s) you'd like the new field to have access to"; the input type would be Layout and the multi select option at the input fields answer level would be checked to allow them to pick multiple page layouts if they'd like.

  • Is Fixed Key
    Used in workflows that can be deployed multiple times to the same org (eg at the Workflow level, when creating a workflow selecting the "Allow Multiple Instantiation/Deployments" option).

    • The fixed key ensures uniqueness across multiple deployments of the same workflow in the same Salesforce — you can’t deploy the same workflow instance twice against the same metadata.

    • Example: A timestamp field workflow targeting a picklist, the picklist variable would be the fixed key so that the metadata can only be deployed once to that picklist field.

  • Sub Prompt
    Adds extra context or a secondary question. Often left blank, but can be helpful in tuple mode to label each part of the set.

  • Default Value
    Pre-populates a default response for deployers.

    • Example: If selecting profiles to add field access, you might default to Admin and Standard profiles. The deployer can always change/remove default values on deploy.

    • Tip: Always use the full Salesforce API name when setting defaults.


Filters Section:

Narrow the choices available to deployers

Out of the box, when selecting an input type that is a type of salesforce metadata, the deployer will see every option under that metadata type for their target org.

Filters refine these options shown to deployers. Filters are only relevant when using input types from Salesforce metadata, such as CustomField CustomObject PicklistValue

The naming convention for Filters is the API name of the path, with * indicating what is up for the user selection. For example, field API names are OBJECTAPI.FIELDAPI, when refining the path for a deployer's field selection, you would use OBJECTAPI.* indicating that the field name is up for the deployer's selection.

  • Path Allowed
    Restricts options to specific Salesforce objects or paths.

    • Example: if an input type is CustomField, instead of wanting to show the deployer all custom fields in the Salesforce they are deploying to, they want to restrict to only fields on the Account and Lead objects. To accomplish this, they'd enter Account.* and Lead.* into the path allowed filter. This will ensure only fields from Account and Lead objects are available to be chosen.

  • Path Exclusions
    The opposite of Path Allowed — excludes specific paths.

    • Using the same example above, if we input Case.* into the Path exclusions filter, this will remove any Case fields from the list of fields displayed to the deployer.

Type Filters only apply to Variables where the input type is CustomField

  • Type Allowed
    Limits the list of fields displayed to the deployer only to the types included in the type allowed filter (when left blank, all field types are listed)

  • Type Exclusions
    The inverse of Type Allowed. Blocks certain field types from being included as options to the deployer (when left blank, all field types are listed)


Best Practices

  1. Keep Prompts Clear: Use straightforward language in variable prompts so deployers know exactly what’s being asked.

  2. Filter for Relevance: Narrow the choices so deployers don’t have to scroll through irrelevant options.

Did this answer your question?