> 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/studio/tasks/reference/interactive-html/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server.

# InteractiveHTML

> Reference for the Interactive HTML Work Center task, which renders builder-authored HTML and returns operator input as output variables.

Platform 6.5.2+

Renders custom HTML and CSS, and returns operator input as output variables.

## Before you begin

Work Center must be enabled in your Itential Platform environment.

## Use cases

Use this task when you want to design the operator's screen yourself. You author the HTML and CSS, Work Center renders it, and the operator's submission returns as task output for the workflow or agent to use. Common scenarios include:

* The form needs a particular look and feel—including your branding, your layout, or your terminology—and you want direct control over it.
* Context and input belong together, such as a report, a device list, or output from an earlier task, paired with the operator's decision directly below it.
* An earlier canvas task has already resolved the data, and this step only needs to render it and collect a response.

## Task properties

### Incoming

| Variable      | Type   | Required | Description                                                                                                                                                                                                                                    |
| ------------- | ------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `header`      | String | No       | Text that appears above the body's content. Use it for a task title or short instruction to the operator.                                                                                                                                      |
| `body`        | String | Yes      | The HTML5 document that renders in Work Center. Include CSS inline or in a `<style>` block. Add a `<form>` element to collect operator input. Only one `<form>` is supported per task.                                                         |
| `btn_success` | String | Yes      | Text for the button that submits the form and marks the task as successful.                                                                                                                                                                    |
| `btn_failure` | String | No       | Text for the button that submits the form and marks the task as failed. Leave empty if this task always requires successful submission.                                                                                                        |
| `variables`   | Object | No       | Displayed as **Variables** in the task panel. Values to substitute into the content before it's shown to the operator. Each key matches a `<!nameOfVariable!>` placeholder in the content. Each value replaces that placeholder as plain text. |

### Outgoing

| Field    | Type   | Description                                                                                                                                                                                                                                                                                                                                                                   |
| -------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `export` | Object | The fields captured from inside the `<form>` element, keyed by its `name` or `id`. If the form has neither, this key falls back to a positional name, such as `form0`, `form1`, and so on. Fields captured from outside the `<form>` element appear in an `orphan` object, which is present only when the content has both a `<form>` and additional named fields outside it. |

## Configure the task

#### Add a title

In the task panel, enter text for **header**. This appears as a title above the rendered content.

#### Author the body's content

Write your HTML5 document in **body**. Include CSS inline or in a `<style>` block. Add a `<form>` element if you need operator input.

#### Add variables

If your content uses `<!nameOfVariable!>` placeholders, add matching keys and values to **Variables**.

#### Set button text

Enter text for the **btn\_success**, such as `Submit`. If the task needs a second path, for example `Reject`, enter text for **btn\_failure**.

## Content authoring

### Supported form elements

Interactive HTML renders:

* Text fields
* Checkboxes
* Radio buttons
* Dropdowns, including multi-select
* Date pickers
* Text areas

### Variable placeholders

Anywhere a `<!nameOfVariable!>` placeholder appears in `body`, it's replaced with the matching value from `variables` before the content is shown to the operator.

**Example**

Content:

```html
<p>Device: <!deviceName!></p>
```

Variables:

```json
{
  "deviceName": "router1.example.com"
}
```

What the operator sees:

> Device: router1.example.com

### Reserved field names

Avoid naming form fields `name` or `id`. These are reserved, and not supported as operator input field names.

### Limitations and considerations

* **No limit on the number of forms.** A task can contain as many `<form>` elements as you need. If multiple forms share the same name, only the first keeps that name. Later duplicates fall back to a positional key, `form1`, `form2`, and so on. For example, four forms named `interfaceConfig` would output as `interfaceConfig`, `form1`, `form2`, and `form3`.
* **No JavaScript.** `<script>` tags and inline JavaScript are stripped before the content renders.
* **No runtime data fetching.** The rendered content doesn't fetch data when the task runs. Resolve all data before the task runs, using an upstream **Render Jinja Context** or **Run Code on Canvas** task.
* **No templating engine.** Pre-render your HTML upstream if you need Jinja or custom filters.
* **File uploads are excluded from output**, even when present in the content.
* **Every input field needs a name.** An input without a `name` attribute is excluded from output, since there's no way to derive a variable name for it.
* **Put submit and cancel controls in the footer.** Don't add submit or cancel buttons inside the body's HTML. Use the task's **btn\_success** and **btn\_failure** fields instead, which apply across the entire set of forms.

## Outgoing structure

How outgoing content is structured depends on whether `body` contains a `<form>` element, and whether that form has a `name` or `id`.

### No `<form>` element

If the content has no `<form>` element at all, every named `input`, `select`, or `textarea` the operator fills in is still captured. The result stays flat as a plain key-value object because there's no form to disambiguate against.

Content:

```html
<input name="name" value="my-name">
<input name="email" value="first.last@example.com">
<textarea name="message">hi</textarea>
```

Output:

```json
{
  "name": "my-name",
  "email": "first.last@example.com",
  "message": "hi"
}
```

### A `<form>` plus other fields outside it

If the content has a `<form>` plus other fields outside it, the form's fields go into their own bucket, keyed by the form's `name` or `id`. The non-form fields are grouped together separately, under `orphan`.

Content:

```html
<form name="userForm">
  <input name="name" value="my-name">
  <input name="email" value="first.last@example.com">
</form>
<input name="customName" value="my-custom-name">
```

Output:

```json
{
  "userForm": {
    "name": "my-name",
    "email": "first.last@example.com"
  },
  "orphan": {
    "customName": "my-custom-name"
  }
}
```

`orphan` only appears when the content has both a `<form>` and additional named fields outside it.

### A `<form>` without a `name` or `id`

If a `<form>` doesn't have a `name` or `id`, it falls back to a positional key: `form0`, `form1`, and so on, in document order.

Content:

```html
<form action="/submit-one" method="post">
  <input type="text" name="name">
</form>

<form action="/submit-two" method="post">
  <input type="email" name="email">
</form>
```

Output:

```json
{
  "form0": {
    "name": "my-name"
  },
  "form1": {
    "email": "first.last@example.com"
  }
}
```

## Work Center behavior

* Reopening a completed task shows what was submitted, read-only.
* The Work Center review screen shows previously submitted answers instead of discarding them.
* Pressing Enter in a form field does not reload the page.

## Example: device change confirmation

This example renders a device name and requester using variable placeholders, then collects an approver's comment before routing the workflow down a success or failure transition.

### Body

```html
<form name="confirmForm">
  <p>Device: <!deviceName!></p>
  <p>Requested by: <!requester!></p>
  <label>Comments:<br />
    <textarea name="comments"></textarea>
  </label>
</form>
```

### Variables

```json
{
  "deviceName": "router1.example.com",
  "requester": "first.last@example.com"
}
```

### Buttons

| Field            | Value   |
| ---------------- | ------- |
| **btn\_success** | Approve |
| **btn\_failure** | Reject  |

### Output

If the operator selects Approve with a comment, the task returns:

```json
{
  "confirmForm": {
    "comments": "Confirmed, proceeding with change window."
  }
}
```

The task follows the workflow's success transition. If the operator instead selects Reject, the task follows the failure transition, with `export` populated from whatever was in the form at that point.

> Reference for the Interactive HTML Work Center task, which renders builder-authored HTML and returns operator input as output variables.