Build a form with Rewst's Form Builder
Learn how to build and customize your Rewst Forms
Create a new form
The part of Rewst you use to create and edit forms is called the Form Builder. To access it, navigate to Automations > Forms, and click .

In the Create New Form dialog, give your form a descriptive name. Remember, as you build more in Rewst, your list of forms will grow significantly. Following proper naming conventions will save you time in finding your right form later on.

The Form Builder is similar to Rewst's Workflow Builder in that it has a list of options on the left, called form fields, which can be dragged and dropped onto the canvas in the center of your screen.
Each of these options will relate to your inputs, or the information that goes into the form. With the exception of the Text/Markdown field which is only used for presenting data to the end user, all other fields are used as data input and contain a field name, field label and field description. The field name is the variable name used within the workflow once the form has been submitted. The field label and field description are used to format the appearance of the form.
Using the correct fields ensures your workflows receive clean, organized data.
Form field options
Dynamic options in forms
Dynamic options automatically fetch data from integrations, thereby eliminating the need for manual data entry and keeping form options up-to-date with the latest data. For example, if you're managing hiring information within your PSA, dynamic options can automatically pull this data into the form, ensuring that users always have the most current information.
There are two types of dynamic options: integration reference and workflow generated.
Option one: Integration reference
A reference option is a dynamic field pulled directly from predefined actions. It works well for straightforward data retrieval, but may require conversion to a workflow-generated option for data manipulation, as this doesn't give any filtering options and will pull directly from the API endpoint.
Integration reference example
Selecting the Microsoft Graph integration to list all users.

Option two: Workflow generated options
If you want more flexibility around the output of the data your user is seeing, you may need to opt for a workflow generated option instead, which allows for in-depth data manipulation using Jinja. We cover what these are and how to use them in Cluck U’s Rewst Foundations and micro course. If you’ve already taken our courses and want a refresher, see our documentation on option generators here and here.
Alternatively, dynamic forms use cases can be handled with our options filter feature. The options filter makes customizing dropdown fields within forms straightforward for those who want to add filtering without updating an options generator workflow. It takes inputs, filters them, and produces an output agnostic of the data source. See our separate options filter documentation here.
Options generator example
In this image, what is shown to the user is what is set as the label for the list contents. Ultimately, it can be whatever you want it to be, using Jinja to manipulate that output correctly. The ID is the value or unique ID of what the workflow is referencing for its future actions.

Set default options
Default options can be selected for a form field linked to a workflow by following these steps.
Add a boolean property to each option result.
Define the boolean property for the Default Selected Field value.
Sample data returned by a workflow:
[
{"label": "Adam", "id": "1", "current_default": false},
{"label": "Matt", "id": "2", "current_default": false},
{"label": "Jareth", "id": "3", "current_default": true}
]
Fields to be filled out in the form:
Value Field:
id
Label Field:
label
Default Selected Field:
current_default
Workflow inputs
Workflow inputs in Rewst offer a flexible way to define specific inputs to a workflow via a form. This functionality allows you to handle various client cases and attributes dynamically. By understanding these concepts and utilizing the provided examples, you can create versatile and dynamic forms tailored to your specific needs.
Below are some key aspects of workflow inputs:
Use org variables for client-specific workflows
If you have a form used across multiple clients, each with distinct environments like Microsoft 365 or On-Prem, you can use an org variable to dictate the source of the data.
For example, by employing {{ ORG.VARIABLES.primary_identity_provider }}
, which is set per client as either on_prem
or azure_ad
, you can use the same form for both client cases. The form will be pulled from the relevant system.

Hard-code attributes for efficiency
Instead of creating separate workflows for various attributes such as department, userPrincipalName, or ID, you can use a single workflow with a hard-coded element. This approach takes your input and returns the desired property.
For example, the attribute department
can be hard-coded to allow a single workflow to handle different returned properties.
Here's a Jinja code snippet for achieving this:
{%- set attribute_collection = [] -%}
{%- set my_attribute = CTX.attribute -%}
{%- set my_data = CTX.data|selectattr(my_attribute) -%}
{%- for user in my_data -%}
{%- if user[my_attribute] or false -%}
{%- set value=user[my_attribute] -%}
{%- set tmp = attribute_collection.append({my_attribute:value}) -%}
{%- endif -%}
{%- endfor -%}
{{- attribute_collection | unique(attribute=my_attribute) | sort(attribute=my_attribute) -}}
Test a form: How to get a form's URL
Recall that you can access all forms in your form list in Rewst. Understanding how to test a form can sometimes be confusing due to its intrinsic link to a workflow. To get the Form URL for testing directly from a workflow:
Locate the trigger on the workflow.
Click View Form URLs.
Select the desired organization's form from the list.

Restrict form drop-downs
The onboarding form includes a number of fields to be filled out when onboarding new users. The default behavior of all the dropdown fields is to pull the list of options from the API. This is because the dropdown fields have Dynamic Options toggled on.

While this may work in many cases, there are scenarios where it makes sense to limit the number of options based on the customer segment you're working with. An example of this might be that you need to limit which email domains each customer sees. You may also want to limit which locations customers can choose from. In any case, you can set specific values for the default_form
organization variables to use in your forms.
Add an organization variable to a form
You can add default values for any of the form organization variables below:
Limit the email domains in the onboarding form
Add the org variable to an organization
Navigate to Configuration > Organization Variables.
Click Add at the top right.
Enter in the following for the new organization variable:
Name:
form_default_email_domain
Value:
["email domain"]
Category: General
Organization: Choose Your Organization

Any value you add to a variable must exist in the list that the form value is pulling from. An example of this would be that any email domain added as a default must exist in the list that is pulled from the Microsoft API.
Next, the variable can be added to the form field.
Add the org variable to the form field
Navigate to Automations > Forms.
Open the User Onboarding Form.
Click to open the settings for the Email Domain Name field.
Enter
true
in the schema.enumSourceWorkflow.input.force_default setting.Enter
email_domain
in the schema.enumSourceWorkflow.input.choose_variable setting.
Click Save.
Make sure to set the org variable values for any company organization using the form. For example, say there are three company organizations that need to use the same form with a list of three domains to choose from. Each organization needs to have the variable added with the domain values set. If you only set the variable and values in Company 1, the other two Companies won't see any options to choose from.
Last updated
Was this helpful?