Application Settings

What It Is

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.

Why It Matters

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.

How These Settings Are Stored

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.

How To Read This Chapter

The Application settings screen is organized into these groups:

  1. Application
  2. Localization
  3. Views
  4. Identity management
  5. Security
  6. Logging
  7. 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:

What This Chapter Covers Versus Customization

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.

Application Group

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

iconsBootstrapIcons

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

iconsFontAwesome

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

Localization Group

locale

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

firstDay

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

businessDays

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 Monday
    • 2 Tuesday
    • 3 Wednesday
    • 4 Thursday
    • 5 Friday
    • 6 Saturday
    • 0 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

businessHoursStart

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

businessHoursEnd

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

decimalSeparator

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

defaultTimeZone

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

timeFormat

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 time
  • H: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

Views Group

viewDefaultPageLength

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

viewerListDefault

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:
    • table
    • table_sortable
    • list
    • kanban
    • calendar
    • cards
    • files-list
    • files-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

viewerSingleDefault

What it controls:

  • the default single-object viewer mode

How to configure it:

  • choose one of the form options:
    • form
    • post
    • public

What it affects:

  • fallback behavior when rendering a single object

Use it when:

  • the tenant should have a consistent default detail-view style

multipleItemsSeparator

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

formRenderMode

What it controls:

  • the default form layout mode used by platform forms when no more specific mode is chosen

How to configure it:

  • choose one of:
    • vertical
    • side-by-side

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

APIMultipleValuesReturnFormat

What it controls:

  • how API responses should return multiple values by default

How to configure it:

  • choose array or object

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

thumbnailSizeX

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

thumbnailSizeY

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:

  • thumbnailSizeX

checkboxDisplayEmptyAsFalse

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

Identity Management Group

allowedExternalIdentityProviders

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

allowApiPasswordReset

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

allowUserRegistrations

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

customRegistrationLinkText

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:
    • example.com
    • partner.org

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

allowedUserRoles

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

defaultUserRoles

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

allowedUserGroups

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

defaultUserGroup

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

Security Group

accessControlAllowOrigins

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.com
    • https://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

passwordRegex

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

passwordRegexExplanation

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

objectsRealDelete

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

filesRealDelete

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

defaultAccountExpirationTerm

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

Logging Group

logApiRequests

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

logAutomationErrors

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

logStructureQueries

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

Feature Keys Group

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_templates
  • featureKey__customization_scripts
  • featureKey__aiSidecar

What These Fields Control

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

Settings Relationships That Matter

Some settings make most sense in combination.

Registration Controls

Think of these together:

  • allowUserRegistrations
  • customRegistrationLink
  • customRegistrationLinkText
  • allowedUserDomains
  • allowedUserRoles
  • defaultUserRoles
  • allowedUserGroups
  • defaultUserGroup

This whole cluster defines how external onboarding should work.

Tenant Shell Defaults

Think of these together:

  • navigationPosition
  • locale
  • defaultTimeZone
  • viewerListDefault
  • formRenderMode

These together define what the tenant "feels like" before any individual module or view customization is applied.

Destructive Behavior Controls

Think of these together:

  • objectsRealDelete
  • filesRealDelete
  • logging settings

These determine whether the tenant behaves conservatively or destructively in operational cleanup scenarios.

What Is Not Configurable Here

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.

Design Questions To Ask Before Changing Application Settings

  • 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?

Best Practices

  • 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.
Previous← Application ManagementNextCustomization →