Parameters

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 Parameters and click + New Parameter.
2. In Select type, choose the parameter type: Text, Password, Credentials, Number, Bool, List, or Map.
3. Enter a Name and the Value for the selected type.
4. (Optional) Add a Description and Tags.
5. Click Confirm (or Save) to create the parameter.

Edit a Parameter #

1. In the Parameters table, click the Action menu (⋮) for the parameter.
2. Select Details (or open the parameter).
3. Update the value and/or metadata (Description, Tags) as needed.
4. Click Save to apply the changes.

Delete a Parameter #

1. In the Parameters table, click the Action menu (⋮) for the parameter.
2. Select Delete.
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 #

Use Password or 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 #

Parameters 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:

• Connections: 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 the 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”.
• Use 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.