> For the complete documentation index, see [llms.txt](https://developer.collibra.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.collibra.com/workflows/designing-workflows/processes/shape-repository/service-task/delegates/data-product-delegates.md).

# Data Product delegates

The Data Product delegates wrap the **multipart/form-data** endpoints of the [Collibra Data product REST API](https://developer.collibra.com/api/rest/data-product). Because Collibra API tasks do not support multipart requests, these delegates are the only way to call those endpoints from a workflow. For any other Data Contract API action, use the [Collibra API task](/workflows/designing-workflows/processes/shape-repository/collibra-api-task.md) instead.

All three delegates are located in the **com.collibra.dataproduct.workflow\.delegate** package and are available automatically with no additional configuration.

Each delegate writes the created or updated resource as a `Map<String, Object>` into the **data\_contract\_result** process variable so that downstream tasks or forms can consume it.

## AddFromManifestDelegate

The **AddFromManifestDelegate** adds a new version to an already-initialized data contract. It parses the manifest ID and version directly from the uploaded manifest content, so you don't need any explicit contract reference.

| Field name              | Type    | Required | Description                                                                                                       | Example                                                       |
| ----------------------- | ------- | -------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| manifest\_content       | String  | Yes      | The manifest content in YAML format. The manifest ID and version are parsed from this content. Must be non-empty. | `kind: DataContract\nname: customer-360\nversion: 1.2.3\n...` |
| manifest\_id            | String  | No       | Override for the manifest ID parsed from the content.                                                             | `customer-360`                                                |
| data\_contract\_version | String  | No       | Override for the version parsed from the content.                                                                 | `1.2.3`                                                       |
| active                  | Boolean | No       | Set to `true` to make this version the active one.                                                                | `true`                                                        |
| force                   | Boolean | No       | Set to `true` to overwrite an existing version with the same value.                                               | `false`                                                       |

Output:

* **data\_contract\_result**: The data contract with the newly added version, as a `Map<String, Object>`.

Properties:

* Class: `com.collibra.dataproduct.workflow.delegate.AddFromManifestDelegate`
* Calls: POST /rest/dataProduct/v1/dataContracts/addFromManifest

## InitDataContractDelegate

The **InitDataContractDelegate** creates a new Data Contract asset and links it to its initial manifest. If no manifest is supplied, a template is generated from the associated Collibra content. Use this delegate as the first step in creating a new data contract.

| Field name              | Type          | Required | Description                                                                                                              | Example                                 |
| ----------------------- | ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------- |
| governed\_asset\_id     | String (UUID) | Yes      | The ID of the governed asset the new Data Contract asset attaches to.                                                    | `019d19e1-3f74-7433-8532-522e14b5f587`  |
| domain\_id              | String (UUID) | No       | The ID of the domain in which the Data Contract asset is created.                                                        | `01923a45-9e7c-7d8f-9f9f-3b8a2e7c1f4a`  |
| manifest\_content       | String        | No       | The initial manifest content in YAML format. When omitted, a template is generated from the associated Collibra content. | `kind: DataContract\nname: orders\n...` |
| manifest\_id            | String        | No       | The manifest identifier inside the manifest document.                                                                    | `orders`                                |
| data\_contract\_version | String        | No       | The initial version label for the data contract.                                                                         | `1.0.0`                                 |
| data\_contract\_name    | String        | No       | A human-readable name for the Data Contract asset.                                                                       | `Orders Data Contract`                  |

Output:

* **data\_contract\_result**: The newly created Data Contract asset with its initial manifest version, as a `Map<String, Object>`.

Properties:

* Class: `com.collibra.dataproduct.workflow.delegate.InitDataContractDelegate`
* Calls: POST /rest/dataProduct/v1/dataContracts

## UploadDataContractVersionDelegate

The **UploadDataContractVersionDelegate** adds a new version to the version history of an existing data contract by explicitly targeting the asset ID of the contract.

| Field name                | Type          | Required | Description                                                                           | Example                                                       |
| ------------------------- | ------------- | -------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| data\_contract\_asset\_id | String (UUID) | Yes      | The ID of the existing Data Contract asset to upload a new version to.                | `019d19e1-3f74-7433-8532-522e14b5f587`                        |
| manifest\_content         | String        | Yes      | The manifest content in YAML format for the new version. Must be non-empty.           | `kind: DataContract\nname: customer-360\nversion: 1.2.4\n...` |
| data\_contract\_version   | String        | No       | The version label. Falls back to the version declared inside the manifest if omitted. | `1.2.4`                                                       |
| active                    | Boolean       | No       | Set to `true` to make this new version the active one.                                | `true`                                                        |
| force                     | Boolean       | No       | Set to `true` to overwrite an existing version with the same value.                   | `false`                                                       |

Output:

* **data\_contract\_result**: The data contract with the newly uploaded version, as a `Map<String, Object>`.

Properties:

* Class: `com.collibra.dataproduct.workflow.delegate.UploadDataContractVersionDelegate`
* Calls: POST /rest/dataProduct/v1/dataContracts/{id}/versions

## Using a Data Product delegate

Each delegate is configured as a service task in Workflow Designer.

{% stepper %}
{% step %}
Add a **Service Task** at the point in the process where you want the delegate to run.
{% endstep %}

{% step %}
Set the implementation type to **Java class**.
{% endstep %}

{% step %}
Enter the fully qualified class name from the delegate properties into the **Class** field.
{% endstep %}

{% step %}
Ensure every required input process variable is populated before the service task runs. The delegate reads variables by name, so the variable name must match the field name exactly. Common ways to populate variables:

* From a **User task** form: Bind the form field value to `{{variable_name}}`. When you submit the form, the process stores the value under that name.
* From a **Script task**: Use `execution.setVariable("variable_name", value)`.
* From the workflow starting asset for asset-scoped workflows: Capture `${item.id}` in a script task, for example `execution.setVariable("data_contract_asset_id", item.id.toString())`.
* From a previous **Collibra API task**: use the **saveResponseParameters** option to store the response under the required name.
  {% endstep %}

{% step %}
Consume the **data\_contract\_result** output after the service task. The delegate writes the response body to this variable as a `Map<String, Object>`. Typical follow-ups are:

* Read fields in a downstream form using dot notation. For example: `{{data_contract_result.id}}` or `{{data_contract_result.manifestVersion.version}}`.
* Pass values into another delegate or **Collibra API task** by reading the map and setting the required fields on subsequent variables.
  {% endstep %}
  {% endstepper %}

## Notes on input types

* ID parameters, such as `governed_asset_id`, `data_contract_asset_id`, or `domain_id` are passed as strings. The delegates parse them and return an error if the value is missing or not a valid UUID.
* The **manifest\_content** parameter expects raw YAML text. The Collibra **fileUpload** form widget stores a file reference as an ID rather than file content, so workflows that source the manifest from a file upload field need a Groovy script task to resolve the reference with `fileApi.getFileAsStream(fileId).getText("UTF-8")` and write the result into `manifest_content` before the delegate runs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.collibra.com/workflows/designing-workflows/processes/shape-repository/service-task/delegates/data-product-delegates.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.