The in-context Editor

The Editor tab in the Appilot extension and widget lets you teach the assistant about your page while you are looking at it. You point at a button, name it, and the assistant knows about it forever after.

Three sub-tabs cover the three kinds of things you can teach:

• Controls: individual buttons, links, or form fields the assistant can press, click, or fill.
• Forms: a group of inputs the assistant can fill out together (a sign-up form, a search bar, a contact form).
• Zones: named regions of the page like sidebar, footer, or main content, so the assistant can refer to them.

If you have never used the Editor before, start with Controls. It is the simplest entity to teach and the one your assistant uses most often.

When to use the Editor

You should reach for the in-context Editor when:

• You spotted a button or form on your site that the assistant should know about.
• The assistant just tried to interact with something and got it wrong, and you want to fix the way it identifies that element.
• Your team rolled out a redesign and the assistant suddenly cannot find a familiar control.

The in-context Editor handles the fast path: register, name, describe, fix. For deep configuration (visibility rules, defaults, multi-step forms, required fields) you still go to Backoffice, and every form in the Editor has an "Open in Backoffice for advanced settings" link to jump there in one click.

Who can use the Editor

You see the Editor tab only if your organisation has given you the Domain Editor role for the current site. Org admins are editors on every domain their organisation owns. Ask your administrator if you don't see the tab and think you should.

How the Editor changes your assistant

When you register, edit, or deactivate something, the assistant picks it up immediately the next time it runs, with no build or deploy step in between. You can verify by asking the assistant in the chat tab "do you see X on this page?".

---

Identifiers

Every Control, Form, and Zone needs an identifier: a short technical name the assistant uses internally to reference it. The Editor suggests one for you when you pick an element; you can change it before saving.

The rules:

• Lowercase letters, numbers, and underscores only.
• Must start with a letter.
• Should be short and meaningful: submit_button, email_field, sidebar_nav.

If you type something invalid, the Editor shows you a friendly red message under the field; the Save button stays disabled until you fix it.

You cannot change an identifier once saved. The identifier is what the assistant looks up; renaming it would break any conversation that already mentions it. If you really need to rename, deactivate the old one and register a new one with the right name.

How Appilot finds elements

When you pick an element on the page, the Editor stores a locator: a short formula Appilot uses to find that exact element again later. It might be the element's id, an aria-label, a data-testid, or a CSS path.

You see the locator written out in the Register / Edit form. Most of the time you don't need to touch it. If your site changes and the element moves, the locator may stop matching. In that case:

1. Click Edit on the broken row.
2. Click Re-pick.
3. Pick the element again on its new location.
4. Save.

The locator updates and the assistant can find the element again. If the picker can never find the element again (it was renamed in a way the assistant cannot recover), pick a nearby stable element instead and update the Label / Description so the assistant explains what it does.

Pages where this applies

For Forms and Zones you can list the page paths where the entity appears. This is what tells the assistant "the contact form only exists on /contact" so it does not promise it on /about.

The Editor uses chips: each path is a small pill you can remove with ×. To add one, type it and press Enter (or comma), or click Use current page to add the URL you are looking at right now.

Paths can be exact (/admin/users) or wildcards (/admin/* to match anything under /admin). When in doubt, start exact and broaden if needed.

---

Working with the element picker

The picker is the blue, purple, or green highlighted overlay that appears when you click "Pick element on page". A small badge at the top of the screen tells you what you are picking.

• Hover moves the highlight over the element under your cursor.
• Click confirms the pick.
• Esc or the Cancel button cancels.

If you click something inside an internal frame (an iframe), the picker can not reach it. You will see a warning telling you to register that element from Backoffice instead.

Deactivating vs deleting

The Editor never deletes anything. When you click Deactivate, the entity is hidden from the assistant and grayed out in the Editor's list, but it is preserved. You can bring it back any time by toggling Show inactive and clicking Reactivate on the row.

Why? Because deactivated controls are often referenced from forms, views, and conversation history. Hard-deleting them would break those references. Backoffice can do hard deletes when an admin really wants to clean up; the in-context Editor stays on the safe side.

Searching long lists

Once you have a few dozen controls or forms registered, the lists grow. Use the search bar at the top of each sub-tab to filter by name or identifier. Toggle Show inactive to also see what has been deactivated.

The AI suggestion button

Each Description field has a Suggest description (AI) button next to it. It writes a short factual description for the element based on its identifier, label, and surrounding context. The first time you click it, the suggestion is inserted directly into the description box. After that, if you already have text written, the Editor asks whether to Replace, Append, or Cancel before overwriting your work.

Your organisation has a monthly cap on AI suggestions. The number remaining is shown next to the button after the first use.

What lives in Backoffice instead

The in-context Editor intentionally does not expose:

• Control prerequisites (the prior steps, such as a hover or a click, that reveal a hidden control).
• Form visibility rules.
• Field defaults and required-field configuration.
• Multi-tab forms.
• Submit / entry control linkage.

Every form in the Editor carries an Open in Backoffice for advanced settings link to jump straight to the right page for those deeper edits.

Keyboard navigation

The Editor is fully usable with the keyboard:

• Tab moves between fields and buttons. The focused element shows a clear blue ring.
• Arrow keys move between the Controls / Forms / Zones tabs.
• Home / End jump to the first or last tab.
• Esc cancels the picker.
• Enter confirms in dialogs and adds chips in the page-paths field.

If you rely on a screen reader, important state changes (saved, deactivated, errors) are announced via live regions.