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

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Inline configuration

# Inline configuration {#ariaid-title1}

Release version: Australia  
Updated September 29, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Inline configuration

Inline configuration in ServiceNow Australia release enables developer-declared properties in code to be configurable by customer admins directly on live pages, without requiring code changes or redeployment.
This capability allows admins to modify widget properties dynamically through the user interface, improving flexibility and reducing dependency on development cycles.
Show full answer Show less  
Authors select one of four configuration modes per property or widget, which determines how and where the configuration data is stored and edited. Widgets can mix modes depending on property complexity.

## Four Configuration Modes

* **Independent config (@config):** The simplest mode where properties appear as editable fields with lock toggles in the framework's properties pane and save changes to the `sysaixconfiguration` table.
* **External config (@externalConfig):** Adds a link in the config panel to a related data list, record, or URL outside the framework, enabling quick access to related platform data. Storage remains in the author's own tables.
* **Custom URL static config (inline-simple):** For complex configurations where full self-config is not feasible. A button opens an external configuration tool in a full-screen iframe. Configuration changes made in this tool are not returned to or stored by the framework.
* **Self-config (inline-auto):** Used when simple property forms are insufficient, such as drag-and-drop layouts or ordered collections. The widget provides its own editor UI and manages autosave behavior, while the framework handles storage through `sysaixconfiguration`. The widget receives callbacks to manage staged edits and persistence.

## Key Details for External and Custom Modes

* **@externalConfig decorator:** Injects quick links into the config panel for related platform data (e.g., assignment groups, SLAs) without affecting storage or resolution priority.
* **inline-simple mode:** Requires a static `configMode` property and implementation of `provideConfigDeepLinking()` to supply configuration URLs. Multiple links can be provided, and the framework renders them as buttons in the widget outline.
* **inline-auto mode:** The widget implements `openConfigEditor`, `closeConfigEditor`, and change persistence methods to fully control the editing experience. This mode supports complex, custom UI editing beyond simple forms.

## Storage and Data Model

Configuration data is primarily stored in the `sysaixconfiguration` table, which extends `sysmetadata` and indexes by page path, experience, and widget tag. The table supports domain separation and conditional configurations. User preferences for configuration use dot-separated keys scoped globally or per user.

The `name` column encodes the property's hierarchical position in the component tree, enabling precise targeting of nested properties.

## Additional Notes

* Custom components can be embedded into the standard properties pane as a bespoke UI for configuration, available on request to maintain consistency across the configuration surface.
* Self-configured widgets still honor the framework's priority stack for configuration resolution and use the framework's save pipeline.
* Authors should consult configuration product and UX owners before injecting custom UI components.  
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/LeINpZ6MlSXTUmYqb18kwA "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 .

## 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/LeINpZ6MlSXTUmYqb18kwA "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/bnom6UK7iss17PaJTXfHeA "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/MzACNDP~yg7lFFDOtCgm1g "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/LeINpZ6MlSXTUmYqb18kwA "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**   

*