Domain Configuration

Domains define where Appilot is active. The assistant only provides knowledge-grounded answers on domains your organization has registered and configured.

Registering a domain

Domains live under the application they belong to, so registration starts there.

1. Go to Apps in the Backoffice and open the application
2. On the Domains tab, click New Domain
3. Enter the hostname (app.example.com), without the protocol or a path
4. Save, then publish the DNS TXT record the verification dialog shows and click Verify Now

Verification proves you control the hostname. Until it succeeds the domain is registered but not verified, which blocks a live widget key and the site adapter, and blocks nothing else: the extension and the keyless widget path serve an unverified domain. That matters for a hosted application whose DNS you do not control. See Verify your domain for the record, the check, and the case where you cannot publish one.

URL patterns

URL patterns control how knowledge is matched to pages:

Pattern	Matches
/register	Exactly app.example.com/register
/settings/*	Any page under /settings/
/forms/claim-*	Pages like /forms/claim-auto, /forms/claim-health
*	Any page on the domain

Finding the domains worth registering

Appilot does not tell you which sites your people use. It never sees them. Domain harvesting, which listed unregistered domains ranked by visit frequency, was removed in September 2026 along with the browsing collection that fed it. See Domain harvesting (removed).

Two things take its place, and both start with a person deciding.

• Coverage requests. A user on a site Appilot does not cover yet presses the button that asks for it. Those requests land with the Appilot operator in Platform Admin rather than in your Backoffice, so ask us for the list for your organization until a Backoffice view exists.
• Register the domain yourself. Pick the applications you want the assistant in and add them here. During a rollout that is usually a short list you already know.

Managing domains

Opening a domain from the application's Domains tab gives you its knowledge, controls, forms, tools, views, zones, action plans, translations, activity and the site adapter.

Its own settings live under Settings in the domain menu, where you can:

• Rename it, which changes only the label shown in the Backoffice
• Move it to another application in your organization
• Make it an alias of another domain in the same application
• Delete it

The hostname itself cannot be changed. Knowledge, views and conversations are recorded against it, so renaming it in place would detach all of them; register the correct hostname and delete the wrong one instead.

Deleting a domain

Deletion removes the domain together with everything configured on it: its views, zones, forms and editor grants, and the knowledge, requests and recorded pages filed under its hostname. The Settings page counts all of it before you confirm, and asks you to type the hostname back.

A domain that other domains alias cannot be deleted. Change or delete those aliases first, otherwise they would be left pointing at nothing.

Applications

Domains are grouped into Applications. An Application is the logical unit for one web application, and it is also what decides which organization owns a domain: a domain reads its tenant from its application, so every domain belongs to exactly one.

• An application might have several domains (app.example.com and api.example.com)
• Knowledge and files can be associated at the application level
• Analytics can be viewed per application

An application's name, description and default knowledge visibility are on its Settings tab. Deleting an application from there removes every domain under it and everything those domains carry, so it asks for the application name typed back.

Site Adapter Configuration

For applications that use non-standard web frameworks (like Vaadin, which uses Shadow DOM and doesn't change URLs during navigation), you can configure a Site Adapter per domain.

What Site Adapters Do

A Site Adapter is a JSON configuration that tells the Appilot extension how to behave on a specific domain:

• Shadow DOM Depth: How deep to traverse Shadow DOM trees (default: 3, increase for frameworks like Vaadin)
• Page Detection: Rules to identify which page/module the user is on, using DOM selectors instead of URLs
• Interaction Overrides: Custom strategies for interacting with framework-specific components (e.g., Vaadin combo boxes)
• Knowledge Hints: Whether to match knowledge by module/page keys instead of URL patterns

Configuring an Adapter

1. Navigate to Apps → select your application → open the domain
2. Choose Site Adapter in the domain menu
3. Edit the JSON configuration
4. Save

Example: Vaadin Application

{
  "schema_version": "1.0",
  "domain": "your-app.example.com",
  "framework_hints": ["vaadin"],
  "runtime": {
    "shadow_dom_max_depth": 6,
    "action_timeout_ms": 3000,
    "mutation_observer_debounce_ms": 500
  },
  "page_detection": {
    "strategy": "dom_selector",
    "rules": [
      {
        "selector": "vaadin-menu-bar [selected]",
        "read": "innerText",
        "map": {
          "Online Services": { "view_path": "app/online-services" },
          "Organizations": { "view_path": "app/org-units" }
        }
      }
    ]
  },
  "interaction_overrides": {
    "vaadin-combo-box": {
      "strategy": "open_then_select",
      "open_trigger": "click",
      "option_container_selector": "vaadin-combo-box-overlay [part='item']"
    }
  },
  "knowledge_hints": {
    "always_include_scopes": ["domain_global"]
  }
}

tip

For standard web applications where URL changes reflect navigation, you don't need a Site Adapter. The default behavior works well for most SPAs and traditional websites.