Skip to main content
Settings

Tenant customization

Locale defaults, picklists, ticket fields, and the tighten-only rule that keeps customization compliant.

Tenant-wide presentation and form configuration lives in the Presentation settings category. Changing it requires the settings.tenant.update permission (general settings) or settings.customization.manage (customization pages) — in the default role catalog, the tenant administrator holds both.

General settings

Settings → General sets the tenant display name and the tenant-wide defaults that users inherit until they set a personal override: language (English/German), date format, number format, timezone, and first day of week (Monday, Saturday, or Sunday). A fresh tenant starts with English, ISO dates, UTC, and a Monday week start.

The tighten-only rule

All customization in TENSOR follows one doctrine: you may restrict and decorate, never loosen or invent. Concretely:

  • A field requirement can move from optional toward mandatory, never back below the platform's floor.
  • A field's visibility can move from editable toward hidden — except compliance-mandatory fields, which can never be hidden, relabeled, or loosened.
  • Picklist options can be relabeled or hidden — except options marked compliance-locked.
  • Custom attributes can be added, but can never collide with or remove a platform attribute, and must declare a PII classification.

A change that violates the doctrine is rejected on save with a structured list of the violations, and the preview surfaces the same list before you commit anything. The point: a tenant can adapt terminology and add rigor for its own process, but no configuration can switch off an invariant a regulation depends on.

Picklists

Settings → Picklists governs the three platform picklists:

PicklistPlatform options
Incident priorityP1, P2, P3, P4
Incident severitySEV 1 · Critical through SEV 5 · Trivial
Change typeStandard (pre-approved, low-risk), Normal (CAB review), Emergency (expedited)

Per option you can relabel and toggle visibility. Compliance-locked options (for example, the change types the CAB quorum floors are defined against) cannot be hidden.

Ticket fields

Settings → Ticket fields configures forms per record type, in three tabs: Incident, Change, and Service request. For each attribute you set:

  • Requirement — optional, recommended, or mandatory.
  • Visibility — editable, read-only, or hidden.

Both axes are tighten-only, as above. You can also add custom attributes with a type (text, integer, boolean, date, enum, jsonb) and a mandatory PII class (none, identifying, or behavioral) — the PII class feeds pseudonymization and GDPR export behavior, which is why it cannot be skipped.

CMDB attributes

Settings → CMDB applies the same requirement/visibility model to configuration-item classes, plus display grouping and sort order per attribute, and the same custom-attribute mechanism. See the CMDB section of the docs for the class catalog itself.

Terminology and branding

  • Settings → Terminology — relabel platform terms to match your organization's vocabulary.
  • Settings → Portal → Branding — the self-service portal's name, logo, and colors. See Publish company branding for how publishing works.