Quick guide

XOAP Verbindungen store the credentials and endpoints XOAP needs to integrate with external systems (for example, cloud providers and on-prem virtualization platforms). These connections are then referenced by other XOAP features.

Create a new Connection

1. Go to Verbindungen und klicken Sie + Neue Verbindung.
2. Unter Select connection type, choose: Cloud provider, On-Premises, or API key.
3. Fill in the required fields for the selected type (see examples below).
4. (Optional) Add Description und Tags.
5. Klicken Sie auf Test Connection (when available) to validate the credentials and connectivity.
6. Klicken Sie auf Bestätigen Sie (or Save) to create the connection.

Edit a Connection

1. In the Connections table, click the Action menu (⋮) for the connection.
2. Wählen Sie bearbeiten.
3. Update fields as needed.
4. Klicken Sie auf Test Connection (recommended) and Save/Confirm.

Delete a Connection

1. In the Connections table, click the Action menu (⋮) for the connection.
2. Wählen Sie Löschen.
3. Confirm the deletion.

Additional useful information

Use least-privilege credentials

Create separate identities/credentials per connection and only grant permissions required for the XOAP feature you’re using (for example, Image Management vs inventory-only).

Credential lifecycle

Rotate secrets regularly (especially cloud app secrets) and update the XOAP connection to match it. Prefer non-expiring/managed approaches where your environment allows it.

Tags help at scale

Tag connections by purpose (e.g., ImageManagement, Inventory, Prod, PoC) to make them easier to find and govern.

Test Connections early

If Test Connection fails, validate network reachability (proxy/firewall/DNS), identity permissions, and correct tenant/subscription context before troubleshooting XOAP features that depend on the connection.

Technical documentation

Verbindungen define how XOAP authenticates to external platforms and APIs. They are used by XOAP features that need access to your infrastructure (cloud or on-prem) or by the XOAP Connector during enrollment.

In XOAP you can create three connection categories:

• Cloud Providers (Azure, AWS, Google Cloud)
• On-Premises (vSphere, Nutanix) (Preview)
• API Keys (Preview)

Assignment scope: A connection can be assigned only to Images / Image Management und Geskriptete Aktionen (it is not used elsewhere).

Permissions: Minimum required permissions per provider are documented in XOAP prerequisites.

Connection types and fields

1) Cloud provider connections

Azure: Managed Identity

Fields you provide:

• Connection name – Friendly name used in XOAP to reference this connection.
• Connector – Device which have XOAP Connector installed on it (More info under Inventory Section)
• Subscription ID – The Azure subscription identifier where XOAP will manage/read resources.
• Description (optional) – Free-text note to document purpose/owner of the connection.
• Tags (optional) – Labels to help you find, filter, and govern connections (max 5 per object).

Test Connection: Available (verifies credentials/permissions against Azure).

Notes:

• Use a dedicated Managed Identety Device with least-privilege permissions and installed XOAP Connector features.
• Rotate secrets regularly; treat them like privileged credentials.

Azure – Application Registration

Fields you provide:

• Connection name – Friendly name used in XOAP to reference this connection.
• Connector – Device which have XOAP Connector installed on it (More info under Inventory Section). Not mandatory.
• Tenant  ID – The Entra ID directory (tenant) identifier where the application exists.
• Description (optional) – Free-text note to document purpose/owner of the connection.
• Tags (optional) – Labels to help you find, filter, and govern connections (max 5 per object).

Test Connection: Available (verifies credentials/permissions against Azure).

Notes:

• Use an Application Registration option when you want to run Scripted Actions from Platform Management, but you do not have Azure Subscription.
• Support MS Graph RestAPI.

AWS – Access Key

Fields you provide:

• Connection name – Friendly name used in XOAP to reference this connection.
• AWS account ID – The 12-digit AWS account identifier that owns the target resources.
• Access key ID – The public identifier part of an IAM access key.
• Access key secret – The private secret part of the IAM access key (treat as a password).
• Description (optional) – Free-text note to document purpose/owner of the connection.
• Tags (optional) – Labels to help you find, filter, and govern connections (max 5 per object).

Test Connection: Available (verifies credentials/permissions against AWS).

Note: Use a dedicated IAM user/role and least-privilege policy as per XOAP prerequisites.

AWS – Assume Role

Fields you provide:

• Connection name – Friendly name used in XOAP to reference this connection.
• Role ARN – The full Amazon Resource Name of the IAM role XOAP will assume for permissions.
• Description (optional) – Free-text note to document purpose/owner of the connection.
• Tags (optional) – Labels to help you find, filter, and govern connections (max 5 per object).

Test Connection: Available. (verifies credentials/permissions against AWS).

AWS – Assume Role (Cross-Account)

Fields you provide:

• Connection name – Friendly name used in XOAP to reference this connection.
• Role ARN – The IAM role ARN in the target account that XOAP will assume.
• External ID – A shared “secret” string required by the role trust policy to prevent confused-deputy access.
• Description (optional) – Free-text note to document purpose/owner of the connection.
• Tags (optional) – Labels to help you find, filter, and govern connections (max 5 per object).

Test Connection: Available (verifies credentials/permissions against AWS).

Note: Cross-account setups typically require a role trust policy + External ID pattern. XOAP’s prerequisites page lists the minimum permissions and guidance.

Google Cloud

Fields you provide:

• Connection name – Friendly name used in XOAP to reference this connection.
• Project ID – The Google Cloud project identifier where XOAP will manage/read resources.
• File (Service Account key JSON) – The uploaded JSON key file used to authenticate as a service account.
• Description (optional) – Free-text note to document purpose/owner of the connection.
• Tags (optional) – Labels to help you find, filter, and govern connections (max 5 per object).

Test Connection: Available. (verifies credentials/permissions against Google Cloud).

Note: The uploaded JSON key should belong to a service account with least-privilege roles required for your use case (Images vs Scripted Actions).

2) On-Premises connections (Preview)

vSphere

Fields you provide:

• Connection name – Friendly name used in XOAP to reference this connection.
• vCenter Server – The vCenter hostname or IP address XOAP will connect to.
• Username – The vCenter user (or SSO identity) used for authentication.
• Password – The password for the specified vCenter user.
• Datacenter – The vSphere Datacenter inventory object that contains the clusters/hosts/datastores you want to target.
• Cluster – The vSphere cluster under the selected datacenter that groups hosts and provides shared resource management (DRS/HA if enabled).
• Host – A specific ESXi host to target (often used when selecting an exact host instead of scheduling via cluster/rules).
• Resource pool – The resource pool within the cluster/host that defines CPU/RAM shares/limits/reservations for deployed VMs.
• Datastore – The storage location where VM files (VMDKs/config) will be placed.
• Folder – The vCenter VM folder used to organize where the VM object appears in the inventory.
• Insecure (toggle) – Allows connecting without strict TLS validation (use only when required in lab/PoC scenarios).
• Description (optional) – Free-text note to document purpose/owner of the connection.
• Tags (optional) – Labels to help you find, filter, and govern connections (max 5 per object).

Test Connection: Currently not available for on-premises.

Important behavior:

• Case-sensitive fields: vCenter inventory object names (Datacenter/Cluster/Host/Resource pool/Datastore/Folder) are case sensitive. Enter them exactly as defined in vCenter.

Nutanix

Fields you provide:

• Connection name – Friendly name used in XOAP to reference this connection.
• Nutanix Username – The account XOAP uses to authenticate to Nutanix (typically Prism).
• Nutanix Password – The password for the Nutanix account.
• Endpoint – The Prism endpoint (hostname/IP + port if applicable) that XOAP connects to.
• Cluster name – The Nutanix cluster identifier/name within Prism where operations will be performed.
• Insecure (toggle) – Allows connecting without strict TLS validation (use only when required in lab/PoC scenarios).
• Description (optional) – Free-text note to document purpose/owner of the connection.
• Tags (optional) – Labels to help you find, filter, and govern connections (max 5 per object).

Test Connection: Currently not available for on-premises.

3) API key connections (Preview)

Used for authenticating the XOAP Connector installation / enrollment flow (selecting an API key when generating install commands).

Fields you provide:

• Connection name
• API Token type (currently “Admin” and “XOAP Connector” have the same permissions — ignore the difference for now)
• Optional: Description, Tags

Security notes

• Treat API keys as secrets: restrict access, rotate when needed, and avoid embedding them in plain text documentation.
• If an API key is rotated, endpoints that rely on it (e.g., connector enrollment processes) must be updated accordingly.

Operational notes and best practices

• Least privilege first: Start from the minimum permissions documented in XOAP prerequisites, then expand only if a specific feature requires more.
• Separate by purpose: Use different connections for Image Management vs Geskriptete Aktionen if you want strict separation of privileges.
• Naming convention: Include provider + purpose + environment in the name (e.g., azure-im-prod, aws-sa-dev, vsphere-im-lab).
• Tagging: Add tags for ownership, environment, customer/project, and purpose (e.g., prod, lab, im, sa).
• Rotation & lifecycle: Plan a rotation process (especially for Azure Client Secret, AWS Access Keys, Google JSON keys, API keys).
• Assignment awareness: Before deleting a connection, verify it’s not assigned to any Images oder Geskriptete Aktionen.

The post Connections appeared first on XOAP.

Quick guide

XOAP Parameters provide a centralized way to store reusable values (for example, usernames, passwords, IDs, lists, and maps) so they can be referenced across XOAP features. Parameters are primarily used via Choose Existing fields throughout the UI—when you click Choose Existing, XOAP shows parameters that match the required type of that field.

Create a new Parameter

1. Go to Parameter und klicken Sie + New Parameter.
2. Unter Select type, choose the parameter type: Text, Password, Credentials, Number, Bool, List, or Map.
3. Enter a Name und die Value for the selected type.
4. (Optional) Add a Description und Tags.
5. Klicken Sie auf Bestätigen Sie (or Speichern Sie) to create the parameter.

Edit a Parameter

1. In der Parameter table, click the Action menu (⋮) for the parameter.
2. Wählen Sie Details (or open the parameter).
3. Update the value and/or metadata (Description, Tags) as needed.
4. Klicken Sie auf Speichern Sie to apply the changes.

Delete a Parameter

1. In der Parameter table, click the Action menu (⋮) for the parameter.
2. Wählen Sie Löschen.
3. Confirm the deletion.

Additional useful information

How “Choose Existing” works

When a field supports Choose Existing, XOAP filters the list to only show parameters of the same type as that field (for example, password fields only show Password parameters).

Use Parameters to standardize environments

Store common values once (tenant IDs, subscription IDs, endpoints, default usernames, etc.) and reuse them across connections, scripts, and other features.

Secrets handling

Verwenden Sie Password oder Credentials types for sensitive data instead of Text, and restrict access via RBAC where applicable.

Naming conventions help

Use clear prefixes to group parameters (for example AZ_, AWS_, VMW_, IM_, SA_, PROD_, POC_) so they’re easy to find in Choose Existing dialogs.

References

References are not auto-updated everywhere: changing a Parameter does not automatically update the effective value in all places where it was previously used. If a feature stores a snapshot of the value, you may need to re-save/re-apply the configuration (or re-run the relevant action) to pick up the updated parameter.

Technical documentation

Parameter are centrally managed values that can be reused across XOAP. They are designed to avoid hardcoding sensitive data (passwords, credentials), frequently reused identifiers (subscription IDs, tenant IDs), and environment-specific settings (paths, flags, lists, mappings).

Parameters are primarily consumed through Choose Existing fields across the UI. When you click Choose Existing next to a field, XOAP filters and shows only parameters that match the required type of that field.

Where Parameters are used

Parameters can be referenced from multiple XOAP features, typically wherever you see:

• A field with Choose Existing
• A field that supports sensitive values (passwords, secrets)
• A field that is reused in multiple configurations (IDs, names, lists)

Typical usage examples:

• Verbindungen: storing secrets/credentials (cloud secrets, vCenter password, Nutanix password, etc.)
• Scripted Actions / Automation: storing API tokens, usernames/passwords, environment variables
• Image Management: storing cloud identifiers, resource names, or credentials used by builders

Parameter Types

XOAP supports multiple parameter types. Each type determines validation, masking, and where it can be used.

1) Text

• Generic string value.
• Use for IDs, names, hostnames, URLs, non-sensitive values.
• Examples: tenant-id, subscription-id, resource-group, endpoint-url.

2) Password

• Secret string value (masked in UI).
• Use for any sensitive single-value secret (passwords, app secrets, tokens).
• Examples: vcenter-password, aws-secret-access-key, client-secret.

3) Credentials

• Structured object for authentication.
• Typically contains username and password (or equivalent fields).
• Best for places that expect a username/password pair together.
• Example value format (conceptual): { “username”: “xoap-admin”, “password”: “****” }.

4) Number

• Numeric value.
• Use for counts, thresholds, sizes, timeouts, etc.
• Examples: vm-count = 3, timeout-seconds = 600.

5) Bool

• True/False values.
• Use for feature toggles and flags.
• Examples: enable-tpm = true, dry-run = false.

6) List

• List/array of values.
• Use for collections such as hostnames, VM names, subnets, etc.
• Example: [“XOAPDEMO0001″,”XOAPDEMO0002”].

7) Map

• Key/value structure (dictionary-like).
• Use for structured configurations and mappings.
• Example: [{“name”:”key1″,”value”:”value1″},{“name”:”key2″,”value”:”value2″}] (format may vary by UI).

In der Parameter details page, XOAP shows where the parameter is currently referenced (Assigned to).

This helps identify:

• Which Scripted Actions / Platform Management items depend on it
• What will be impacted if you rotate credentials or change IDs

Use this view before:

• Rotating secrets
• Renaming or deleting parameters
• Changing environment-specific values

Security and operational best practices

• Store secrets as Password/Credentials, not Text.
• Rotate credentials regularly and keep a short operational procedure for “update + rerun/reapply”.
• Verwenden Sie tags to group parameters by:
  • environment (prod, poc, lab)
  • purpose (image-management, inventory, scripted-actions)
  • customer/project
• Prefer principle of least privilege: don’t reuse the same secret everywhere if scopes differ.
• For Credentials/List/Map types, keep the structure consistent and documented so teams know what to expect.

The post Parameters appeared first on XOAP.

Quick guide

XOAP Ressourcen is a central file repository used across XOAP. You can upload any file type (scripts, configuration files, templates, archives, binaries, etc.). Resources are commonly referenced by other XOAP features (for example, script selection in “Run Script”).

Create a new Resource

1. Go to Ressourcen und klicken Sie + Neue Ressource.
2. Upload your file(s) using Click to upload oder drag and drop.
3. (Optional) In the Resource details step, add:
   • Description
   • Tags
   • (Optional) Version message
4. Klicken Sie auf Next/Confirm to finish and create the resource.

Edit a Resource

1. In der Ressourcen table, click the Action menu (⋮) for the resource.
2. Wählen Sie Details.
3. If the resource is an editable type (PowerShell, Shell script, JSON, YAML, Text file), update the content and/or metadata as needed.
4. Save the changes (a new version may be created depending on the update workflow).

Delete a Resource

1. In der Ressourcen table, click the Action menu (⋮) for the resource.
2. Wählen Sie Löschen.
3. Confirm the deletion.

Additional useful information

Upload anything

XOAP Resources supports uploading any file type (not limited to scripts).

Editable formats

You can edit and maintain these resource types directly: PowerShell, Shell scripts, JSON, YAML, Text files.

Use tags for organization

Tag resources by purpose/environment (e.g., ImageManagement, ScriptedAction, PoC, Prod) to keep the library searchable and governed.

Resources are reused across XOAP

Many UI workflows that require a file/script (for example script execution flows) will reference content stored in Ressourcen.

Technical documentation

XOAP Ressourcen is a central repository for files used across the platform. You can upload any file type (scripts, configs, templates, binaries, archives, etc.). Resources are versioned and can be referenced by other XOAP features (commonly Scripted Actions and Image Management).

Resource Categories and Filtering

The Resources page provides filters/tabs for common file categories such as:

• All resources
• PowerShell
• Shell scripts
• JSON
• YAML
• ZIP
• Text files
• Activity log

These are primarily for organization and faster discovery; XOAP still allows uploading any format.

Core Resource Properties

Each resource typically has:

• Resource name
• Resource type (MIME/type classification)
• Description
• Tags
• Version und Version message
• Audit info (Created by / Updated by + timestamps)

Upload and Overwrite Behavior

When adding resources:

• You can upload files via drag & drop or file picker.
• Allow overwrite if already exists controls whether an upload can replace an existing resource with the same identity/name (depending on your XOAP behavior and constraints). If you overwrite an already existing file a new version is created with the uploaded resource.

Resource List Actions

From the Resource list (⋮ action menu), you typically can:

• View details
• Herunterladen
• Löschen

Resource Details Page

The Resource Details page is the main control surface for a resource.

Latest Version Panel

Shows:

• Latest version number
• Version message
• Creation / update metadata

Edit Resource Content

• Edit resource content opens an editor for supported text-based resource types (for example: PowerShell, Shell, JSON, YAML, Text).
• This allows in-place editing without re-uploading a file.

Save / Confirm and Versioning

When you save changes to resource content, XOAP prompts to create a new resource version:

• You can set the New Version (including Custom Version segments).
• You can provide a Version message describing the change.
• Confirming publishes the updated version as the latest.

Versioning is critical because other XOAP components can depend on a specific resource version for reproducibility.

View all versions and compare

From Resource Details, View all opens Versioning history where you can:

• See all historical versions
• Review version messages, dates, and authors
• Compare versions (diff view) to understand exactly what changed between revisions

Download Resource

• Download resource retrieves the currently selected/latest resource file.

Tags

• Tags support classification, filtering, and governance (e.g., vSphere, Image.XO, Prod, PoC).

Assigned to

Die Assigned to section lists where the resource is currently referenced (commonly under Platform Management, e.g., Scripted Actions). This helps impact analysis before changes:

• “Who uses this resource?”
• “Which version is currently referenced?”

Practical notes and best practices

• Verwenden Sie version messages consistently (what changed + why).
• Prefer editing via Edit resource content for small controlled changes in scripts/config files; prefer re-upload for large structural changes or binary artifacts.
• Treat shared resources as “interfaces”: changing behavior can affect downstream runs—use versioning to keep rollbacks easy.
• Use tags to separate environments and purposes (e.g., Prod, Test, CustomerX, AVD, Build, Deploy).

The post Resources appeared first on XOAP.

Quick guide

XOAP Zeitpläne let you run Image Definitions und Geskriptete Aktionen automatically on a defined time pattern (minutes, hourly, daily, weekly, or monthly). Each schedule can be assigned to one or more Images and/or Scripted Actions, and XOAP shows the Next scheduled run in the Schedules list.

Create a new Schedule

1. Go to Zeitpläne und klicken Sie + New Schedule.
2. Unter Schedule details, enter:
   • Name (required)
   • Description (optional)
   • Tags (optional)
3. Select the recurrence pattern using the tabs:
   • Minuten, Hourly, Daily, Weekly, or Monthly
   • Configure the timing options shown for the selected tab (e.g., “Every X minute(s)”, “Every X hour(s) on minute Y”, etc.).
4. Klicken Sie auf Weiter to open Assign schedule.
5. Assign the schedule to the targets:
   • Use the Images tab to select one or more images
   • Use the Geskriptete Aktionen tab to select one or more scripted actions
6. Klicken Sie auf Oberfläche to create the schedule.

Edit a Schedule

1. In der Zeitpläne table, click the Action menu (⋮) for the schedule.
2. Wählen Sie Details.
3. Update Name, Description, Tags, and/or the recurrence pattern (Minutes/Hourly/Daily/Weekly/Monthly).
4. Review or adjust the assigned Images / Geskriptete Aktionen (if applicable in your workflow).
5. Klicken Sie auf Speichern Sie.

Delete a Schedule

1. In der Zeitpläne table, click the Action menu (⋮) for the schedule.
2. Wählen Sie Löschen.
3. Confirm the deletion.

Additional useful information

What a schedule can target

A schedule can be assigned to Images and/or Geskriptete Aktionen (you can use one schedule for both).

Visibility of upcoming runs

The Schedules list shows Next scheduled run so you can quickly verify timing.

Tags for governance

Use tags like Prod, PoC, AWS, Hardening, WeeklyAudit to filter and manage schedules at scale.

Troubleshooting

If scheduled executions don’t occur as expected, validate the schedule pattern, assignments (Images/Scripted Actions), and check the relevant Activity log for execution evidence.

Technical documentation

Zeitpläne in XOAP define recurring execution times for Images und Geskriptete Aktionen. A schedule is a reusable object that combines:

• Metadata (name, description, tags, audit info)
• Recurrence pattern (minutes/hourly/daily/weekly/monthly)
• Assignments (which Images and/or Scripted Actions are linked to the schedule)

Schedules help standardize automation and make recurring runs predictable and auditable.

Where schedules are used

Schedules can be assigned to:

• Images (Image Management)
• Geskriptete Aktionen

A single schedule can be assigned to multiple targets, and to both categories at the same time.

Schedules list view

Die Zeitpläne list shows the most important schedule metadata at a glance.

Columns (typical)

• Name – Schedule name
• Description – Optional short description
• Next scheduled run – Calculated next run timestamp based on the selected recurrence pattern
• Tags – Optional labels for filtering and governance

Toolbar and list controls

• Suche – Filters schedules by name/description (and commonly tags depending on UI implementation)
• Columns selector – Choose visible columns
• Row selection checkboxes – Select items (if bulk actions exist in your environment)
• Pagination – Navigate through result pages

Row actions (Action menu ⋮)

• Details – Opens schedule details
• Löschen – Removes the schedule (after confirmation)

Schedule details page

Die Schedule details view is the authoritative place to inspect and manage a schedule. It includes:

1) Metadata section

• Name (required): Unique human-friendly identifier for the schedule.
• Description (optional): Free-text documentation for intent/purpose.
• Tags (optional): Used for filtering, governance, and grouping (e.g., aws, prod, weekly-audit).

2) Audit information (read-only)

• Created by / Updated by – User identity that created/last modified the schedule
• Creation time & date / Update time & date – Timestamps for lifecycle tracking

3) Recurrence pattern configuration

Schedules support the following recurrence modes:

• Minuten
• Hourly
• Daily
• Weekly
• Monthly

Only one recurrence configuration is active at a time. The UI shows the relevant controls for the selected tab. The schedule engine uses these settings to calculate the Next scheduled run shown in the list view.

Note: The UI typically expresses these patterns in a “human Cron-like” way (e.g., “Every X minutes”, “Every hour on minute Y”). The exact available fields depend on the selected mode.

4) Assignment section (targets)

Schedules can be assigned to two target types via tabs:

• Images tab
  Shows the list of Image Definitions currently assigned to the schedule.
• Geskriptete Aktionen tab
  Shows the list of Scripted Actions currently assigned to the schedule.

These tabs provide visibility into what will be triggered by this schedule.

The table commonly includes columns like:

• Name
• Status (Latest run) (where applicable)
• Output (Latest run) (where applicable)
• OS / Role / Builder (for images, depending on your workspace)

This section is primarily for association management and visibility (what is attached to the schedule).

Create schedule flow (wizard)

When creating a schedule, XOAP uses a two-step flow:

Step 1 – Schedule details

• Bereitstellung von Name, optionally Description und Tags
• Choose and configure the recurrence pattern (Minutes/Hourly/Daily/Weekly/Monthly)
• A Summary bar typically displays the chosen name and recurrence info

Step 2 – Assign schedule

• Select target objects under:
  • Images
  • Geskriptete Aktionen
• Die Summary bar typically shows how many targets are selected per type
• Finalize with Oberfläche

This wizard ensures schedule definition and assignments are captured together.

Actions and behavior

Speichern Sie

• Commits schedule configuration changes (metadata + recurrence)
• Die Next scheduled run is recalculated based on new settings

Löschen

• Removes the schedule definition from XOAP
• Any automation based on that schedule stops (because the schedule object no longer exists)

Details

• Opens the schedule configuration and assignment view for inspection/editing

Operational notes and best practices

• Add tags that help future governance and filtering (e.g., prod, poc, aws, audit, weekly).
• Prefer names that express intent and cadence (e.g., Weekly-CIS-Hardening, Daily-AVD-Image-Refresh).
• A schedule without assignments will exist but won’t trigger anything useful. Always confirm the assigned Images/Scripted Actions.
• Very frequent schedules (minutes/hourly) can generate significant compute and operational load depending on what your Images/Scripted Actions do.
• For targets shown in the assignment tables, “Latest run” indicators are the quickest way to spot issues; deeper investigation should use the relevant activity/log views in XOAP.

Limits and scope

• Schedules apply only to Bild Definitions und Geskriptete Aktionen.
• The UI provides Next scheduled run as the primary indicator that the recurrence definition is valid and active.

The post Schedules appeared first on XOAP.

Quick guide

XOAP Tags let you label and categorize objects across the platform (for example, Applications, Groups, Roles, Parameters, Resources, and Connections). Tags make it easier to search, filter, and govern objects at scale.

Create a new Tag

1. Go to Tags und klicken Sie + New Tag.
2. Enter a Tag name (up to 40 characters).
3. Select a Tag color.
4. (Optional) Add a Description (up to 160 characters).
5. Klicken Sie auf Bestätigen Sie to create the tag.

Edit a Tag

1. In der Tags table, click the Action menu (⋮) for the tag.
2. Wählen Sie Details.
3. Update Tag name, Tag color, and/or Description.
4. Klicken Sie auf Speichern Sie.

Delete a Tag

1. In der Tags table, click the Action menu (⋮) for the tag.
2. Wählen Sie Löschen.
3. Confirm the deletion.

Additional useful information

Assignment limit

You can assign up to 5 tags to a single object.

Keep naming consistent

Use simple, reusable naming (e.g., Prod, PoC, AWS, Azure, ImageManagement).

Use tags for governance

Tags are most useful when standardized across teams (environment, owner, purpose, customer, etc.).

Technical documentation

Purpose and behavior

Tags are reusable labels that can be assigned to many XOAP objects. They support:

• Filtering and search in list views.
• Consistency and governance through standard labeling.
• Cross-feature organization (the same tag can be reused across multiple modules/objects).

Important constraint: A single object can have maximum 5 tags assigned.

Tags list view

The Tags list provides an overview of all tags and their basic metadata.

Common columns

• Name: Tag identifier (up to 40 characters).
• Description: Optional free text (up to 160 characters).
• Preview: Visual representation of the tag (label + selected color).

Controls and actions

• Suche: Filters tags by name (and typically matches description if available).
• Columns selector: Choose which columns are shown in the table.
• Action menu (⋮) per tag:
  • Details: Opens the Tag details page for editing and assignment visibility.
  • Löschen: Removes the tag from the system (tag will no longer be available for assignment).

Create Tag

When creating a tag, the following fields are available:

• Tag name (required): Max length is 40 characters
• Tag color (required): Select one color from the available palette
• Description (optional): Max length: 160 characters

Tag details page

The Tag details page is the central place to maintain tag metadata and to see where the tag is used.

Editable fields

• Tag name
• Tag color
• Tag description

Audit metadata (read-only)

• Created by / Updated by
• Creation time & date / Update time & date

Assigned-to view (usage tracking)

Die Assigned to section shows which objects currently use the tag, grouped by module (for example: Application Management, Configuration Management, Image Management, Platform Management, Parameters, Resources, Connections).

What you can do here

• Review usage: See which objects are tagged (name + object type/description).
• Search within assignments: Quickly find where a tag is applied.
• Unassign from an object: Use the remove/unassign control (trash/bin icon) next to an entry to detach the tag from that object.

Deletion considerations

When a tag is deleted:

• It is removed from the Tags catalog and is no longer selectable for new assignments.
• Existing usage will no longer remain available as a tag association (i.e., the tag will not appear on objects anymore).

Recommended conventions and best practices

• Use a small set of global tags (e.g., Prod, Test, PoC) plus domain tags (AWS, Azure, vSphere, Security, AVD).
• Prefer short names that are stable over time (avoid embedding dates unless necessary).
• Define an internal standard so different teams don’t create near-duplicates (e.g., AWS vs Amazon).

The post Tags appeared first on XOAP.