Skip to main content
A screen resource defines one portal route. It can contain no root widget or one root widget node.

​
Author a screen

Create or edit a JSON file under portal/screens/. Keep its $schema URL and use the file name as the screen slug. Use the current schema for:
  • route metadata;
  • access and visibility settings;
  • the root widget node;
  • every nested widget property.
Do not copy a widget shape from an old portal. Built-in nodes and their properties can change with the Portal Definition schema.

​
Compose a widget tree

When a screen needs child placement, choose a registered container widget from the current schema or builder catalog. The container’s node definition tells you which property owns its children. Each node must use a built-in widget type or a published third-party widget type available to the portal. See PortalScreen, PortalWidgetNode, and PortalBuiltinWidgetNode for the exact properties.

​
Preview changes

Check each changed route at its screen slug. Verify empty content, narrow and wide layouts, interactive states, and the active theme modes.
Navigation controls discovery, not the only route resolution path. A valid screen can still be opened directly when its route and profile gates allow it.

​
Validate references

Preview can preserve an unresolved navigation entry without attaching a screen ID. Push rejects invalid references. Run fluid portal doctor, inspect every changed navigation target, and fix missing screen slugs before push.