InteractiveHTML

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

Outgoing

Configure the task

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:

1
<p>Device: <!deviceName!></p>

Variables:

1
{
2
  "deviceName": "router1.example.com"
3
}

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:

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

Output:

1
{
2
  "name": "my-name",
3
  "email": "first.last@example.com",
4
  "message": "hi"
5
}

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:

1
<form name="userForm">
2
  <input name="name" value="my-name">
3
  <input name="email" value="first.last@example.com">
4
</form>
5
<input name="customName" value="my-custom-name">

Output:

1
{
2
  "userForm": {
3
    "name": "my-name",
4
    "email": "first.last@example.com"
5
  },
6
  "orphan": {
7
    "customName": "my-custom-name"
8
  }
9
}

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:

1
<form action="/submit-one" method="post">
2
  <input type="text" name="name">
3
</form>
4
5
<form action="/submit-two" method="post">
6
  <input type="email" name="email">
7
</form>

Output:

1
{
2
  "form0": {
3
    "name": "my-name"
4
  },
5
  "form1": {
6
    "email": "first.last@example.com"
7
  }
8
}

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

1
<form name="confirmForm">
2
  <p>Device: <!deviceName!></p>
3
  <p>Requested by: <!requester!></p>
4
  <label>Comments:<br />
5
    <textarea name="comments"></textarea>
6
  </label>
7
</form>

Variables

1
{
2
  "deviceName": "router1.example.com",
3
  "requester": "first.last@example.com"
4
}

Buttons

Output

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

1
{
2
  "confirmForm": {
3
    "comments": "Confirmed, proceeding with change window."
4
  }
5
}

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.