Validating configuration before publishing

MobilityManager validates configuration on the server before it is saved or activated, so an invalid value can never take effect. Knowing what is checked helps you fix problems quickly and avoid failed saves. This article summarizes the validation applied across the main configuration areas.

Why server-side validation matters

Client forms guide you, but the platform re-checks every change on submit. A rejected change returns a specific error message rather than being partially applied, which keeps configuration in a consistent, safe state.

Belege configuration (publishing)

Publishing an expense configuration requires the SystemAdmin role and passes these checks:

• A version label is required.
• At least one Beleg type must be configured.
• Every severity must be a recognized value: Off, Info, Warning, or Blocking. An unknown severity is rejected with a message listing the allowed values and naming the offending type and field.
• The configuration baseline must be available, otherwise publishing returns a 503.

Note: Severity validation runs over every per-type field — fuel-type mismatch, missing cost center, missing VAT rate, duplicate detection, and mileage plausibility — so a stale client or a typo cannot persist a value the rules engine would not understand.

Localization labels

• You must submit at least one label.
• Each item needs a non-empty internal key, language code, and label.
• The internal key must be one of the recognized workflow-state or Beleg-type keys; an unsupported key is rejected.
• Saving requires the SystemAdmin role in addition to settings:manage.

Document storage

• The provider must be a supported value: Local, Azure Blob, or S3.
• Provider-specific required fields are enforced (for example a base path for Local, a container and connection reference for Azure Blob, and a bucket, region, and key references for S3).
• A supplied local encryption key must be a base64-encoded 32-byte AES key.
• When encryption at rest is enabled, an encryption key reference is required and must resolve from configuration.

Reference data

• Fuel type and motor type keys are required and stored lowercase.
• Keys must be unique; a duplicate returns a conflict.

A pre-publish checklist

1. Confirm you have the required permission — and the SystemAdmin role where publishing or localization is involved.
2. Review the current active version so you know what you are replacing.
3. Check that severities and provider fields use allowed values.
4. For email templates, preview before activating.
5. Submit, then verify the saved result by reopening the configuration.

Tip: If a save fails, read the returned message closely — it names the exact field or value at fault, which is faster than guessing.

Warning: A 503 "baseline not available" or "store not available" response is an environment problem, not a validation error. Retrying will not help; the underlying schema needs to be provisioned first.

Related

• Belege configuration overview and publishing a version
• Configuring document storage (Local, Azure, S3)
• Localization and workflow-state label translations
• System configuration overview and access