Template

Reverse Provisioning Template

Every system or component in Witboost is associated to a use case template id that identifies the template it has been created from and keeps a reference to an infrastructure template which is used to identify the technology (tech) adapter that can interact with the infrastructure service(s) on which the entity is physically deployed.

To perform a Reverse Provisioning operation, the entity's tech adapter may require specific information from the user (e.g., a token, table name, URL, etc.). Therefore, the Platform Team needs a tool that allows them to define the necessary user inputs when initiating a Reverse Provisioning operation on a system or component.

The ReverseProvisioningTemplate Witboost entity allows defining a set of Reverse Provisioning input parameters and linking them to one or more use case template IDs. When a user navigates to a component page, and a ReverseProvisioningTemplate entity associated with the component's use case template ID is found, they will be able to proceed to the Reverse Provisioning import wizard. The first step of the wizard will display an input form based on the parameter definitions stored in the ReverseProvisioningTemplate entity.

Entity definition

To define a new ReverseProvisioningTemplate entity, the Platform Team needs to create a reverse-provisioning-template.yaml file in a Git repository, with the following properties:

Field	Type	Description
apiVersion	string	witboost.com/v1 (legacy) or witboost.com/v2
kind	string	Fixed to ReverseProvisioningTemplate.
metadata	EntityMetadata	Standard Witboost entity metadata (e.g., metadata.name).
spec.domain	string (optional)	Domain of the entity.
spec.owner	string (optional)	Owner of the entity.
spec.useCaseTemplateId	list[string] (optional)	Associates the ReverseProvisioningTemplate with deployment unit components that have a matching useCaseTemplateId.
spec.useCaseTemplateRef	list[string] (optional)	Full references (type:namespace/name) to one or more use case template entities (e.g., template:default/dataproduct-template). The useCaseTemplateId values from the referenced templates will automatically populate spec.useCaseTemplateId.

note

If no spec.domain is specified, the ReverseProvisioningTemplate entity will be available for all users if RBAC is enabled.

note

You can fill both spec.useCaseTemplateId and spec.useCaseTemplateRef arrays. The resulting ReverseProvisioningTemplate entity will process and merge their elements in a single spec.useCaseTemplateId array.

Property spec.parameters stick to the same templating language used inside the definition of a use case template (property spec.parameters inside template.yaml). The only difference is that spec.parameters of template.yaml may accept a list of parameter objects, while spec.parameters of reverse-provisioning-template.yaml expects a single object that will be rendered in UI form.

Sample reverse-provisioning-template.yaml

apiVersion: witboost.com/v1
kind: ReverseProvisioningTemplate
metadata:
  name: test-reverse-prov-template
spec:
  owner: group:agile_lab
  domain: domain:organization
  useCaseTemplateId:
    - urn:dmb:utm:aws-cdp-outputport-impala-template:0.0.0
  parameters:
    required:
      - table
    properties:
      database:
        title: Database name
        type: string
        description: Impala Database name
      table:
        title: Table name
        type: string
        description: Impala table name
      format:
        title: Format
        type: string
        description: File format
        enum:
          - PARQUET
          - CSV
        enumNames:
          - 'Parquet'
          - 'CSV'
      ignoreTechnicalColumns:
        title: Ignore technical columns
        type: boolean

This specification will create a ReverseProvisioningTemplate entity, associated with each component or system with a use case template id equal to urn:dmb:utm:aws-cdp-outputport-impala-template:0.0.0. When a user opens the Reverse Provisioning Import Wizard on one of these components, they will be presented with the form in the following image:

note

Even if not explicitly defined in the ReverseProvisioningTemplate, the Import Wizard always renders a mandatory environment field. This is used to target the environment for the provisioning data collection.

Templating language

To better understand the templating language for reverse provisioning parameters and the available input field types check this page and this one.

tip

To test a form definition and preview how it will be rendered, you can exploit the Template Editor located at https://<witboost-url>/scaffolder/edit. It is not specifically intended for reverse provisioning templates but it can serve as a good visual preview tool.

Versions

Reverse Provisioning Templates can be defined using either apiVersion: witboost.com/v1 or witboost.com/v2. These versions determine default behaviors, particularly regarding entity compatibility, and whether editing Skeleton or Legacy entities is supported.

note

A system or component may match multiple Reverse Provisioning templates, if more than one template is associated with its useCaseTemplateId.

In such cases, Witboost prioritizes templates using apiVersion: witboost.com/v2 over those using v1.
This ensures that the latest compatibility logic and features are always applied when available.

If no compatible v2 template is found, Witboost will fall back to a matching v1 template — provided it supports the entity type (skeleton or legacy).

witboost.com/v2 (Recommended)

This is the modern, recommended version. It supports editing of Skeleton Entities out-of-the-box and lets you optionally allow or forbid edits on Legacy Entities using a compatibility block.

Compatibility Options (Optional)

When using v2, you can add a compatibility section to control whether legacy entities can be edited using this template:

apiVersion: witboost.com/v2
kind: ReverseProvisioningTemplate
# ...
spec:
  compatibility:
    legacyEntities:
      executionPolicy: NOT_ALLOWED # ALLOWED, NOT_ALLOWED (default)

If omitted, default compatibility behavior applies (legacy entities: NOT_ALLOWED).

witboost.com/v1 (Legacy)

This version was originally built for editing Legacy (non-skeleton) Entities. By default, it only supports Legacy Entities, but can optionally be extended to support Skeleton Entities too.

Compatibility Options (Optional)

apiVersion: witboost.com/v1
kind: ReverseProvisioningTemplate
# ...
spec:
  compatibility:
    skeletonEntities:
      executionPolicy: ALLOWED # ALLOWED, ALLOWED_WITH_WARNING (default), NOT_ALLOWED

By default, Skeleton Entities are supported by v1 templates with ALLOWED_WITH_WARNING execution policy which makes the Import Wizard display a warning like:

To support backward compatibility with legacy tech adapters, you can define a pathToParameterMap under skeletonEntities in your compatibility block. This mapping tells Witboost how to translate catalog-info.yaml field updates into valid parameters.yaml updates at runtime.

Example

parameters.yaml of the Skeleton Entity:

parameters:
  emailParam: current@email.com
  tagsList: []
  unchangedParam: unchanged-value

reverse-provisioning-template.yaml

apiVersion: witboost.com/v1
kind: ReverseProvisioningTemplate
# ...
spec:
  compatibility:
    skeletonEntities:
      executionPolicy: ALLOWED
      pathToParameterMap:
        spec.mesh.email: emailParam # spec.mesh.email --> parameters.emailParam
        metadata.tags: tagsList # metadata.tags --> parameters.tagsList

Update returned by a legacy tech adapter:

{
  "metadata.tags": ["tagA", "tagB"],
  "spec.mesh.email": "new@email.com"
}

Updated parameters.yaml:

parameters:
  emailParam: new@email.com
  tagsList:
    - tagA
    - tagB
  unchangedParam: unchanged-value

info

Updates targeting catalog-info paths like witboost.parameters.<key> are automatically converted to updates under the parameters: section of the parameters.yaml file when editing Skeleton Entities.

This ensures compatibility with older Reverse Provisioning implementations that send updates using the witboost.parameters path.

No explicit pathToParameterMap configuration is required for these cases — the transformation happens automatically.

If a field update cannot be mapped to a corresponding parameter, it will be ignored.

Updating Skeleton Entities

To update a Skeleton Entity, the Import Wizard operates on the entity's parameters.yaml file.

When the user submits the form and an update is received from the tech adapter:

• The updated values are merged into the parameters: block of the parameters.yaml file.
• Existing values with the same name are overwritten.
• The catalog-info.yaml remains unchanged — values are injected dynamically at render time.

Updating Legacy Entities

To update a Legacy Entity, the Import Wizard applies changes directly to the entity's catalog-info.yaml file.

Entity registration

Once the reverse-provisioning-template.yaml file is defined, you can register the ReverseProvisioningTemplate entity in the Witboost Catalog.

Automated way

When a reverse-provisioning-template.yaml is placed in the same folder as a Witboost use case template's template.yaml file, it will be automatically fetched by Witboost and the related ReverseProvisioningTemplate entity will be registered (or refreshed).

Manual way

It's also possible to manually register ReverseProvisioningTemplate entities from the Catalog Import page https://<witboost-url>/scaffolder/import (Builder > Templates > Register Template button) by providing the URL of reverse-provisioning-template.yaml.

Template reloading

In order to reflect the modifications made on the reverse-provisioning-template.yaml to the Witboost ReverseProvisioningTemplate entity you have two options:

1. wait for Witboost to automatically fetch and sync the changes
2. Builder > Software Catalog > Filter for ReverseProvisioningTemplates > Open the target entity page > Click on the refresh icon

Documentation

ReverseProvisioningTemplate entities can be documented exactly like other witboost entities. Check this section for additional details.

The documentation can then be read from the ReverseProvisioningTemplate catalog page (Docs tab) and will also be accessible from the Reverse Provisioning Import Wizard on components associated to the documented template.

tip

It is strongly recommended to provide clear documentation of the output (the metadata that will be imported) the user can expect after running the reverse provisioning operation.

Reverse Provisioning Template Checklist

The following checklist can be used to verify if a ReverseProvisioningTemplate entity has been loaded successfully and is semantically correct.

• Go to Builder > Software Catalog > Filter for ReverseProvisioningTemplates

  • Check: the target entity is found
  • Open the entity page
    • Check: no errors are displayed
    • Check: in case you documented the entity, the Docs tab correctly renders it

• Go to Builder > Templates

  • Check: every use case template listed in the spec.useCaseTemplateRef field in reverse-provisioning-template.yaml - or every template that generates components with one of the use case template ids in spec.useCaseTemplateId - features a clickable magic wand icon that redirects to ReverseProvisioningTemplate entity page.

  

  info

  The magic wand icon on a use case template card indicates that every component created starting from that use case template is suitable for the reverse provisioning operation; the reverse provisioning input parameters are defined by the ReverseProvisioningTemplate entity referenced by the icon hyperlink.

• Open the reverse provisioning input wizard of one of the target components

  • Check: the input form in the first step of the wizard is correctly rendered and it's the desired one
  • Check: in case you documented the ReverseProvisioningTemplate entity, an info icon on the upper right corner of the wizard is displayed and it links to the documentation

Entity removal

A ReverseProvisioningTemplate entity can be unregistered from the Software Catalog (Builder > Software Catalog > Filter for ReverseProvisioningTemplates > Find the target entity) just like any other catalog entity.

caution

If you unregister an entity whose reverse-provisioning-template.yaml is placed in the same folder of a witboost use case template's template.yaml file, it will be automatically reloaded by witboost (see the Automated entity registration section above). In this case, please remember to first remove reverse-provisioning-template.yaml from the repository before deleting the related entity from the Software Catalog.