Skip to main content

SG noCode Form Builder

Overview​

The Form Builder interface is organized into three main areas that work together to define and preview the form:

  • JSON Schema Panel (Left Column)
  • Form Preview (Center Column)
  • Fields Palette (Add Fields button)

Users may switch between View Mode and Edit Mode depending on their permissions or configuration needs.

SG noCode Form Builder

SG noCode Form Builder

Builder Modes​

View Mode​

View Mode displays the form without allowing structural modifications. Users can:

  • Inspect form fields
  • Review layout and labels
  • View conditional indicators
  • Validate field structure

This mode is typically used by users who have read-only access or who only need to review the form configuration.

Edit Mode​

Edit Mode enables full editing capabilities within the builder. When activated, the full layout becomes interactive. Users can:

  • Add or remove fields
  • Reorder fields
  • Modify field configuration
  • Edit the underlying schema
  • Configure conditional logic
  • Test form behavior

JSON Schema Panel​

The JSON Schema Panel displays the underlying schema that defines the form structure. This schema represents the authoritative configuration used by the platform to render and validate the form. Users can:

  • Scroll through the schema
  • Expand the panel for detailed editing
  • Collapse the panel to focus on the visual editor
  • Modify the schema directly

Changes made in the schema are reflected in the Form Preview.

Direct editing of the schema is typically used by advanced users who need to implement configurations not available through the visual editor.

Form Preview​

The Form Preview displays a live rendering of the form while it is being built. The preview allows users to interact with fields and manage the layout in real time. Available actions include:

  • Adding new fields
  • Reordering fields
  • Editing field settings
  • Removing fields
  • Entering Test Mode

Each field is represented as a field card containing configuration controls. Field cards include:

  • Settings icon – opens the field configuration modal
  • Delete icon – removes the field from the form
  • Indicators showing whether the field is:
    • Required
    • Disabled
    • Controlled by conditional logic

The preview updates immediately when changes are made.

Fields Palette​

The Fields Palette provides the components that can be added to the form.

Fields can be dragged into the preview area and positioned anywhere within the form.

Fields Palette

Fields Palette

Basic Fields​

Basic fields represent standard input types. Available fields include:

  • Text Field
  • Email Field
  • Number Field
  • Date Field
  • Text Area
  • Dropdown/Select
  • Checkbox
  • Radio Buttons
  • Password

Advanced Fields​

Advanced fields support more complex data input or dynamic behavior. Examples include:

  • Section
  • Multiselect
  • Async Select
  • Autosuggest

Sections allow grouping related fields into logical blocks within the form.

Custom Components​

The builder supports custom components that extend form functionality. Available options include:

  • Custom Code
  • Custom Code Frontend

These components allow developers to integrate custom logic or UI behavior into the form.

Custom Code Widgets​

The builder supports custom code components that allow developers to extend form functionality.

Custom Code alert

When a form contains a Custom Code Widget, an alert appears in the Form Builder asking you to acknowledge the custom code before proceeding. This ensures you have the opportunity to review the code before using it.

Before acknowledging, you can open the widget settings to inspect the code, but all other actions are disabled. Select Acknowledge Custom Code to enable full access to the form.

Custom Code alert

Custom Code alert

Custom Code Widget​

The CustomCode widget enables dynamic and context-aware customization of form fields in real-time. By executing custom JavaScript (JS) code in a Node.js v20 runtime environment, it allows users to fetch, process, and populate form data dynamically.

Key Features:

  1. Dynamic Data Fetching: Fetch data from APIs or other sources in real-time.
  2. Custom JavaScript Support: Users can write custom JS code to handle data processing and form updates.
  3. Runtime Environment: Executes in a Node.js v20 environment with pre-configured capabilities.
  4. Contextual Awareness: Leverages variables like sg_context for details such as org, wfgrp, stack, and wf.

How it works:

Users provide custom JavaScript code in the apiSchema.handler configuration. This code is executed to process data and dynamically update the jsonSchema and uiSchema of the form.

UI Schema Properties​

  1. API Schema - The apiSchema key in the UI schema is used to define the logic required for dynamic behavior. It allows you to pass custom JavaScript code, specify when it should run, and provide cloud configuration to support it.
    1. handler - JavaScript code to be executed based on the trigger. Typically used to fetch dynamic options or perform actions on selection.
    2. triggerType - The triggerType key defines when the JavaScript code should be executed. It supports the following values:
      • onLoadItems – Executes the JavaScript code when the options dropdown is opened. Applicable only to select and multiselect fieldTypes.
      • onSelection – Executes the JavaScript code when an option is selected from the dropdown or after value has been passed in case of string fieldType. The onSelection trigger in the string field Custom Code widget functions behaves like an onblur event. That is , this trigger activates when the user clicks away from or leaves the field, rather than when text is selected within the field.
    3. Deployment Platform Config - Cloud providers can be passed and then used inside Javascript code using deploymentPlatformConfig.
  2. Field Type – The fieldType key in the UI schema determines the type of input field to render. It supports the following values:
    • select – Renders a single-select dropdown input. This is the default fieldType and is commonly used for selecting one item from a list.
    • multiselect – Renders a multi-select dropdown input, allowing users to choose multiple options.
    • string – Renders a basic text input field.

Accessible Variables in JS Code​

  • fetch - The standard JavaScript Fetch API, used for making network requests.

  • SDK - The SDK object provides access to classes and methods exported by the following JavaScript cloud SDKs:

    • @azure/identity
    • @azure/arm-resources
    • @aws-sdk/client-ec2
    • @aws-sdk/client-ssm

    These SDKs can be used within your JavaScript code to interact with Azure and AWS services programmatically.

  • sg_context - Provides contextual information and user metadata.

    • viewContext - Contains contextual identifiers related to the current form or view. Keys may include:
      • org
      • wfgrp
      • stack
      • wf
      • template
      • templateType
      • currentDeploymentPlatformConfig - Provides configuration details for the selected cloud connector, if any.
    • user - Contains information about the current user, such as:
      • email
      • role
    • token - The user's ID token (JWT). Can be used to authenticate API requests to StackGuardian’s backend or other secured endpoints.
    • deploymentPlatformConfig - Provides configuration details for the selected cloud connector, if any. These are the AWS and Azure deployment platform configurations that can be accessed:
      • AWS: integrationId, profileName, awsDefaultRegion, awsAccessKeyId, awsSecretAccessKey
      • AZURE: integrationId, profileName, armClientSecret, armClientId, armSubscriptionId, armTenantId
    • jsonSchema - This can be used to access current jsonSchema.
    • uiSchema - This can be used to access current uiSchema.
    • formData - Contains the current values of all form fields. Use this to read the value of other fields in the same form and create inter-field dependencies. Example: sg_context.formData.myFieldName
    • formSource - Indicates the context in which the form is being rendered — i.e., whether the user is creating or updating a resource, and which type of resource. Use this to conditionally show fields, change options, or adjust defaults based on the operation. See formSource example. Possible values:
      • WORKFLOW_CREATE – User is creating a new workflow
      • WORKFLOW_UPDATE – User is updating an existing workflow
      • TEMPLATE_CREATE – User is creating a new template
      • TEMPLATE_UPDATE – User is updating an existing template
      • POLICY_UPDATE – User is updating a policy
    • triggerInfo - Use this to access information about the trigger of code execution. triggerInfo will always contain triggerType (onSelection or onLoadItems). valueSelected is only present when triggerType is onSelection, and indicates the value selected by the user. It will be absent (undefined) when triggerType is onLoadItems.
  {
      "$schema": "http://json-schema.org/schema#",
      "type": "object",
      "properties": {
          "workflow_output": {
              "title": "Workflow Outputs",
              "type": "string"
          }
      }
  }

Context Inputs​

Context Inputs let you set example values for the context variables available in your JavaScript code. Use them to test and debug your code directly within the builder. The following context variables are available:

  • viewContext — contextual identifiers for the current form:
    • org — the organization name
    • wfgrp — the workflow group name
    • stack — the Stack name
    • wf — the Workflow name
    • template — the template name
    • templateType — the template type
    • currentDeploymentPlatformConfig — the selected cloud connector, used for testing your JavaScript only
  • user — information about the current user: Email and Role
  • formSource — the context in which the form is being rendered (for example, Workflow Update)
  • formData — the current form data, expressed as a JSON object

Custom Frontend Widget​

The CustomCodeFrontend widget enables dynamic and context-aware customization of form fields in real-time, allowing users to fetch, process, and populate form data dynamically. Unlike the CustomCode widget, where the JavaScript code is executed in a backend Lambda environment, this widget executes the JavaScript directly in the user's browser.

This is useful for scenarios where users need to dynamically adjust the form fields based on real-time data, such as fetching workflow outputs from the StackGuardian API.

note

The CustomCodeFrontend widget does not make use of Cloud Connectors (Azure, AWS, GCP) to fetch data from Cloud Providers. For these use cases, the CustomCodeWidget should be used.

Key Features:

  1. Dynamic Data Fetching: Fetch data from APIs or other sources in real-time.
  2. Custom JavaScript Support: Users can write custom JavaScript to handle data processing and form updates.
  3. Contextual Awareness: Leverages variables like sg_context for details such as org, wfgrp, stack, and wf.

How it works:

Users provide custom JavaScript code in the apiSchema.handler configuration. This code is executed directly in the frontend (in the user's browser) to process data and dynamically update the jsonSchema and uiSchema of the form.

UI Schema Properties​

  1. API Schema - The apiSchema key in the UI schema is used to define the logic required for dynamic behavior. It allows you to pass custom JavaScript code, specify when it should run, and provide cloud configuration to support it.
    1. handler - JavaScript code to be executed based on the trigger. Typically used to fetch dynamic options or perform actions on selection.
    2. triggerType - The triggerType key defines when the JavaScript code should be executed. It supports the following values:
      • onLoadItems – Executes the JavaScript code when the options dropdown is opened. Applicable only to select and multiselect fieldTypes.
      • onSelection – Executes the JavaScript code when an option is selected from the dropdown or after value has been passed in case of string fieldType.
  2. Field Type – The fieldType key in the UI schema determines the type of input field to render. It supports the following values:
    • select – Renders a single-select dropdown input. This is the default fieldType and is commonly used for selecting one item from a list.
    • multiselect – Renders a multi-select dropdown input, allowing users to choose multiple options.
    • string – Renders a basic text input field.

Accessible Variables in JS Code​

  • fetch - The standard JavaScript Fetch API, used for making network requests.
  • sg_context - Provides contextual information and user metadata.
    • viewContext - Contains contextual identifiers related to the current form or view. Keys may include:
      • org
      • wfgrp
      • stack
      • wf
      • template
      • templateType
    • user - Contains information about the current user, such as:
      • email
      • role
    • token - The user's ID token (JWT). Can be used to authenticate API requests to StackGuardian’s backend or other secured endpoints.
    • jsonSchema - This can be used to access current jsonSchema.
    • uiSchema - This can be used to access current uiSchema.
    • formData - Contains the current values of all form fields. Use this to read the value of other fields in the same form and create inter-field dependencies. Example: sg_context.formData.myFieldName
    • formSource - Indicates the context in which the form is being rendered — i.e., whether the user is creating or updating a resource, and which type of resource. Use this to conditionally show fields, change options, or adjust defaults based on the operation. See formSource example. Possible values:
      • WORKFLOW_CREATE – User is creating a new workflow
      • WORKFLOW_UPDATE – User is updating an existing workflow
      • TEMPLATE_CREATE – User is creating a new template
      • TEMPLATE_UPDATE – User is updating an existing template
      • POLICY_UPDATE – User is updating a policy
    • triggerInfo - Use this to access information about the trigger of code execution. triggerInfo will always contain triggerType (onSelection or onLoadItems). valueSelected is only present when triggerType is onSelection, and indicates the value selected by the user. It will be absent (undefined) when triggerType is onLoadItems.
  {
    "$schema": "http://json-schema.org/schema#",
    "type": "object",
    "properties": {
        "workflows": {
            "type": "string",
            "title": "Workflow List",
            "description": "Select your workflow",
            "enum": [
                "CUSTOM-TEdH",
                "CUSTOM-4sg7",
                "test-26-May",
                "CUSTOM-gitlab",
                "CUSTOM-github",
                "aws-s3-demo-website-0OH2-Copy",
                "aws-s3-demo-website-0OH2"
            ]
        },
        "outputs": {
            "title": "Workflow Outputs",
            "type": "string"
        }
    }
 }

formSource Example​

The following example shows how to use formSource to offer different environment options depending on whether the user is creating or updating a workflow. On create, only safe environments are shown. On update, production becomes available and the current value is preserved as the default.

const isUpdate = sg_context.formSource === 'WORKFLOW_UPDATE';

const environmentOptions = isUpdate
  ? ['dev', 'staging', 'production']  // allow production only on update
  : ['dev', 'staging'];               // restrict to safe envs on create

return {
  jsonSchema: {
    ...sg_context.jsonSchema,
    properties: {
      ...sg_context.jsonSchema.properties,
      environment: {
        type: 'string',
        title: 'Environment',
        enum: environmentOptions,
        default: isUpdate ? sg_context.formData?.environment : 'dev',
      },
    },
  },
  uiSchema: sg_context.uiSchema,
};

Testing Custom Code widgets​

The Custom Code Widget and Frontend Widget include several tools for testing your JavaScript code directly within the builder.

Trigger defines when the JavaScript code is executed. The following options are available:

  • on Dropdown Opened — executes the code when the options dropdown is opened
  • on Selection — executes the code when an option is selected

The Console displays console.log outputs and errors produced when your code runs. Select Run to execute the code and Clear to reset the console output.

The Javascript Templates button provides a set of predefined code templates to use as a starting point.

Preview renders a live preview of the widget output, letting you validate the result before saving.

Testing Custom Code widgets

Testing Custom Code widgets

Field Configuration​

Each field can be configured through the Field Settings modal, accessed via the settings icon on the field card.

The configuration modal allows editing the field's behavior and appearance.

Available settings vary based on field type and may include:

  • Label
  • Placeholder
  • Help Text
  • Required state
  • Disabled state
  • Conditional Logic

Selecting Save applies the changes to both:

  • the visual field
  • the underlying schema

Closing the modal without saving discards the changes.

Field Configuration

Field Configuration

Advanced Mode​

Advanced Mode allows direct editing of the form configuration using:

  • JSON Schema
  • UI Schema

This mode is intended for advanced users who need to configure behaviors not supported by the visual editor.

Advanced Mode can be used to:

  • Modify unsupported fields
  • Define custom validation rules
  • Adjust UI rendering behavior
  • Implement advanced schema structures

Changes made in Advanced Mode are applied when the form is saved.

Advanced Mode

Advanced Mode

Test Mode​

Test Mode allows users to interact with the form and validate its behavior before deployment. When Test Mode is activated:

  • The Fields Palette is replaced with a Form Data panel
  • Users can enter values into the form
  • Conditional logic is evaluated in real time

Test Mode allows users to:

  • Validate field behavior
  • Inspect output values
  • Verify conditional logic
  • Test custom widgets
Test Mode

Test Mode

Generate Schema​

The Form Builder can automatically generate a form schema using the Generate Schema menu, accessible from the toolbar.

Generate Schema

Generate Schema

Paste Code Manually​

Paste and edit Terraform code directly into the builder. If the code contains valid variable definitions, the builder generates form fields automatically.

Paste Code Manually

Paste Code Manually

From Template Repo​

Generates a form schema based on the connected template repository. During generation, the system clones the repository, scans Terraform files, extracts variable definitions, and converts them into form fields.

From Template Repo

From Template Repo

Unsupported Fields​

When importing schemas or generating forms from Terraform, some field configurations may not be supported by the visual editor.

In the form, unsupported fields are marked with an Unsupported Field badge and display the following message: "This field must be edited manually in Advanced Mode using the JSON and UI Schema." To edit them, open the field settings and select the Advanced tab, where you can modify the JSON Schema and UI Schema directly.

Unsupported Fields

Unsupported Fields

Terraform Parsing Limitations​

The Terraform parser supports most standard variable definitions. However, some Terraform constructs may not be supported. Examples include:

  • Complex validation expressions
  • Advanced Terraform functions
  • Dynamically generated variables

If unsupported syntax is detected, the generation process may fail.

Users may resolve this by simplifying the Terraform configuration or manually editing the schema.

Review UI Schema​

Opens the JSON Schema and UI Schema editors, allowing you to view and edit the underlying schema directly. This is the same editor used when modifying unsupported fields in Advanced Mode.

Review UI Schema

Review UI Schema

Error Handling​

During schema generation or import, several types of errors may occur. Common errors include:

Repository Configuration Errors

  • Invalid repository URL
  • Missing repository access permissions
  • Authentication failures

Repository Retrieval Errors

  • Failed to retrieve Git credentials
  • Failed to clone repository
  • Network access issues

Terraform Parsing Errors

  • No .tf files found
  • Empty Terraform files
  • No variable blocks detected
  • Unsupported Terraform expressions

Schema Validation Errors

  • Invalid JSON syntax
  • Unsupported schema structure
  • Missing required schema fields

When errors occur, descriptive messages are displayed to help users resolve the issue.