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
- 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-navigationonly when a composite settings screen will replace the generated list destination. - 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.
- 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:
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
| Configuration | Implementation |
|---|---|
| Coded records, versions, effective dates | Ordinary App Resource |
| A few App-owned scalar values | Small singleton Resource with a Policy |
| Several related configuration Resources | One App screen; separate per-Resource API checks |
| Platform-wide configuration | Existing 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.