Console

Applications

Overview

Applications represent systems under test in Zof Console, web properties, APIs, desktop software, or multi-tier compositions. Registering applications centrally establishes team ownership, environment metadata, and execution context reused across projects and Agent Console.

Accurate application records prevent misrouted runs and ambiguous reports. Include canonical URLs, environment separation, and responsible team so operators know whom to escalate when connectivity or agent selection fails.

Desktop and restricted-network workloads pair application records with endpoint agents and endpoint applications in Agent Console. Cloud agents handle typical web and API validation in managed runtimes.

Who should read this

QA engineers, SREs, platform teams, and developers operating Zof Console and APIs.

Prerequisites

Permission to view or manage applications in Platform
Known application URLs or endpoint deployment plan

When to use this workflow

Onboarding a new service into reliability workflows
Separating staging and production targets with distinct metadata
Registering endpoint desktop targets before fleet execution

Step-by-step procedure

Open Platform → Applications

Navigate via left navigation or ⌘K → "Applications".

Review existing registrations to avoid duplicate records for the same service.

Filter by team when operating in large multi-product organizations.

Register a web or API application

Create a record with human-readable name, primary URL, and owning team.

Document supported environments (staging, preprod, production) in metadata fields.

Link integration identifiers when source control or service catalog mappings exist.

Configure endpoint applications when required

For desktop or VDI scenarios, create endpoint application entries associated with Agent Console.

Assign labels and capabilities consistent with organizational agent policy.

Validate heartbeat and telemetry in Agent Console before scheduling dependent runs.

Associate applications with projects

When creating or editing projects, select the correct application to resolve execution targets.

Avoid swapping application linkage mid-release without revalidating suites tied to URLs.

Update application URLs when infrastructure migrations change hostnames.

Validate connectivity before critical runs

Run a smoke suite against staging after network or firewall changes.

Inspect run logs for DNS, TLS, or authentication failures pointing to application misconfiguration.

Coordinate with infrastructure teams when agents cannot reach private endpoints.

Maintain lifecycle and ownership

Transfer team ownership when services reorganize to keep notifications accurate.

Retire deprecated applications to prevent accidental selection in new projects.

Archive rather than delete when historical runs must remain explainable.

Key concepts

Web application: URL-driven target executed primarily by cloud agents.
Endpoint application: Desktop or restricted-network target executed by endpoint agents.
Environment: Named execution context (staging, production) with distinct base URLs or secrets policy.

Best practices

One application record per deployable service, not per micro-feature
Keep staging and production as separate environment entries, never implicit toggles
Document required headers or auth patterns in team runbooks linked from application metadata
Align Agent Console labels with application environment to avoid cross-environment execution

Common issues

Runs fail with connection errors: Verify URL, VPN requirements, and allowlists from agent runtime to application host. Test from Agent Console telemetry view.
Desktop runs never start: Endpoint agent offline, wrong label, or missing endpoint application linkage. Restore agent heartbeat first.

Was this page helpful?