> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.itential.com/itential-platform/6/release-notes/breaking-changes/form-builder-removed/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server.

# Form Builder removed

> Breaking change notice that Form Builder has been removed in Platform 6, with guidance on replacing legacy forms with JSON forms.

**Form Builder** has been removed from Itential Platform following its deprecation in version 2023.2. With this removal, you can no longer create legacy forms; however, existing legacy forms continue to work for the time being.

### What should I do?

JSON Form Builder has replaced Form Builder. To maintain functionality, replace instances of legacy forms with JSON forms where possible. JSON forms and legacy forms are structured differently within workflows, so some alterations may be necessary. In particular, legacy forms based on NSO service models may require some effort to replace, especially if they send input to the `SaveInstances` task.

For instructions on adapting NSO-based JSON forms to a workflow expecting legacy forms, see:

* [Replace legacy forms based on NSO service models](#replace-legacy-forms-based-on-nso-service-models)
  * [Before you begin](#before-you-begin)
  * [Create an NSO-based JSON form](#create-an-nso-based-json-form)
  * [Adapt an NSO-integrated workflow](#adapt-an-nso-integrated-workflow)
  * [Create the transformation](#create-the-transformation)

Itential strongly recommends refactoring any use cases currently met by legacy forms to use JSON forms instead. If you have a use case that cannot be met by JSON forms, you may be able to sideload Form Builder as a custom application. Contact your Customer Success representative for more information.

## Replace legacy forms based on NSO service models

To adapt NSO-based JSON forms to a workflow expecting legacy forms, you must first create a JSON form to replace the legacy form and then make the existing workflow compatible with the new JSON form.

### Before you begin

Ensure you are familiar with each of the following before proceeding:

* [JSON Forms](/itential-platform/studio/json-forms/overview)
* JST Designer
* Workflows

### Create an NSO-based JSON form

NSO-based JSON forms are constructed in much the same way as legacy forms.

#### Open JSON Form Builder

Open JSON Form Builder.

#### Select a service model

Select the **YANG Models** dropdown from the right-hand Form Elements bin. Click the dropdown that appears and type the path of the NSO service model you will be sourcing fields from into the filter bar. Select your desired service model. Its fields populate under the **YANG Models** header.

#### Build the form

Drag service model fields onto the form as you would any other elements in the bin.

**ServiceModelPath**

NSO-based legacy forms automatically infer and output the appropriate service model path depending on what model the form was based on. JSON forms do not natively mimic this functionality. To compensate, you must supply JSON forms with a manually created, dynamic dropdown field named **`ServiceModelPath`**. Configure it as follows:

* Method: `GET`
* Base route: `/service_management`
* API route: `/service_models`
* Source property: `/`
* Property key: `/name`
* Dropdown label: `Value as label`

When filling in the form at runtime, the dropdown field options populate based on any NSO service models discovered by the system. Select the model that your form and workflow are designed to interact with.

### Adapt an NSO-integrated workflow

Next, make your existing workflow compatible with your new JSON form. Two tasks — `ShowFormByName` and `ShowJSONForm` — are responsible for rendering legacy forms and JSON forms in a workflow, respectively. Each outputs a different data structure to subsequent tasks or job variables. These differences are the main source of difficulty in replacing service model-based legacy forms with JSON form counterparts.

Both task outputs are structured as JSON objects, but the particulars vary:

* Each task output has a root key named `export`. The value of this key is a JSON object in which each form field has its own corresponding key (referred to as a **field key**).
* `ShowFormByName` (legacy) wraps the value of each field key in an array.
* `ShowJSONForm` (JSON) does **not** wrap the value of each field key in an array.

For example, `ShowFormByName` may output the following for a legacy form representing an apple:

```json
{
    "export": {
        "Name_FieldKey": [
            "Apple"
        ],
        "Color_FieldKey": [
            "Red"
        ],
        "Ripe_FieldKey": [
            true
        ]
    }
}
```

`ShowJSONForm` outputs the following for a JSON form with the same field structure:

```json
{
    "export": {
        "Name_FieldKey": "Apple",
        "Color_FieldKey": "Red",
        "Ripe_FieldKey": true
    }
}
```

The following caveats also apply to service model-based legacy forms:

* `ShowFormByName` nests all fields sourced from an NSO service model in the value of a field key named after that service model's path.
* In general, each of these fields is a primitive key-value pair — for example, `"name": "ios1_Device"`.
* The `device` field is the main exception. It is represented as a reference key-value pair (an array) — for example, `"device": ["cisco_CSR_181"]`.

For example, `ShowFormByName` may output the following for a legacy form representing the `EBH` service model:

```json
{
    "export": {
        "/ncs:services/EBH:EBH": [
            {
                "name": "ios1_Device",
                "device": [
                    "cisco_CSR_181"
                ],
                "evc-even": "2",
                "evc-odd": "1"
            }
        ]
    }
}
```

`ShowJSONForm` outputs the following for a JSON form with a similar field structure (noting the differences from [Create an NSO-based JSON form](#create-an-nso-based-json-form)):

```json
{
    "export": {
        "serviceModelPath": "/ncs:services/EBH:EBH",
        "name": "ios1 Device",
        "device": "cisco CSR 181",
        "evcEven": "2",
        "evcOdd": "1"
    }
}
```

If your workflow was originally designed to send data to the `SaveInstances` task via a service model-based legacy form, it expects output in the former format. Your workflow must use a transformation to convert the output of the new JSON form to that of a similar legacy form. See [Create the transformation](#create-the-transformation) below.

### Create the transformation

The following transformation translates the output of the `ShowJSONForm` task into a format mimicking that of the `ShowFormByName` task, ensuring the output conforms to the `SaveInstances` task's requirements.

We will be translating the following data:

```json
{
    "export": {
        "serviceModelPath": "/ncs:services/EBH:EBH",
        "name": "ios1 Device",
        "device": "cisco CSR 181",
        "evcEven": "2",
        "evcOdd": "1"
    }
}
```

This example demonstrates the general concepts behind the transformation. It is not a one-size-fits-all solution — you will need to tailor it to fit your own environment.

#### Open JST Designer

Open JST Designer.

#### Add an incoming schema

On the left side of the window, hover over the **Add +** button beneath the Incoming Schemas header and click **Incoming Schema**. The Add Incoming Schema modal opens, pre-populated with:

```json
{
    "$id": "",
    "type": ""
}
```

Replace the JSON schema with the following:

```json
{
    "$id": "export",
    "type": "object",
    "properties": {
        "serviceModelPath": {
            "type": "string",
            "examples": ["/ncs:services/EBH:EBH"]
        },
        "name": {
            "type": "string",
            "examples": ["ios1_Device"]
        },
        "device": {
            "type": "string",
            "examples": ["cisco_CSR_181"]
        },
        "evcEven": {
            "type": "string",
            "examples": ["2"]
        },
        "evcOdd": {
            "type": "string",
            "examples": ["1"]
        }
    },
    "required": []
}
```

Click **Save**.

#### Add a templateLiteral method

Use the search bar above the workbench to locate the `templateLiteral` method. Drag it onto the canvas and click **edit template**. Construct a template string that mimics the legacy format, using the `${}` delimiter for variables:

```json
{
    "${ModelPath}": [
        {
            "name": "${instanceName}",
            "device": [
                "${deviceName}"
            ],
            "evc-even": "${evenValue}",
            "evc-odd": "${oddValue}"
        }
    ]
}
```

Click **Update**.

#### Connect incoming schema values

Connect your incoming schema values to the appropriate `templateLiteral` parameters: `serviceModelPath` → `ModelPath`, `name` → `instanceName`, `device` → `deviceName`, etc.

This substitutes the values into the string, transforming the template into:

```json
{
    "/ncs:services/EBH:EBH": [
        {
            "name": "ios1_Device",
            "device": [
                "cisco_CSR_181"
            ],
            "evc-even": "2",
            "evc-odd": "1"
        }
    ]
}
```

At this stage, this data is still a *string*. The next step converts it to a JSON object.

#### Add a parse method

Use the search bar to locate the `parse` method. Drag it onto the canvas and connect the `templateLiteral` return parameter to the `text` parameter on `parse`. This converts the string output back into a JSON object.

#### Add an outgoing schema

On the right side of the window, hover over the **Add +** button beneath the Outgoing Schemas header and click **Outgoing Schema**. Set `$id` to `export` and `type` to `object`. Click **Save**.

#### Connect and save

Connect the `parse` return parameter to the `export` outgoing schema. Save your changes using the canvas toolbar.

> Breaking change notice that Form Builder has been removed in Platform 6, with guidance on replacing legacy forms with JSON forms.