The following workflow is typical for a team that is working in product configurations.
The top of a product tree must be a product configuration. This is because configurations determine the versions of all the products in a configuration. (Products know their immediate child products, but not the versions of those child products.)
Configurations can use dimension and value pairs to express variations in your products that are based on those dimensions and values. A dimension describes how a product configuration or product branch is unique by defining its aspects. A dimension consists of a name, such as geo, and a value, such as uk.
Example: If your product is a speedometer that is created in the United States, you could create a variant of the speedometer product for the United Kingdom.
When you set dimension and value pairs for a configuration, the pairs determine the versions of all the products in that configuration. Each dimension and value pair must be unique, but you can add as many pairs as you need to configurations and to products. To edit dimension and value pairs for a configuration, in the Create Product Configuration dialog box, read the Dimensions hover help.
After you create a product configuration, you work with it and its products in the Browse Products page.
A product configuration alone is not useful. The configuration collects products that are used to organize requirements, design models, work items, and test cases, which your team needs for your product.
If you do not yet have products or configurations to add to the configuration, see Importing files from other tools as baselines or Creating a product.
When you start your product release, you set up one or more configurations. A configuration is always at the top of the product tree. The rest of the hierarchy can be a mix of configurations with child configurations, configurations with child products, products with child configurations, and products with child products.
A team is working on a mechanical heart valve with approximately 11 pieces, such as titanium lock ring, locking wire. Pete, the team lead, decides to use one product configuration at the top, called Heart Valve 2017. Pete creates a product for each part of the heart valve, such as, titanium lock ring-1 and locking wire-1. Under each product, the team members responsible for the product add artifacts, such as work items, requirements, test cases, and design models.
A team is working on a new mobile phone with a top-level configuration called SmartPhone V5. Susan, the team lead, knows the pieces that she needs to build the smartphone. Susan needs to find the pieces, such as the screen, the camera, the touchpad.
First, Susan looks at an existing smartphone to see which pieces she needs, then adds the relevant configurations to her SmartPhone V5 configuration. (If she adds products to SmartPhone V5, she needs to be sure to add dimensions and values to her SmartPhone V5 configuration to collect the latest product branches.) Next, she creates new pieces for the smartphone, either products or configurations, as needed.
Susan's team is contributing to this phone a 10-megapixel camera with an enhanced flash called Camera EF. Several other product teams plan to use the new camera, so she creates a configuration for easier reuse. She sets dimensions and values to flash=enhanced. She creates a variant product of the old Flash product, and sets its dimension and value to flash=enhanced. She adds Lensand other products, and sets their dimensions and values to flash=enhanced.
Later, if you find that a configuration should be a product or a product should be a configuration, you can convert them. You can swap a configuration with its children or swap a product to make a new configuration. See Swapping configurations and products.
The products might or might not have dimension and value pairs set. If they do, they must match those set in the parent product configuration (not the top-level configuration, unless it is the parent).
You and your team can view it in the Browse Products list box.
At some point in a product release, some aspect of product development might stop because of a problem. You might want to compare configurations to see where a problem was introduced, find where a problematic child product is used, and create a patch. See Comparing product configurations, Finding where a product configuration or product is used, and Creating a patch from a baseline.
At a certain point, your team reaches a milestone, such as a sprint date or beta release. Milestones are good places in the product release to create non-modifiable versions of a configuration hierarchy. For steps, see Creating a baseline to capture a milestone. After you create a baseline, you can create a modifiable copy of the baseline to make the configuration and its product hierarchies modifiable again.
After your product is released and you are ready to begin work on the next release, create a modifiable copy of the baseline to begin work.