---
sourceDocument: Brazil Build or modify applications
sourceDocumentLink: https://www.servicenow.com/docs/r/application-development

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Inline configuration

# Inline configuration {#ariaid-title1}

Release version: Brazil  
Updated September 29, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read  
Inline configuration turns a property a developer declares in code into something a customer admin can change on a live page, without a code change or a redeploy. An author picks one of four modes per property, and the framework stores and reads back the resulting values.

The mechanics of declaring a property are in [Configurable properties for Lux experiences](https://www.servicenow.com/docs/Z8ch9vNd7cy1kj11~SRK2A "A property becomes configurable and visible in the props pane when you add a decorator to it. The decorator's options set the field type that the props pane renders, and also set the storage key that the resolved value is read back from."); what the admin sees is in admin-experience.html.

## Four configuration modes {#inline-configuration__inline-configuration-four-configuration-modes}

An author picks a mode per property, or per widget for self-config, in increasing order of effort. A single widget can mix modes: some properties on the standard popover, others deep-linked or self-configured.
{#inline-configuration__table-inline-configuration-four-configuration-modes__entry__5}

| Order | Mode | Declared with | What the admin gets | Where data saves |
|-|-|-|-|-|
| 1 | Independent config | `@config` on a field | The value field in the framework props pane, plus a lock toggle | `sys_aix_configuration` |
| 2 | External config | `@externalConfig` on the class | Same pane, plus a link out to a list, record, or URL | The author's own table |
| 3 | Custom URL | `static configMode = 'inline-simple'` | Pane stays; a button opens an author-supplied URL full-screen in an iframe | Wherever the linked tool saves; not through the framework |
| 4 | Self-config | `static configMode = 'inline-auto'` | Nothing framework-drawn; the widget renders its own editor | `sys_aix_configuration`, through the framework's save pipeline |
[ ]

{#inline-configuration__table-inline-configuration-four-configuration-modes}

Mode 1 applies to most properties. Only complex widgets (list, form, action bar, data visualization) need one of the others.

## External config with @externalConfig {#inline-configuration__inline-configuration-external-config-with-externalconfig}

A class-level decorator with no effect on resolution, storage, or the priority stack. It only injects a link into the config panel, so the admin has a quick path to related platform data: assignment group rules, SLA definitions, approval policies.

    @customElement('some-tag')
    @externalConfig({
      key: 'incidentData',
      list: {table: 'incident', fixedFilter: 'active=true'}
    })
    class SomeElement extends AIUXElement {}

Three variants: `list: {table, fixedFilter}`, `record: {table, sysId, view}`, or `link: {url}`.

## Custom URL with inline-simple {#inline-configuration__inline-configuration-custom-url-with-inline-simple}

For complex platform configuration where full self-config is not feasible. The widget's configuration lives in an external platform tool, opened in an iframe.

    @customElement('my-component')
    export class MyComponent extends AIUXElement {
      static configMode = 'inline-simple';

      provideConfigDeepLinking() {
        return {
          label: 'Configure Incident List',
          url: `${window.location.origin}/incident_list.do`
        };
      }
    }

Two requirements: the `configMode` static (a plain property, not a decorator) and an override of `provideConfigDeepLinking()`, which is a no-op on `AIUXElement` by default. Return a single `{label, url}`, an array of them for several buttons, or `null` for none. The editor renders one link-icon button per entry on the element's outline.  
Warning:  
Configuration set inside the opened URL is not returned to the widget. The framework does not receive or store values from the linked tool.

## Self-config with inline-auto {#inline-configuration__inline-configuration-self-config-with-inline-auto}

For widgets when a flat property form can't express the change: drag-and-drop layouts, a widget toolbox, a canvas, or curating an ordered collection. The framework delegates edit mode only; the UI, the affordances, and the
autosave behavior are the author's.

    class SnLayoutRenderer extends AIUXElement {
      static configMode = 'inline-auto';

      // The framework calls this when config mode opens.
      openConfigEditor({fieldValues, onChange, onSave, onClose}) {
        this._inlineConfig = {onChange, onSave, onClose};
        this._editMode = true;
      }

      closeConfigEditor() {
        this._editMode = false;
      }

      _persistChange(key, value) {
        this._inlineConfig?.onChange(key, structuredClone(value));
      }
    }

{#inline-configuration__table-inline-configuration-self-config-with-inline-auto-callbacks__entry__3}

| Callback | Direction | What it does |
|-|-|-|
| `fieldValues` | in | Current resolved value per `selfConfigSchema` key, admin and user layers applied |
| `onChange(key, value)` | out | Stage a pending edit. Safe to call repeatedly; pass a clone, not a live reference. |
| `onSave()` | out | Persist all staged edits and exit config mode |
| `onClose()` | out | Exit, discarding anything unsaved |
[ ]

{#inline-configuration__table-inline-configuration-self-config-with-inline-auto-callbacks}

On open, the editor scans the DOM to collect every configurable entry. Self-config widgets are handed their own editor instead of the standard per-property popover everyone else gets.

Self-config does not bypass the priority stack. The framework writes values to the admin layer through the same save path the props pane uses. The widget owns the editing UI, not the storage.

## Custom component in the props pane {#inline-configuration__inline-configuration-custom-component-in-the-props-pane}

Not a fifth mode. A bespoke component is injected into the standard props pane, keeping the familiar surface while still saving to `sys_aix_configuration`. Source marks this as available on request only. It also instructs authors to consult the configuration product and UX owners first, so the injected UI stays consistent with the rest of the configuration surface.

## How configuration is stored {#inline-configuration__inline-configuration-how-configuration-is-stored}

## sys_aix_configuration {#inline-configuration__inline-configuration-sys-aix-configuration}

Extends `sys_metadata`, indexed on `(page_path, tag)`, and backs every admin layer.
{#inline-configuration__table-inline-configuration-sys-aix-configuration__entry__2}

| Column | Notes |
|-|-|
| `page_path` | Required: matches the request's page path |
| `experience_path` | Required: matches the experience basename |
| `tag` | Required: the top-level element's custom-element name |
| `name` | Required: the full storage key |
| `value` | JSON, validated at write time |
| `condition` | Optional GlideScript, evaluated server-side |
| `order` | Evaluation order for conditional rows; default 100 |
| `personalization_disallowed` | Blocks the user preference from applying; default false |
| `sys_domain` / `sys_domain_path` | Standard domain separation |
[ ]

{#inline-configuration__table-inline-configuration-sys-aix-configuration}

The `name` column encodes the element's position in the component tree: `propKey` for a top-level property, `header.propKey` or `header.badge.propKey` for a nested
one. See [Configurable properties for Lux experiences](https://www.servicenow.com/docs/Z8ch9vNd7cy1kj11~SRK2A "A property becomes configurable and visible in the props pane when you add a decorator to it. The decorator's options set the field type that the props pane renders, and also set the storage key that the resolved value is read back from.") for how an id chain produces that key.

## sys_user_preference {#inline-configuration__inline-configuration-sys-user-preference}

No schema changes. User layers use dot-separated keys:

* Scoped: `aix.config.{pageId}.{tag}.{instanceId}.{name}`
* Global: `aix.config-global.{tag}.{name}`
**Related concepts**   

* [Configuration model](https://www.servicenow.com/docs/GMie8eKbnJlCpmbXGwkzcw "Lux makes a component's behavior configurable at three levels: code, admin policy, and individual preference without three separate systems to learn. You add one decorator, @config, to a class field to opt a property into all of it.")
* [Regions and the wrapper contract](https://www.servicenow.com/docs/U9LFJsY07dTSlK~_7lsmHg "A config admin can restructure a page's layout directly on the rendered page and persist the result as an admin override. Config admins can add and remove rows, columns, and widgets, resize column spans, change scrolling, and move containers.")  
**Related reference**   

* [Configurable properties for Lux experiences](https://www.servicenow.com/docs/Z8ch9vNd7cy1kj11~SRK2A "A property becomes configurable and visible in the props pane when you add a decorator to it. The decorator's options set the field type that the props pane renders, and also set the storage key that the resolved value is read back from.")  
**Related topics**   

* admin-experience.html