Application settings are the tenant-wide operational defaults managed from the Application settings screen. They define how the tenant behaves in broad areas such as:
- shell and navigation behavior
- localization defaults
- views and forms defaults
- onboarding and identity-management rules
- security and deletion behavior
- logging
- feature flags and feature keys
These settings are different from per-resource configuration such as Views, Modules, or Queries. They are also different from Customization, which focuses more on branding, theme, assets, mail transport, SMS, and environment variables.
These settings shape the environment in which the whole tenant runs.
Even when no type, query, or view changes, application settings can still change:
- how navigation is laid out
- what users see as default viewers
- how dates and times feel across the UI
- how registration and onboarding work
- how APIs behave
- whether deletion is soft or real
Poor defaults here create friction everywhere. Good defaults quietly improve the whole tenant.
These settings are stored as tenant configuration values and written through Config::set(...), not through the environment-variable store used by customization variables.
That means:
- this screen manages tenant configuration keys
- the settings act as reserved configuration keys with known defaults
- many parts of the platform read them directly as runtime defaults
This is useful to understand because it explains why these settings feel "built into" the tenant rather than like arbitrary dynamic variables.
The Application settings screen is organized into these groups:
- Application
- Localization
- Views
- Identity management
- Security
- Logging
- Feature keys
This chapter follows the same structure and explains each option in terms of:
- what it controls
- how to configure it
- what effect it has at runtime
- when to use it
Use this chapter together with:
This screen covers behavioral and operational defaults.
Typical examples:
- default locale
- default viewers
- registration policy
- password rules
- logging switches
Customization covers different concerns, such as:
- app title
- logos
- icon asset files
- colors and theme
- mail transport settings
- SMS settings
- environment variables
This distinction matters because implementers often expect branding settings here, but those live elsewhere.
What it controls:
- whether the main tenant navigation is shown on the
top or on the left
How to configure it:
- choose
top for a top navigation layout
- choose
left for a sidebar-oriented layout
What it affects:
- the main application shell
- the navigation wrapper used in the standard layout
- how users orient themselves inside the tenant
Use left when:
- the tenant has many modules
- navigation should stay persistent and space-efficient
Use top when:
- the tenant has a smaller navigation surface
- the design should feel more website-like or dashboard-like
What it controls:
- whether Bootstrap Icons are loaded into the tenant frontend
How to configure it:
- enable it if the tenant uses Bootstrap Icons in modules, views, canvases, buttons, or templates
- disable it if the icon library is not needed
What it affects:
- the
<head> asset loading for Bootstrap Icons
Use it when:
- builder-configured icons or templates rely on Bootstrap icon classes such as
bi bi-table
What it controls:
- whether Font Awesome assets are loaded into the tenant frontend
How to configure it:
- enable it when templates or UI customizations rely on Font Awesome classes
- disable it if the tenant standardizes on Bootstrap Icons only
What it affects:
- the
<head> asset loading for Font Awesome styles
Practical guidance:
- avoid loading unnecessary icon libraries if the tenant already has a clear icon standard
What it controls:
- whether the tenant should use the automatically derived tenant namespace ID
How to configure it:
- leave it enabled to use the default generated namespace
- disable it if you need to provide a custom namespace through
tenantNamespace
Why it matters:
- some integrations and namespacing logic depend on a stable tenant namespace identifier
Use the default when:
- there is no integration or isolation reason to override it
Use a custom namespace when:
- external integrations, migration strategy, or tenant identity rules require a specific namespace ID
What it controls:
- the explicit tenant namespace ID when
tenantNamespaceUseDefault is disabled
How to configure it:
- first disable
tenantNamespaceUseDefault
- then enter the exact namespace ID that should be used
What it affects:
- runtime tenant namespace resolution
Important relationship:
- this field only matters when the default namespace toggle is turned off
Use it carefully:
- changing it after integrations depend on the existing namespace can have non-obvious consequences
What it controls:
- the tenant's default language/locale
How to configure it:
- choose one of the supported locales currently exposed by the settings form, such as
en or cs
What it affects:
- the UI language baseline
- translator output
- date/time localization defaults in several places
- template language in the standard HTML shell
Use it when:
- the tenant should have one primary operating language
Important note:
- user preferences may still override some locale behavior at runtime, but this setting remains the tenant default
What it controls:
- the first day of week used by calendar-oriented UI
How to configure it:
- choose
0 for Sunday
- choose
1 for Monday
What it affects:
- calendar view layout and expectation
Use it when:
- the tenant should match local business conventions
What it controls:
- the days treated as business days in business-time-aware UI
How to configure it:
- select one or more weekday codes from the multi-select
- the field is taggable, but in normal use you should stick to weekday values:
1 Monday2 Tuesday3 Wednesday4 Thursday5 Friday6 Saturday0 Sunday
What it affects:
- calendar business-hours display
- work-week-like expectations in the UI
Use it when:
- the tenant has non-standard work weeks
- the organization operates on region-specific business-day conventions
What it controls:
- the default business opening time
How to configure it:
- enter a time string such as
8:00 or 09:00
What it affects:
- calendar business-hour display range
Use it when:
- working hours should be visually emphasized in scheduling views
What it controls:
- the default business closing time
How to configure it:
- enter a time string such as
18:00 or 17:30
What it affects:
- calendar business-hour display range end
Use it when:
- schedule planning should align with typical operating hours
What it controls:
- the default decimal separator for numeric formatting conventions
How to configure it:
- enter the desired separator, typically
, or .
What it affects:
- number presentation expectations in user-facing contexts
Use it when:
- the tenant should match regional numeric conventions
What it controls:
- the tenant's default time zone
How to configure it:
- choose one IANA time zone identifier such as
Europe/Prague, UTC, or America/New_York
What it affects:
- runtime default timezone setup
- date/time interpretation across many screens and processes
Use it when:
- the tenant should operate from one primary business timezone
Be careful:
- changing this after a tenant is heavily used can alter how times are perceived across the system
What it controls:
- the preferred default time display format
How to configure it:
- choose the 12-hour or 24-hour format offered by the form
Current options:
g:i a for 12-hour timeH:i for 24-hour time
What it affects:
- human-readable datetime rendering that falls back to tenant defaults
Use it when:
- the tenant should match local time-reading habits
What it controls:
- the default number of items shown per page in list-oriented data views
How to configure it:
- enter a positive integer such as
20, 50, or 100
What it affects:
- default pagination in views and APIs that use tenant defaults for page length
Use it when:
- the tenant should favor denser operational lists or lighter default pages
Practical guidance:
- smaller values reduce initial page load complexity
- larger values reduce pagination frequency for power users
What it controls:
- the default list viewer used when no more specific list viewer is chosen
How to configure it:
- choose from the supported list viewer options shown in the form, such as:
tabletable_sortablelistkanbancalendarcardsfiles-listfiles-thumbnails
What it affects:
- default list rendering fallback in the view system
Use it when:
- the tenant has one dominant list interaction style
Be careful:
- this is a tenant-wide default, not a replacement for configuring individual views intentionally
What it controls:
- the default single-object viewer mode
How to configure it:
- choose one of the form options:
What it affects:
- fallback behavior when rendering a single object
Use it when:
- the tenant should have a consistent default detail-view style
What it controls:
- the fallback separator used when multiple values are rendered together
How to configure it:
- choose one of the provided separator styles:
- new line (
<br>)
- comma
- pipe
What it affects:
- rendering of multi-value outputs in property displays and similar contexts
Use it when:
- the tenant should consistently render multiple values with one preferred visual convention
What it controls:
- the default form layout mode used by platform forms when no more specific mode is chosen
How to configure it:
What it affects:
- how many forms are laid out by default
Use vertical when:
- forms should feel simpler and narrower
Use side-by-side when:
- denser enterprise-style forms are preferred
What it controls:
- how API responses should return multiple values by default
How to configure it:
What it affects:
- API response shape for multi-value data
Why it matters:
- this is an integration contract setting
- changing it after integrations are live can break assumptions in external consumers
Use it carefully:
- prefer stability once external systems depend on the API
What it controls:
- the horizontal size used for generated thumbnails
How to configure it:
- enter an integer pixel value
What it affects:
- image thumbnail generation behavior for file/image properties
Use it when:
- the tenant needs more compact or larger thumbnail previews
What it controls:
- the vertical size used for generated thumbnails
How to configure it:
- enter an integer pixel value
What it affects:
- image thumbnail generation behavior for file/image properties
Use it together with:
What it controls:
- whether an empty checkbox-like value should be interpreted as
false
How to configure it:
- enable it if missing checkbox values should be treated as negative values
- disable it if empty and false should stay distinct
What it affects:
- checkbox-related property handling and output interpretation
Use it when:
- integrations or form behavior expect empty checkbox submissions to behave like explicit
false
What it controls:
- which external identity providers are allowed for sign-in or onboarding flows
How to configure it:
- select one or more providers from the multi-select
What it affects:
- login and identity flows that expose external providers
Use it when:
- the tenant wants to allow only approved external identity providers
What it controls:
- whether password reset is allowed through the API-oriented password reset flow
How to configure it:
- enable or disable the checkbox
What it affects:
- API password reset capability exposed by the user module
Use it when:
- password reset should be available through API-supported flows
What it controls:
- whether external user self-registration is allowed
How to configure it:
- enable it to allow user-driven registration
- disable it to prevent public/self-service registration
What it affects:
- registration routes
- identity onboarding behavior
Important relationship:
- if this is disabled, the standard registration flow is blocked even if a custom registration link is configured elsewhere
What it controls:
- a custom URL used as the registration link target
How to configure it:
- enter an external or alternate URL if registration should lead somewhere other than the standard tenant registration route
What it affects:
- login-page registration link behavior
Use it when:
- registration is handled outside the standard tenant registration screen
- onboarding should redirect to an external signup portal or another entry flow
What it controls:
- the label shown for the custom registration link
How to configure it:
- enter the exact text users should see next to the login form
Use it when:
- the default "register" wording is not specific enough for the onboarding flow
¶ allowedUserDomains
What it controls:
- which email domains are allowed during user self-registration
How to configure it:
- enter one or more domains in the taggable multi-select, such as:
What it affects:
- registration validation
- API and onboarding checks for allowed domains
Important behavior:
- an empty list means no domain restriction
- once values are added, only those domains are accepted
What it controls:
- which roles a registering or requested user may choose or receive in registration-related flows
How to configure it:
- select one or more roles from the existing role list
What it affects:
- registration and user-creation constraints
Use it when:
- onboarding should be limited to a defined set of roles
What it controls:
- which roles should be assigned by default during self-registration or external identity onboarding
How to configure it:
- select one or more roles from the role list
What it affects:
- automatic role assignment during registration/onboarding flows
Best practice:
- keep these aligned with
allowedUserRoles
- use only the minimum roles necessary for a newly onboarded user
What it controls:
- which groups are allowed in onboarding or requested group assignment flows
How to configure it:
- select one or more groups from the group list
What it affects:
- group assignment constraints during registration and related flows
What it controls:
- the default group assigned to a newly registered or externally onboarded user
How to configure it:
- choose one group from the select field or leave it empty
What it affects:
- onboarding defaults for user grouping
Best practice:
- keep this aligned with
allowedUserGroups
What it controls:
- which origins are allowed for CORS-style access to API endpoints
How to configure it:
- add one or more origins to the taggable multi-select, for example:
https://app.example.comhttps://admin.example.com
What it affects:
- API presenters and webhook-like endpoints that consult allowed origins
Important behavior:
- an empty list means no extra origins are explicitly allowed by this setting
Use it when:
- browser-based integrations need cross-origin access
Be careful:
- this is a security boundary
- allow only origins you trust
What it controls:
- the regex pattern used to validate passwords against tenant rules
How to configure it:
- enter a valid regular-expression body describing the required password shape
Default intent:
- at least one number
- at least one lowercase letter
- at least one uppercase letter
- minimum length requirement
What it affects:
- password validation in reset and onboarding flows
- password-type property validation behavior where tenant rules apply
Use it when:
- the tenant needs stricter or differently explained password requirements
Be careful:
- invalid or overly strict regex rules can make onboarding or resets fail in confusing ways
What it controls:
- the user-facing explanation of the password rule
How to configure it:
- enter a clear human-readable explanation that matches
passwordRegex
Why it matters:
- the regex is for validation
- this field is what users actually read
Best practice:
- always update this together with
passwordRegex
What it controls:
- whether objects should be truly deleted rather than handled through softer deletion behavior
How to configure it:
- enable it for true destructive deletes
- disable it if the tenant should preserve deleted records through soft-delete-like behavior
What it affects:
- delete behavior in resource and object managers
Use it carefully:
- true deletion is operationally risky
- enable it only when retention and recovery expectations allow it
What it controls:
- whether files should be truly deleted from storage rather than only logically removed
How to configure it:
- enable it for physical file deletion
- disable it if file recovery or softer lifecycle handling is needed
What it affects:
- file and image deletion behavior
Use it carefully:
- like object real delete, this has data-retention consequences
What it controls:
- the default relative term used when calculating account expiration during onboarding-related flows
How to configure it:
- enter a relative time expression such as:
+5 minutes+7 days+30 days
What it affects:
- account expiration defaults during some user onboarding or identity flows
Use it when:
- temporary accounts or timed activation windows should have a default expiry rule
What it controls:
- whether API requests should be logged
How to configure it:
- enable it when API observability is needed
- disable it to reduce log volume
Use it when:
- integrations need troubleshooting support
- auditability of API activity matters
What it controls:
- whether automation errors should be logged centrally
How to configure it:
- enable it for stronger operational observability
- disable it if the tenant intentionally keeps automation logging minimal
What it affects:
- automation error logging behavior in the automation runtime
Use it when:
- automations are business-critical and failures need to be discoverable
What it controls:
- whether structure-related queries should be logged
How to configure it:
- enable it when low-level structure/query troubleshooting is needed
What it affects:
- certain lower-level structure-query diagnostics in resource handling
Use it when:
- investigating data-model or query-generation issues
Be careful:
- this is mainly a diagnostic switch, not a normal business setting
The Application settings screen also exposes one text field per feature key defined by the platform.
In the current codebase, these feature keys are:
featureKey__customization_templatesfeatureKey__customization_scriptsfeatureKey__aiSidecar
They store inserted feature keys used to unlock gated capabilities.
How to configure them:
- enter the provided feature key value into the corresponding field
What they affect:
- access to customization templates
- access to customization scripts
- use of the AI sidecar feature
Important note:
- these fields are not ordinary convenience settings
- they participate in feature unlocking logic
Use them when:
- the tenant has been issued a valid feature key for the corresponding capability
Some settings make most sense in combination.
Think of these together:
allowUserRegistrationscustomRegistrationLinkcustomRegistrationLinkTextallowedUserDomainsallowedUserRolesdefaultUserRolesallowedUserGroupsdefaultUserGroup
This whole cluster defines how external onboarding should work.
Think of these together:
navigationPositionlocaledefaultTimeZoneviewerListDefaultformRenderMode
These together define what the tenant "feels like" before any individual module or view customization is applied.
Think of these together:
objectsRealDeletefilesRealDelete- logging settings
These determine whether the tenant behaves conservatively or destructively in operational cleanup scenarios.
Some related values exist as tenant defaults but are not edited on this screen.
Examples include:
viewPageLengths- branding assets such as title and logos
- mail transport settings
- SMS gateway settings
- theme and color tokens
Those belong to config defaults or to Customization, not to the Application settings form itself.
- Is this a tenant-wide policy, or should it really be configured per view, module, or flow?
- Will changing this affect live integrations?
- Does this setting define a safe default, or a hard business restriction?
- If registration or identity settings change, do the chosen defaults still match the onboarding policy?
- If delete behavior changes, is the tenant ready for the retention consequences?
- Set localization and timezone defaults early in the tenant lifecycle.
- Keep API response-shape settings stable once integrations exist.
- Align onboarding settings as a coherent policy, not one field at a time.
- Treat
objectsRealDelete and filesRealDelete as deliberate governance decisions.
- Update
passwordRegex and passwordRegexExplanation together.
- Use logging switches intentionally, and turn on deep diagnostics only when operationally useful.