A work unit is a tool for grouping multiple products and bundles together so they can be distributed at the same time. In Product Catalog, every data change (create, update, reassociate, discontinue) for a product or bundle must be associated with a work unit.

Creating a Work Unit

There are two methods of creating a work unit:

• Create Work Unit API request
  • A client submits a request to create a work unit.
  • Product Catalog creates the work unit and returns a unique work unit ID in the response.
• Data change request with no work unit ID
  • A client submits a data change request with no work unit ID.
  • After successfully processing the request, Product Catalog creates a work unit.

Work Unit Identifiers

A unique system-assigned identifier (WU ID) is assigned to every work unit at the time it is created.

Following are details about WU IDs.

• Every data request must be associated with one work unit, which is associated with the data that is actioned per the request.
  • An existing WU ID can be listed on a data request
  • A data request can be submitted with no WU ID. In this scenario, Product Catalog creates the work unit
• A single WU ID can be listed on multiple data requests that are submitted separately. The data that is actioned for each request is has the same WU ID.
  Here is an example of three requests:
  • Request 1. Create product X – WU 1
  • Request 2. Update bundle X – WU 1
  • Request 3. Discontinue bundle Y - WU 1
  Product X and bundles X and Y are associated with WU 1.
• If a single request is for multiple data changes, all of the data that is actioned per the request has the same WU ID.
  Here is an example of multiple data changes on an Update request for bundle Z with WU ID 2.
  • Create product A and product B
    Product Catalog will create both A and B as an individual entity with its own record ID. These record IDs will be referenced in bundle Z but will be available for referencing in other bundles.
  • Add a reference from distributed product C to bundle Z
  • Disassociate distributed product D from bundle Z
  WU ID 2 will be associated with bundle Z and with products A, B, C, and D.

Work Unit Owners

Details about work unit owners:

• The owner of a work unit is the organization for whom the system created the work unit:
  • The organization that submitted a Create Work Unit API request
  or
  • The organization that submitted a data change request without a work unit ID
• The work unit owner may or may not be the catalog owner.
• The work unit owner can retrieve, update, and release only those work units that it has created.
  Here is an example:
  • Suppose tech provider ZZ is authorized to create, retrieve, update, and discontinue products on behalf of catalog owner 91.
  • ZZ submits a request to create Product A on behalf of 91. No work unit ID is on the request
  • The system creates Product A and work unit WU ZZ-1
  • The system associates Product A and work unit WU ZZ-1
  • ZZ owns WU ZZ-1; 91 owns Product A
  • ZZ can retrieve, update, and release WU ZZ-1; 91 is not authorized for these functions

Update a Work Unit

Use the Update Work Unit API to change the name or description of a work unit in Incomplete status. The system-assigned work unit identifier cannot be changed.

Updating a work unit does not change its associated products and bundles. Only the name and/or description are modified, along with the lastModifiedTime and lastModifiedBy values.

There are no partial updates. If either field fails validation, or the work unit is not in Incomplete status, the system rejects the request, makes no changes, and returns an error.

Reassociate Work Units

Reassociation moves products and bundles from one work unit to another — for example, to consolidate or reorganize data — without discontinuing and recreating it.

• Reassociation disassociates the data objects from its current (source) work unit and associates it with the target work unit in a single operation. There is no limit on the number of times a data object can be reassociated.
• The source and target work units must be in Incomplete status and have the same work unit owner. Cross-organization reassociation is not permitted.
• The target work unit can be an existing work unit, identified by its work unit ID, or a new one.
• When no work unit ID is provided, the system creates a new work unit with the system assigned work unit ID.
• A single request can move data objects into more than one target work unit. Each target work unit is processed independently — the failure of one does not affect the others.
• Products and bundles pass or fail in validation individually. The system reassociates the data objects that pass and returns an error for each data object that fails; failed data objects remain associated with their current work units.
• The response reports each target work unit's outcome — fully successful, fully rejected, or partially successful — and lists the products and bundles now associated with it.

Releasing a Work Unit

Releasing a work unit moves its associated data to the distribution workflow. Work units can be auto-released or they can be released manually.

The autoRelease field in every data change request indicates how the associated work unit should be released.

• Auto-release True: Product Catalog releases the work unit when the data change request is submitted and its associated data is successfully processed.
• Auto-release False: Product Catalog processes the data change request but does not release the associated work unit.

Because the work unit has not been released, the work unit owner can list the same WU ID on additional data change requests and then submit a Release Work Unit API request. All of the data associated with the work unit moves to the distribution workflow at the same time.

📝 Before a work unit is released, the system validates its associated data. If any associated data fails validation, the work unit is not released.