Skip to content
Guide

Add a settings page

Model App configuration as a Resource, publish its surface, and place it in the settings group with correct enforcement.

Give operators one place to edit App configuration. Use an App-owned Resource for configuration records or a singleton, then place its screen in the App Menu's settings group.

Build the configuration screen

  1. Follow Create a Resource for the configuration's data and protected API. Choose tenant or organization ownership from the business rule; the People certificate policy below is Legal Entity scoped. Use --without-navigation only when a composite settings screen will replace the generated list destination.
  2. Use the generated screen directly, or combine several Resources with Build an App screen. Register the component and its manifest route. Each API checks its own Resource permission and record scope, including writes; a shared page permission cannot replace them.
  3. Publish the destination with Add a menu destination, using groupId: 'settings'.

This exact destination in packages/people/src/Contribution/PeopleCertificateSettings.php points to the existing certificate screen:

Code example
PHP
NavigationItem::make(
    id: 'people-certificate-settings',
    route: '/apps/people/settings/certificates',
    icon: 'file-badge',
    sort: 180,
    labelKey: 'people.certificate.settings.title',
    appKey: 'people',
    contextId: 'app',
    groupId: 'settings',
    permission: 'people.certificate_policy.read',
),

The enclosing class implements Nexia\Navigation\Contracts\NavigationContribution and returns this item from navigationItems(). It separately declares people.certificate_policy.update as a protected Legal Entity permission. Keep read and update distinct when adapting this pattern.

Confirm the result

Refresh contribution discovery after adding a class. In an operational tenant, an actor with read access sees Settings and can load the configuration. An actor lacking update may view it but receives a refusal when sending a write directly. A user without read access must not receive the configuration through the API. Test those cases using Test an App.

Choosing the configuration owner

ConfigurationImplementation
Coded records, versions, effective datesOrdinary App Resource
A few App-owned scalar valuesSmall singleton Resource with a Policy
Several related configuration ResourcesOne App screen; separate per-Resource API checks
Platform-wide configurationExisting platform capability; no App import of the host's Site Configuration registry

App settings belong inside the App Menu. The host Settings Menu and Site Configuration are platform-owned. The SDK component boundary remains the same as for other App screens; there is no separate settings storage API.

Source of truth: docs/developers/content/en/platform-extensions/add-settings.md