Application Management
What It Is
Application management is the operational side of the tenant settings screen. Where Application Settings expose the behavioral defaults of the tenant (locale, forms, identity rules, logging), Application management exposes the actions an operator can take against the running tenant:
- rebuild and export data
- import database backups
- regenerate operational artifacts
- purge caches
- rotate the tenant's cryptographic key
- wipe data while keeping the model
- reset the tenant entirely
These actions live on the tenant admin screen under the "Management" block, alongside tenant information (domain, namespace, size).
Why It Matters
Settings describe how the tenant behaves. Management describes what an operator can do to the tenant. These two perspectives have different risk profiles:
- editing a setting is almost always reversible
- pressing a management button can have large and sometimes irreversible effects
Treating the management area with care protects tenant data, cryptographic continuity, and integrations that depend on the tenant's stable behavior.
How The Screen Is Organized
The management block groups actions by intent:
- Operational maintenance — safe actions the operator can run on demand.
- Cryptographic rotation — one-off actions that invalidate existing tokens or links.
- Destructive actions — data removal or full tenant reset. Always behind a confirmation collapse.
The same visual language is used for similar risk levels:
- neutral primary buttons for routine maintenance
- warning styling for cryptographic rotation
- danger styling for destructive actions
- collapse + explicit "confirm" button for anything that cannot be undone
Operational Maintenance
Search Index Scan
Rebuilds the tenant search index.
When to use: after large data imports, after migrating a tenant, or when search results look stale.
Impact: may take a while on large tenants but is safe to run any time.
Export Database
Produces a gzipped SQL export of the tenant database and stores it inside the tenant directory on the server.
When to use: before a risky change, before a version upgrade, as part of routine snapshots.
Impact: read-only. The export is stored in the tenant filesystem, so it respects the tenant's storage quota.
Import Database
Uploads a previously exported, gzipped SQL file and restores it into the tenant database.
When to use: restoring from a backup, seeding a fresh tenant from a template, rolling back a change.
Impact: replaces current tenant data. Treat this as a destructive action even though it lives next to neutral maintenance buttons.
AI Agents
Opens the AI agents overview. This is a navigation shortcut, not an operation.
When to use: when configuring or reviewing AI-assisted functionality at the tenant level.
Cache Purges
The platform keeps several operational caches. The management area exposes the ability to purge them selectively:
- templates cache — purge after template asset changes
- database cache — purge after low-level schema changes
- tenant runtime cache — purge tenant-specific Redis and file caches
When to use: after a customization deployment that did not fully reflect, or during operator troubleshooting.
Impact: caches rebuild automatically on subsequent requests. These actions are safe but may briefly increase response time until caches refill.
API Response Cache
The platform caches GET and SEARCH responses for the REST API on disk. Read-heavy integrations that repeatedly request the same data are served the cached payload without touching the database. The cache is per-user and tenant-scoped.
The Application Management screen has a dedicated API response cache panel that surfaces:
- Cache size — number of stored responses and total disk footprint
- Oldest entry — timestamp of the earliest still-cached response, useful for sanity-checking that purges and TTL are working
- TTLs — time-to-live applied to list responses and to single-resource responses
Two purge actions are available:
Purge entire API cache. Drops every cached API response for the tenant. Use after a large structural change that could affect many endpoints at once — for example a new role assignment that should be reflected immediately, or a bulk import that bypassed the normal write path.
Purge cache for a specific type. Drops every cached response (lists and single-resource entries) for one selected type. Use when only one type was affected by an out-of-band change. This is the everyday operator tool for forcing a refresh without flushing the whole tenant.
When to use:
- after a bulk import or migration that wrote rows directly without going through the normal resource manager
- after a role or permission change that should be reflected in cached views immediately
- when investigating reports of stale data
Impact: safe. Subsequent requests rebuild cache entries on demand. There is a brief window where API response times will be back to uncached levels until the cache warms up again.
Behavior: purges are immediate. List entries also expire on their own within the configured TTL (5 minutes by default), so for routine writes through the platform you do not need to purge manually — the cache invalidates itself.
Single-resource cache entries are flushed automatically when the resource is created, updated, or deleted through the platform, so manual purges are rarely needed for normal day-to-day editing.
Cryptographic Rotation
Tenant Security Key
The tenant has a private security key used to sign and encrypt data the platform issues to the outside world: secure links, short-lived tokens, and similar credentials. This key is stored in the tenant configuration and is generated lazily the first time a feature needs it.
When to use:
- you suspect the key leaked
- you are rotating keys on a scheduled cadence
- the tenant is being handed over between teams or environments
Impact:
- links and tokens already in circulation stop working (for example, password-reset links in unopened e-mails, pending workflow links, encrypted callback URLs)
- affected users or processes will need to restart the flow
- already active logins are not affected — they use the session layer, not this key
Behavior: the action is ajax-driven. After rotation, a success flash message is shown and the management panel refreshes in place, without a full page reload.
Destructive Actions
Remove Data, Keep Model
Deletes all data for types in the entity role while preserving the model itself, as well as enumerations, checklists, and system objects.
When to use:
- preparing a tenant for go-live after a testing phase
- promoting an implementation from a sandbox environment with test data
Impact:
- entity rows are wiped from storage
- the data model, users, groups, and configuration remain intact
Confirmation flow: the primary button expands a warning panel, and a second explicit button performs the operation.
Application Reset
Full clean-install wipe. Removes object-model definitions, data-protection configuration, application configuration, users, form groups, and page layouts.
When to use:
- starting over from scratch inside an existing tenant
- resetting a sandbox tenant between iterations
Impact: effectively re-initializes the tenant. There is no in-place recovery — restore from an export if needed.
Confirmation flow: identical pattern to "Remove Data" — expand-and-confirm.
How These Actions Relate To Other Surfaces
Some management actions overlap with capabilities exposed elsewhere. Knowing which surface to use matters:
| Need | Preferred surface |
|---|---|
| Export/import as part of release workflow | Application management |
| Export for implementation sync between tenants | Tenant Synchronization |
| Purge cache after template/script edit | Application management |
| Force a refresh of cached REST API responses | Application management (API response cache) |
| Rotate the tenant security key | Application management |
| Rotate an integration credential | Secret Store |
| Wipe entity data | Application management (Remove Data) |
| Remove specific objects | ordinary object actions in views |
Programmatic Access
Some management actions are also available programmatically:
SystemManager::regenerateAppSecret()via the InternalAPI$api->system->regenerateAppSecret()— rotates the tenant security key from automations or scripts.
Use the programmatic entry point sparingly: rotations are visible, tenant-wide events and are usually better handled from the admin screen where an operator can read the warning in context.
Design Questions To Ask Before Pressing A Management Button
- Is this action reversible? If not, do I have a current export?
- Will this invalidate anything currently in transit (e-mail links, pending callbacks, signed URLs)?
- Are any integrations holding tokens or links that might break?
- Am I doing this on the right tenant? Check the tenant domain shown at the top of the screen.
- Is there a lower-risk alternative (for example, purging a single cache instead of resetting the tenant)?
Best Practices
- Take an export before any destructive or cryptographic action.
- Rotate the tenant security key deliberately, not as a "just in case" reflex — it invalidates real user-facing flows.
- Use cache purges as a troubleshooting tool, not routine hygiene.
- Keep "Remove data" and "Application reset" reserved for tenant lifecycle transitions, not regular use.
- Document who on your team may perform each management action.