Custom JavaScript

Add a small amount of JavaScript to a question to read or set answers, read URL parameters, change variables, or react to the respondent's input. Custom JS is opt-in per question and is always sandboxed. See Limits & Security for what it can and cannot do.

Status: the JavaScript runtime API (window.Intuify.survey.*) is exposed to the respondent page and the builder preview. Authoring the per-question onLoad / onSubmit script editor is shipping behind a follow-up release; until then, you can use the runtime API from external tools (browser console, embed wrappers, Tag Manager). The reference pages below describe the public surface that ships today.

When to use custom JS#

• Pre-fill an answer from URL parameters.
• Read another question's answer and display it elsewhere on the page.
• Set a survey variable based on a calculation.
• Translate a Qualtrics widget that you migrated to Intuify.

For most use cases, the no-code features cover you:

Reach for custom JS only when you've ruled the above out.

How it works#

Each survey page gets a fresh window.Intuify object. The full API lives on window.Intuify.survey:

// Read the current question's text after piping
const text = window.Intuify.survey.getQuestionText("q_1");

// Pre-fill an answer
window.Intuify.survey.setResponse("q_2", "red");

// Read URL params (e.g. ?source=email)
const { urlParams } = window.Intuify.survey.getEmbeddedData();
console.log(urlParams.source);

The three legacy variable shortcuts still work for backward compatibility:

window.Intuify.setVariable("score", 42);
window.Intuify.getVariable("score"); // 42
window.Intuify.getAllVariables(); // { score: 42, ... }

See API reference for the full method list and Examples for ready-to-use snippets.

Lifecycle (planned)#

Once the per-question onLoad / onSubmit editor ships:

Text/Graphic display blocks support only onLoad (there's no response to submit).

Preview vs. live#

The runtime API is identical between the builder preview and the live respondent page, with two caveats:

1. Preview survey variables aren't persisted (they reset each preview run).
2. The server-driven respondent runtime treats setVariable as a no-op for now. Variable writes from custom JS land in the next phase.

Either way, every getter (getQuestionText, getChoices, getResponse, getMetadata, etc.) works the same in both environments. Test in preview before going live.

Migrating from Qualtrics#

If you're porting a Qualtrics question that used this.questionText, getChoices(), Qualtrics.SurveyEngine.setEmbeddedData(), etc., the quick translation:

For full plugin payloads (themes, columns, plugin config) call Intuify.survey.getQuestionPayload(id), which returns the same shape your widget already receives.

The Interface code editor#

Some question types in Intuify are rendered by a small web component rather than by the standard builder UI. Interface code is where that component is read, changed, previewed and saved, and it is the closest thing in the product to writing JavaScript for a question today.

The editor is available to Intuify platform administrators. On a question card, look for the code icon in the row of icons at the top right. Its tooltip reads Interface code — copy it from here, or paste code onto this question on a question that has no interface of its own yet, and Custom interface code — open to edit or copy on one that already has one. Click it and the editor opens full screen. The icon is not offered on questions from the palette's StorySync AI Qual section, nor on Text & Graphic, Play Video, Create / Edit Global Variables or Display Global Variables questions. The Instruction Swiper does offer it: it is built on Text & Graphic but draws its own screens, so its code opens on the swiper's own and is saved as a copy of it.

Under the Interface code title you see the element the code defines (for example <my-card-select>), the question's type, and the build the code came from. If nothing has been detected yet it reads no element detected.

What is on screen#

Two small controls sit beside the pane they act on. Format code, next to the interface.js label, reprints the file with consistent indentation. Beside Live preview you can switch the preview between Mobile, Tablet and Desktop, because layout choices that only apply on a phone are invisible at one fixed width. The badge there reads Updates when you pause: the preview rebuilds a moment after you stop typing, not on every keystroke. The refresh button next to it is titled Run the widget again from scratch, which is what to reach for when the widget itself has got stuck rather than the code being wrong.

While you have unsaved changes, a Draft · unsaved badge appears above the code. The line under the code pane is the running verdict on what you have written: the element and its size in green when the code is fine, a problem in red when it is not, or an amber note about something that may limit what the server can read. A red line means Save & apply stays disabled until you fix it. An amber note does not block saving, it just tells you why a save might come back refused.

At the bottom, Full stored bundle expands to show the exact code that runs for respondents, for when you want to check what was actually stored rather than what you are editing.

The AI panel#

Press AI in the header to open the prompt box. On a question that already has code the label reads Describe the change you want and the note under it says the change is made to the file in place. On an empty question it reads Describe the interface you want. Press Generate to run it. Follow-up prompts can refer back to earlier ones, and Ctrl+Z undoes generated changes one at a time.

The Built-in functions button in the header opens a short reference of the blocks that sit at the top of the file and the functions the interface can call.

Closing without saving#

If you close the editor with unsaved changes, a strip appears asking whether to close and discard them. Keep editing returns you to the code. Discard throws the changes away. There is no autosave here: nothing reaches the question until you press Save & apply.

Saved versions#

Every Save & apply writes one version. The header button that shows the current version number (for example v3) opens Saved versions, a list of everything saved for this interface, newest first.

Each row shows the version number, the date and time it was saved, and published if that version has been published. The version the question is actually running is labelled on this question instead of offering a button.

To go back to an earlier version, press the restore button on its row. That loads that version's code into the editor and tells you it is in the editor and needs a save to apply. Restoring does not change the question on its own, and it does not remove the versions saved after it. Saving from there writes a brand new version on top, so going back is itself something you can undo.

The last row in the list is Original, which is not a version. It is what the question opened on before anything in this editor touched it: either the interface as it ships, or the script uploaded for this question type. It has its own restore button, and restoring it behaves exactly like restoring a version, so your own saved versions survive it.

On an interface nothing has been saved for yet, the list says so and points you at Save & apply to write the first version.

Editor options (question text)#

The rich text editor used for question text and other authored copy has its own small settings dialog. In the toolbar, at the right-hand end, the button titled More editor options opens Editor options.

The dialog has one group, Editor mode, with two choices:

Picking a mode applies it immediately and closes the dialog. The current mode is highlighted, so the dialog also tells you which one you are in.

HTML is not in this dialog. It has its own toolbar button next to it, which reads Switch to HTML and then Switch to Standard View once you are there.

Related guides#

• Custom JS API reference
• Custom JS examples
• Limits & security
• Carry forward & piping
• Flow editor