Tenant Settings
Tenant settings define the global configuration that applies to the whole tenant and every test it contains. They are reached via Administration → Select your Tenant. The page is split into multiple tabs; each tab is described below with a short business explanation for every field.
Most fields can be overridden on a per-test or per-step level — the value configured here is the default that is used when nothing more specific is set.
Head-Data
Master data and identity of the tenant.
| Field | What it controls |
|---|---|
| Tenant-Id | Permanent technical identifier of the tenant. Set on creation and cannot be changed afterwards. Used in URLs, API paths and audit logs. |
| Description | Human-readable name / short description shown in the tenant picker. Free text, up to 2000 characters. |
| Open-Id Role for Tenant Admins | Name of the OpenID Connect / OIDC role that grants administrator access to this tenant. Users whose token contains this role can change tenant settings, manage AI models, users and external systems. |
| Open-Id Role for Regular Users | Name of the OIDC role that grants regular user access (define and run tests, but no administration). Requires the admin role to be configured as well. |
| Logo of tenant | URL to a logo image. The image is shown in the navigation bar when this tenant is selected — useful when several tenants are operated by the same group of users. |
| msg.ZenTestAI: API-Key | API key used to call the msg.ZenTestAI REST API from CI/CD pipelines or other automation. The key itself is never displayed — only its presence. Use Regenerate to issue a new key (the old one is invalidated immediately). |
| Deactivate this tenant | Hides the tenant from the tenant selector for all assigned users. This is visibility only — existing permissions and data are preserved and the tenant can be re-activated at any time. |
AI
Default chat models that are used whenever a test or step does not pick a specific model itself. Before a model can be assigned here it must first be created on the AI-Models page.
The tab shows the list of configured chat models. Each model can be dragged onto (or ticked for) one or more of the following roles:
| Role | Used for |
|---|---|
| Default Model for Vision Tasks | All operations that need to look at a screenshot — most importantly assertions and visual element checks. Must be a vision-capable model (e.g. gpt-4o, claude-sonnet-4). Pure text models are not allowed. |
| Default Model for Complex Reasoning | Used when the step requires non-trivial planning — for example translating a natural-language step into the concrete action to perform, or driving the AI Assistant. Use a high-quality reasoning model. |
| Default Model for Standard Tasks | Used for high-volume, low-complexity tasks such as scanning the HTML page to identify elements. A cheap model with a large context window (e.g. gpt-4o-mini) is the recommended choice. If the cheap model is not confident enough, the platform automatically falls back to the reasoning model. |
| Default Model for AI Agent | Model used by interactive AI Assistant sessions (Define-Test, Get-Test-Running, Bulk-Create, Free Chat). Must have an API key configured and be on the allow-list for agent usage. |
A warning banner is shown until every role has at least one model assigned.
Defaults
Default values applied to newly created tests, plus tenant-wide behaviour for iframes and network waits.
| Field | What it controls |
|---|---|
| Default User for new tests | The user/agent that is pre-selected when a new test is created. Can be overridden in the test details. |
| Default URL | The start URL that is pre-filled for new tests. Can be overridden in the test details. |
| iframe Handling | How the test executor deals with <iframe> elements on the page. Options: System Default, No iFrames (most performant) — iframes are ignored, All iFrames are accessed — every iframe is entered, iFrames are accessed by Host — only iframes whose URL matches a configured list are entered. |
| iframe URLs | Only shown when iFrames accessed by Host is selected. Comma- or pipe-separated list of URL patterns; only iframes whose src matches one of the patterns are entered. |
| Handle Network Auto-Wait | Whether the executor waits for all outgoing network requests to finish before proceeding to the next step. Options: Wait for all requests (safest, default) or Ignore specific endpoints — useful when a slow analytics or telemetry endpoint blocks the test otherwise. |
| Network URLs to Ignore | Only shown when Ignore specific endpoints is selected. Comma- or pipe-separated list of URL patterns whose requests are not awaited. |
Service Requests
Controls what information may be attached when a user generates a Service Request for support (see Getting Help).
| Field | What it controls |
|---|---|
| Allow Service Requests | Master switch. When off, no Service Request can be created and all toggles below are ignored. |
| Tenant Configuration | Include the tenant configuration (this page, hosts, external systems) in the support bundle. |
| Application Settings | Include application-level / platform-wide settings. |
| AI Configuration | Include the list of configured AI models and the model assignments (API keys are always redacted). |
| API Communication | Include HTTP request/response logs of calls between backend, runner and external systems. Important for diagnosing integration issues. |
| HTML Content | Include the captured HTML/DOM of the pages under test. May contain customer data — keep off if your application processes sensitive information. |
| Memory Snapshots | Include memory and internal-state snapshots from the runner. Off by default because of the high privacy impact; turn on only when explicitly asked by support. |
External systems
Configures synchronisation with an external test management system (Jira Xray, Zephyr Scale, …). Because this tab has many vendor-specific fields, it has its own dedicated chapter: see External Systems.
The tab also exposes two convenience tools:
- Link All Available Tests — re-creates the link between every local test and its counterpart in the external system. Useful after switching from one Jira/Xray instance to another where the issue keys remained identical.
- Configure Pipeline — opens the CI/CD pipeline integration sidebar for triggering test execution from build pipelines.
Restrictions
Tenant-wide guardrails that protect against accidental misuse and runaway cost. All fields below are only enforced when Restrictions for this tenant are active is turned on.
| Field | What it controls |
|---|---|
| Restrictions for this tenant are active | Master switch. When off, all fields below are ignored and the tenant operates without limits. |
| Demo tenant | Marks this tenant as a public demo. Used for trial/marketing scenarios and may activate additional UI hints. |
| Restrict Tenant to host | Regular expression that the target URL of every step must match. Prevents tests written in this tenant from accidentally running against unintended domains (e.g. production while you are on staging). |
| Max Test-Case Definitions | Hard upper limit for the number of test cases that can exist in this tenant. 0 = unlimited. Useful for licensing or quota enforcement. |
| Max AI costs per day (cent) | Daily budget for AI API spend, expressed in cents. Once exceeded, further test executions are blocked until the next day. Cost is calculated from the per-token prices configured on each AI model. |
| Max AI executions per day | Maximum number of test executions allowed per calendar day. 0 = unlimited. |
| Do not allow editing | When on, the test catalogue becomes read-only for regular users; only admins can change tests. Typical for "locked" production tenants where tests must not drift. |
Proxy
Configures whether the test executor (and optionally the AI provider calls) go through an HTTP proxy.
| Field | What it controls |
|---|---|
| Proxy Handling | Three options: Use System Default — defer to the runner's system/environment proxy, Do not use a Proxy — bypass any system proxy and connect directly, Use a Proxy — use the proxy explicitly defined in the fields below. |
| Proxy URL | Address of the HTTP proxy (e.g. http://proxy.company.com:8080). Only used when Use a Proxy is selected. |
| Proxy User | Username for proxy basic authentication (leave empty if the proxy does not require credentials). |
| Proxy Password | Password for proxy basic authentication. Stored encrypted and never returned to the UI in plain text. |
| Use Proxy for AI Models | When on, outbound calls to the AI provider (OpenAI, Azure, Anthropic, …) also go through the proxy. When off, AI calls are made directly even if the proxy is otherwise active. Required in restricted networks where AI endpoints are only reachable via the proxy. |
| Test Connection | Opens a network diagnostic dialog that probes DNS, TCP and HTTPS reachability through the configured proxy. Use it after changing proxy settings to verify connectivity. |
Individual hosts can override these settings — see the host-level configuration on the External Systems and host detail pages.
Mail
msg.ZenTestAI can send e-mail notifications when scheduled or pipeline test runs fail. All fields below are only used when Send E-Mails for failed pipeline/scheduled tests is enabled.
| Field | What it controls |
|---|---|
| Send E-Mails for failed pipeline/scheduled tests | Master switch for notification e-mails. When off, no e-mails are sent regardless of the SMTP configuration. |
| SMTP-Server Host | Hostname or IP of the outgoing SMTP server (e.g. smtp.gmail.com, mail.company.com). |
| SMTP-Server Port | TCP port of the SMTP server. Typical values: 25 (plain), 465 (SMTPS), 587 (STARTTLS). |
| SMTP-Server User-Name | Username for SMTP authentication. Stored encrypted; can alternatively be loaded from an environment variable on the backend host. |
| SMTP-Server Password | Password for SMTP authentication. Stored encrypted; can alternatively be loaded from an environment variable on the backend host. |
| EMail-Sender | The From: address used in outgoing mails (e.g. noreply@company.com). |
| EMail-Receiver | New-line separated list of recipients that receive a notification whenever a scheduled or pipeline-triggered test fails. |
Feature Toggles
The Feature Toggles tab is hidden in the standard UI and is intended for administrators that have explicit guidance from support. The features listed here are typically beta — they may change behaviour or be promoted into the regular UI in a future release.
| Field | What it controls |
|---|---|
| Enable Advanced Auto-Complete for Test Definition | Activates AI-powered auto-complete suggestions while writing test steps in the editor. Suggests likely next steps and assertions based on what the test already contains. |
| Enable Agentic Execution for Select Actions | Replaces the deterministic select action with an agentic AI solution that takes a screenshot, decides how to open the dropdown, scrolls if necessary and picks the entry. Useful for non-standard dropdowns (e.g. virtualised lists, calendar widgets). |
| Enable Speed Mode | Activates a set of runner-internal optimisations (improved event-bubbling detection, unified wait tracking) that reduce execution time at the price of slightly less defensive timing in edge cases. |
| Disable Beta Features | The opposite switch: when on, beta-flagged features are hidden throughout the UI of this tenant. Use it to give end users a stable, conservative experience. |
| Network Trace | Opens the same network diagnostic dialog as on the Proxy tab — handy when investigating connectivity issues unrelated to the proxy. |
| Secret Synchronisation (expandable section) | Operations on the encrypted secret storage. Batch size controls how many rows are processed per iteration; Force rewrap re-encrypts already-current secrets onto the active key — used during key-encryption-key (KEK) rotation. The action buttons (Run one batch, Run until drained, Stop, Reset cursor) drive the backfill job and report scanned / migrated / failed counts. Only run this after coordinating with the platform operator. |