Workspaces best practices

To help guide the development of your workspaces related business processes, consider the following best practices:

Use task group comments to coordinate and track work and for communication

Workspace Content Contributors should use task group comments to keep other Workspace Content Contributors posted about their work and changes they have made. Task group comments are also useful for Workspace Managers to see how work is progressing and to tell Workspace Task Group Approvers what changes have been made that require approval.

Minimize the number of tasks assigned to a Workspace Content Contributor

Try to combine the work assigned to a Workspace Content Contributor into one task where possible. This prevents unnecessary task switching and improves the Content Contributor's efficiency when working on tasks.

Put steps 1 and 3 into one task for Workspace Content Contributor A and create one task for Workspace Content Contributor B. The Workspace Content Contributors can coordinate their work using the task group comments.

Keep task groups independent of each other

A task group is the smallest unit of work that can be committed to the production-ready data on the authoring server. This means that all updates made in a task group will be committed to production-ready data together, but updates made in different task groups are not guaranteed to be committed in the same transaction. Interdependencies among task groups require you to commit the task groups in the correct order. Because resolving interdependencies among task groups is not automated, you should keep task groups independent of each other.

To keep task groups independent, you should carefully design your task groups and not use managed assets in more than one task group.

The task group locking policy does not completely prevent users from accessing managed assets that are created in different task groups. For example, if products A and B are created in task groups A and B respectively, a cross-sell association between products A and B can be created in task group C.

Creating and using only one task group per workspace is recommended if it can satisfy your business requirements. This is the strictest way to guarantee task group independence.

Keep workspaces independent of each other

Do not allow users to work on the same managed asset in different workspaces. This prevents overwriting data and achieves consistency between the production-ready data and workspaces.

Working on the same managed asset in different workspaces can also cause inconsistency between the production-ready data and the workspace data. For example, a catalog category was updated in workspace 1, but the same category was deleted in workspace 2. If the change from workspace 2 is committed first, committing the changes from workspace 1 will fail due to the inconsistency between the workspace and the production-ready data. The category is used in the workspace but it does not exist in production-ready data.

Keep the workspaces and the production-ready data consistent

You can also introduce inconsistencies between workspaces and the production-ready data by directly updating the production-ready data. When you update a managed asset in a workspace, the managed asset is not locked in the production-ready data.

Updates made directly to the production-ready data can be overwritten once updates in workspaces are committed or the updates can cause the commit from workspaces to be blocked. For example, if you update a catalog category in a workspace, you can block the commit of the changes in the workspace by deleting the category from the production-ready data.

If you need to work directly on the production-ready data, consider using a quick publish task group in a workspace instead. Otherwise, you must check if you must manually apply the same change to all of your workspaces as well as the production-ready data.

Avoid direct updates to the production-ready data

Avoid direct updates on the production-ready data on the authoring server unless the updates are isolated by your business processes.

Regardless of which locking policy you use, you can always create, update or delete content directly in the production-ready data. Direct updates to the production-ready data might be overwritten when a task group commits or they might prevent a task group from committing successfully.

Typically, updating and creating content in the production-ready data would not cause potential conflicts for the commit except where a unique index is involved. An example is trying to update a product part number to a value introduced in another workspace or base.

Deleting resources, such as removing associations or moving products, risks causing conflicts.

You should perform direct updates to the production-ready data only on assets that would not be worked on concurrently in a workspace or on assets that are introduced initially in the base. For example, if you receive pricing from a back-end system, you might choose to load and update directly to the production-ready data since Workspace Content Contributors would never update prices in a workspace. You might introduce new products or items directly into the base and create workspace processes only to update existing products or items.