Saltar al contenido principal

Managing Views

Views control where your knowledge content appears. Each view maps to a page or section in your application. When a user visits a page, Appilot detects the current view and delivers the relevant knowledge entries, controls, forms, and tools.

Accessing Views​

Navigate to Apps → [Your App] → [Domain] → Views in the Backoffice.

Understanding the Views table​

ColumnDescription
NameThe view's display name
PathHierarchical path used for inheritance and linking
DetectionIcons for the configured detection rules (URL, DOM, page title, SDK) and the rule count
ContentNumber of knowledge entries linked to this view
Last detectedWhen the runtime last matched this view in the wild (useful to spot stale or broken detection rules)

Click a row to open the view editor.

Creating a view​

  1. Click New view on the Views page
  2. Fill in the required fields:
    • Name: a descriptive name (e.g. "User Registration")
    • Path: hierarchical path used for inheritance and for the runtime to address this view (e.g. zufi/online-services)
    • Description: free-text context the assistant reads to understand the view
  3. The view is created. Open it to configure detection rules and link knowledge entries.

Views are the only page detection and placement model. Link knowledge, controls, forms, and tools to view paths.

Detection rules​

Detection rules tell Appilot how to recognise when a user is on a specific view. A view can have multiple rules; the first match wins, so combine rules to provide fallback coverage.

Prefer URL when your app exposes one. Open the page you want to register in a normal browser tab and look at the URL. If it changes when you navigate between the views you want to distinguish, write a URL rule. DOM rules are reserved for views the URL cannot tell apart (sub-tabs, sidebars opened inside a page, single-URL apps like Vaadin Flow). Many "SPA" frameworks (Vue Router, React Router, Nextcloud's Vue 3 router) update the URL on every navigation, so "it's a SPA" is not a reason to skip URL detection.

URL detection​

Best for any application whose URL changes between views, which is the majority of modern web apps, including most SPAs.

Example: pattern **/apps/files/** detects the Nextcloud Files app across any subfolder or filter. Pattern /settings/profile detects the profile settings page.

DOM detection​

Best for views the URL cannot distinguish: a sidebar or sub-tab opened inside the same page, or a legacy single-URL SPA (Vaadin Flow, applet-style apps) where the framework never updates the URL.

Configuration:

  1. CSS selector: target element (e.g. h1.page-title, section[aria-label="Sharing"])
  2. Read mode: innerText reads visible text, textContent reads raw text including hidden nodes, getAttribute reads an element attribute (combine with the attribute name)
  3. Expected value: the text or attribute value that identifies this view

Tips:

  • Open the page in DevTools and confirm the URL doesn't already give you the answer before reaching for DOM
  • Use stable selectors (IDs, data attributes, ARIA labels) over CSS classes that may change
  • Test selectors in browser DevTools: document.querySelector('your-selector')
  • If you find yourself trying to assert "this element just exists" by checking its id, switch to URL detection. That's a sign you reached for DOM when URL would have worked.

Page title detection​

Useful when the document title is the most stable signal (some legacy admin tools).

SDK detection​

Best when you control the application code and can report context directly.

Your application calls the Appilot SDK to report the current view path. See Views & Detection Rules for technical details.

Linking knowledge to views​

Each view can have multiple knowledge entries linked to it:

  1. Open a view from the Views table
  2. Scroll to the Linked content section
  3. Click Add content to link existing knowledge entries, or create new ones from the Knowledge page using this view as a prefilled target

Knowledge entries inherit through the path hierarchy: content linked to zufi/ appears on all child views like zufi/online-services.

Content scoping​

Knowledge entries have a scope that determines when they appear. Only these three scopes are valid:

ScopeAppears on
Domain GlobalAll pages on the domain
App GlobalAll domains in the application
PageOnly the views explicitly linked from the entry's Views tab

Use the Views tab on a page-scoped entry to link it to the views where it should appear.

Knowledge entry statuses​

StatusMeaning
DraftBeing written, not visible to end users
In ReviewReady for review, not yet published
PublishedLive, visible to end users through the assistant

Only Published entries are delivered to users by the AI assistant.

How views relate to controls, forms, and tools​

Views are the common addressing layer for every other content primitive:

  • Controls with scope=view carry a view_path. They are listed under the matching view card in the Controls page.
  • Forms declare one or more view_paths; the assistant emits transitions between them in fill order.
  • Tools with a view_id are only offered when that view is active.

This is why the Backoffice groups Controls and Tools by view: it mirrors the model the runtime uses to decide what is reachable.

Best practices​

  1. Start broad, then refine: Create domain-wide content first, then add view-specific details.
  2. Use meaningful paths: Paths like zufi/online-services/new are clearer than page1/sub2.
  3. Monitor detection health: Use the Last detected column to spot rules that no longer match (a long gap is a red flag).
  4. Test detection rules: Use the extension on the target page to verify detection works before publishing dependent content.
  5. One topic per entry: One knowledge entry per topic is easier to maintain than one large entry covering everything.