FAQ

This FAQ covers the core Design concepts, screen-building model, API wiring, and schema responsibilities across the platform

Frequently asked questions

What is the Design app responsible for?

Show answer

Design is where you build and evolve the admin UI.

It covers screen structure, interaction patterns, API wiring, and data shape so teams can change internal experiences quickly.

See Overview.

What are the main building blocks in Design?

Show answer

Think in three main groups:

• User Interface for apps, screens, widgets, menus, and visual behavior

• API Mapping for connecting screens to backend endpoints

• Data Schema for defining record structure, defaults, and validation rules

Supporting assets such as options, translations, icons, styles, and components help standardize the UI across apps.

See Overview.

What is the difference between an app and a UI?

Show answer

An app is a container for navigation and screens.

A UI is one specific screen inside that app.

Apps usually map to business areas or user roles. UIs map to specific tasks such as listing products, editing orders, or reviewing records.

See User Interface.

What is the difference between a lister and an editor?

Show answer

A lister helps users find and select records.

An editor helps users view or update a selected record.

Most business screens use both together.

See Listers and Widgets.

What role do widgets play?

Show answer

Widgets are the field-level building blocks of a UI.

They control how values are displayed, edited, validated, grouped, or embedded.

Different widget types exist for simple values, arrays, nested objects, indirect data, read-only display, and hosted custom components.

See Widgets.

When do I need a Source?

Show answer

You need a Source when a screen should talk to a non-default backend endpoint.

That usually means one of these:

• the UI should call a custom runner or saga

• the list view should use a dedicated query endpoint

• some operations should be overridden or disabled

If no matching Source exists, the UI falls back to the default admin CRUD behavior.

See API Mapping.

How does a UI connect to a Source?

Show answer

The usual convention is matching ids.

When a UI and a Source share the same id, the UI uses that Source for list, get, create, update, and delete behavior.

This keeps the UI definition separate from endpoint details while still linking them cleanly.

What is the role of a schema in Design?

Show answer

A schema defines the shape of the data behind the screen.

It drives structure, validation, labels, defaults, and consistency across editors and APIs.

Even when the underlying store is schema-flexible, defining schemas usually makes the system easier to maintain.

See Data Schema.

Does a UI automatically pick up a schema?

Show answer

Yes, in the common case.

If a schema has the same id as a UI, that schema is used automatically for labels and validation.

You can also point a UI to a different schema when reuse makes more sense.

What is the relationship between UI, Source, and Schema?

Show answer

They solve different concerns:

• UI defines how the screen behaves

• Source defines which backend endpoints the screen calls

• Schema defines the structure and validation of the data

That separation makes screens easier to reuse and change. You can update the API route or data model without redesigning the whole screen.

Do I need to define a Source and Schema for every UI?

Show answer

No.

A UI can work without a custom Source if the default CRUD behavior is enough.

A schema is also not always mandatory, but it is strongly recommended for clarity, validation, and long-term maintainability.

What are options, translations, icons, and styles for?

Show answer

They are shared UI assets.

• Options define reusable dropdown values

• Translations manage labels and language variants

• Icons define reusable visual symbols

• Styles control theme and appearance

These assets keep many screens consistent without copying the same setup repeatedly.

See User Interface.

What are components in Design?

Show answer

Components define the available editor and filter building blocks used by the platform.

Most teams do not change them often.

They matter more when extending the platform with new custom UI capabilities.

See Components.

Can I build an internal app without writing front-end code?

Show answer

Yes.

That is one of the main purposes of Design.

You can define apps, screens, forms, lists, widgets, and menus through configuration, then connect them to backend APIs.

Is Design meant for public customer-facing front-ends?

Show answer

Its main strength is internal admin and operational UI.

You can use the platform headlessly for external front-ends, but Design is optimized for back-office tools, admin flows, and internal business screens.

How does Design relate to Devops?

Show answer

Design builds the admin experience.

Devops provides the backend services and APIs that the screens call.

A common setup is: Devops exposes an endpoint, API Mapping connects a UI to it, and Schema keeps the record structure consistent.

See Overview and Devops FAQ.

When should I use special menu actions or extended scope features?

Show answer

Use them when a simple form screen is not enough.

Menu actions help trigger operations from listers, editors, selections, or widgets. Extended scope features help with conditional display, extra data, defaults, and context-aware behavior.

These features are useful when the UI needs workflow behavior, not just basic CRUD editing.

See Menus and Extended Scope.

What should I understand first if I am new to Design?

Show answer

Start with these concepts:

• App for navigation context

• UI for the actual screen

• Lister and editor for interaction pattern

• Widget for field behavior

• Source for backend wiring

• Schema for data structure and validation

Once these are clear, the rest of the Design section becomes much easier to follow.

Where should I go next for deeper Design FAQs?

Show answer

Start with the subsection that matches your goal:

• Need apps, screens, widgets, or menus → User Interface

• Need endpoint wiring or custom list actions → API Mapping

• Need validation or data structure rules → Data Schema

Subsection-specific FAQs can then go deeper into screen types, widget behavior, source actions, and schema patterns.