Workspaces contain sets of resources that you and team members can modify.
In your lifecycle product, you can specify which configuration to use by selecting it from the Configuration Management menu.

At the start of the project, a team member delivers Resource A and Resource B to the Great New Product workspace. The lifecycle product assigns a version identifier to the resources. These resources are now available to the team members who use this workspace.
Later that afternoon, team member Bob creates a snapshot of the top-level workspace because his team wants to capture the current state of the resources in the project and prevent further changes to these versions. Later, the team might use this snapshot to see how resources have changed, or another project team might use it as a starting point for a new project milestone.
The next day, team member Charlie creates a workspace named Great New Product Workspace 1, which is based on the Great New Product March 2014 snapshot. Charlie and his team members use this new workspace to start development on a new project milestone. The versions of the resources in the snapshot become the initial versions in the new workspace. Team members can edit the versions of the resources that are listed in the workspace (therefore creating new versions), deliver other resources, and remove resources from the workspace.
A week later, team member Dan delivers a change set that updates Resource B; this delivery changes the version that is associated with the Great New Product Workspace 1 workspace. Dan’s team members now see the updated version of the resource.
The next day, team member Joe delivers Resource D to the Great New Product Workspace 1 workspace. The lifecycle product assigns a version identifier “103” to this version, which the workspace now references.
Frank delivers his changes to Resource C to the top-level workspace. The lifecycle product assigns a version identifier “202” to this version, which this workspace now references.
Use change sets to group your changes to resources. A change set is associated with the workspace in which it is created. To make the changes in the change set visible in the corresponding workspace, you must share them.
This content applies to version 4.0.3 or later. To then make those changes visible to a different workspace, you must deliver the changes from the workspace to either an assigned flow target, or to another workspace that has a common ancestor as the workspace from which you are delivering changes.
For more information about flow targets, and delivering and merging changes, see the links to the related topics.
The roles and operations that are assigned in the Configuration Management application complement, but do not replace, the permissions that are assigned in the lifecycle management product. Permissions for lifecycle management products vary; see the administration pages or the online help for that product.
For the complete list of permissions, in the Configuration Management application, see the Permissions page of the appropriate Configuration Management project area.
If your workspace requires a version of a resource that exists in a snapshot in another configuration space, you can create a dependency on that snapshot. When you add a dependency on a snapshot, all the resources in the snapshot are included in the scope of the workspace and, therefore, to all the project areas that use the configuration space in which the workspace belongs.
You can only create dependencies on snapshots that are not in the same configuration space as the current configuration.
You can specify dependencies on snapshots only, not workspaces, because snapshots are immutable.
The Configuration Management application manages the organization of versions of resources and other configuration management capabilities.
In a lifecycle management product, teams work within a project area. A project area is an administratively defined area of the repository where information about one or more projects is stored. This information includes the project deliverables, team structure, process, and schedule. Typically, resources are organized into separate project areas so that there is one project area for each logical group of information. For more information about project areas, see the related link at the end of this topic.
The following concepts are specific to the Configuration Management application.
In the Configuration Management application, a configuration space is a mechanism for organizing workspaces and snapshots. When you create a project area in a lifecycle product, you can assign the new project area to an existing configuration space, or create a configuration space.
After you associate a project with a configuration space, you cannot associate that project with a different configuration space.
A configuration is a unique set of versions of resources. Configurations organize versions of resources into groups so that teams work on the correct versions of resources. There are two types of configurations: snapshots and workspaces.
After you modify resources, you can go back to the snapshot to see how the resources have changed.
To add, edit, and remove versions of resources in workspaces, you must have the corresponding permissions assigned to you or your role in the Configuration Management application. To make your workspace changes visible to other team members, deliver your changes from your workspace to a flow target, which is also a workspace.
When you create a workspace, you can select a snapshot on which to base the new workspace. You can also create a workspace based on the contents of another workspace in the same configuration space. For example, in the preceding scenario, you can create a workspace named GNP-WS2 based on Great New Product Workspace 1. The versions of the resources in the new workspace are the same as those resources in the selected workspace. A corresponding snapshot is also created. If you add, edit, or remove resources in the new workspace, you do not affect the resources in other workspace.
If your workspace requires resources in a workspace that is in a different configuration space, you must take a snapshot of the latter workspace, and then in your workspace specify a dependency on that snapshot.