Add support alongside an existing request form

Review a bot-assisted draft and open the existing form without automatically submitting a ticket.

Before you start

You need a support workspace, an allowed domain, approved instructions and the portal team that can open its existing support form. This stage complements that form: identity, project, files, screenshots and submission remain with the portal. The educational form in the screenshot demonstrates the integration; it is not the customer’s portal and does not prove delivery to its helpdesk.

What to click

  1. Create or select a support workspace in Мои кабинеты and configure its responses and knowledge for your product.
  2. In Конфигурация → Встраивание, configure presentation and the actual Ссылка на существующую форму обращения. Use HTTPS, a local path or anchor; opening a programmatic form also requires the portal team’s event handler.
  3. Configure the policy and message confirmation. Optionally enable Отвечать только при найденных материалах. Click Сохранить и применить.
  4. Register the domain and install the snippet with data-mode="support" and the selected workspace slug. The website team may also set data-support-url to the actual form URL or anchor as an independent recovery path.
  5. Ask a question in the widget. Click Обратиться к специалисту to contact a person; the action remains available when the bot cannot answer.
  6. Review Тема and Черновик обращения, edit the text and remove unnecessary data. Click Открыть форму с черновиком. Without a portal handler, use Копировать черновик and Открыть форму поддержки instead.
  7. After the portal confirms opening and prefilling, the widget collapses. Check the existing form, attach files and use its own submit button. Only the existing support workflow can confirm that a ticket was registered.
  8. Click Новый диалог for another issue. The portal team also resets chat on logout or user/project changes. Previous server history is retained; local messages, queued sends and consent are cleared.
Support widget settings: actual console, educational data
Support widget settings: actual console, educational data
2026-10-15 · Actual console and widget on a local integration fixture with educational data. The sample form does not submit real tickets.
  1. Название в виджете
  2. Ссылка на существующую форму обращения
  3. Отвечать только при найденных материалах
  4. Сохранить и применить
Editable draft: actual widget on an educational existing-form page
Editable draft: actual widget on an educational existing-form page
2026-10-15 · Actual console and widget on a local integration fixture with educational data. The sample form does not submit real tickets.
  1. Черновик обращения
  2. Открыть форму с черновиком
  3. Копировать черновик
  4. Обратиться к специалисту

What the portal team integrates

The customer retains its portal source code. Its developers install the widget and implement their form callback using these instructions; IAM.Bot does not need access to that repository. The developer integration package contains a detailed Russian guide for both sites, the bridge, JSON Schema and an educational example. Replace the example’s SDK/API origins and workspace slug before running it. The integration contract below applies in either language. The separate developer appendix and beta checklist in Russian can be forwarded to your website and portal teams. The instructions are reusable: configure your own company name, domains, form categories and recipients.

Handle the same-page iambot:support-request version-one event. Validate fields, prefill the existing form and acknowledge only its successful opening. The optional support-form-bridge.js validates bounded fields, scopes by workspace slug and handles callback errors. Resolve user and project from the portal’s authenticated context; widget metadata grants no permissions. No transcript is placed in a URL. The widget does not read account data or files and does not create a ticket.

Load support-form-bridge.js from the same origin as widget.js in your snippet. Install one listener after the bridge loads:

const disconnect = window.IAMBotSupportBridge.install({
  workspaceSlug: "REPLACE-WITH-SUPPORT-SLUG",
  async openForm(request, { signal }) {
    // Your portal implements these functions; the API shown here is illustrative.
    const context = portal.currentContextKey();
    const form = await portal.openSupportForm();
    if (signal.aborted || context !== portal.currentContextKey()) return false;
    const draft = "Subject: " + request.subject + "\n\n" + request.message;
    const accepted = await portal.confirmMergeIfDraftExists(form, draft);
    if (!accepted || signal.aborted || context !== portal.currentContextKey()) return false;
    portal.setSupportCategory(form);
    portal.mergeMessageAsPlainText(form, draft);
    return portal.isFormVisibleAndPrefilled(form); // exactly true; no submission
  }
});

If your form’s Тема field is a category dropdown, choose the agreed support category and prepend the free-text subject to the message when no separate title field exists. Offer merge, replace or cancel for an existing draft. Preserve contacts, project, attachments and screenshots. Use plain-text values or the normal form state API, never innerHTML.

After each asynchronous wait, check signal and the authenticated user/project context. Call window.IAMBotChat?.reset() on logout or context changes, and disconnect() on unmount. Acknowledge only completed opening: the operation is cancelled after five seconds and must not fill a form later. The same-page event does not prove authorization.

Verify the result

The form contains the edited text. Opening does not submit it, and existing attachments still work. Verify actual specialist receipt after manual submission. If no acknowledgement arrives within five seconds, the draft remains available; the widget does not claim that the form opened or that a ticket was registered.

Recovery

Copy the draft and use the direct link, or open support from the portal’s normal menu. The administrator checks the saved URL; the portal team checks its handler and acknowledgement after actual opening. Model failures must not block the existing form. Automatic tickets and operator replies in chat require a separate integration and are outside this stage.