One of the key capabilities of Stages is reuse of process elements. If a role, work product or guidance has been created in one workspace, it can be used in another process in a different workspace. This creates remote associations between the two workspaces.

Remote associations allows central creation and management of process elements in the process they belong to. It also fosters communication between functions about their dependencies on each other. If an element is coming from another workspace, it is has a double arrow next to the name. In below Change Management process example, an activity requires Project Manager and Risk Manager roles which reside in Project Management workspace, to be consulted and this creates a remote association between the workspaces.

Remote associations are created by simply selecting a role, work product, guidance and other elements from another workspace using the Browse option to add association.

One of the recommendations for process versioning is to not set working version as valid due to the impact on remote associations. During the life of the process (e.g. Change Management), if the working version is set as valid; and the processes (e.g. Requirements Management) it has remote associations with have a separate valid and working version, then the remote associations will be linked to working and valid versions separately and appear twice (e.g. remote association to work product Functional Specification)

If Change Management continues to have working as valid version, it can lead to some unintended consequences. One, end users will find this confusing and not know which input to refer back to. Secondly, a modeler might manually choose to delete on the duplicates. In this case, if the input without the V (i.e. the one linking back to working version) is deleted and later Change Management process is released and marked valid, then the working version will no longer have the remote association as it was previously deleted. This might potentially introduce an error in working and future baselined version of missing remote associations.

The recommended practice is when a process with remote associations modeled in the working version is baselined by creating a process version, then the process(es) with which these remote associations are established should also have working version baselined by creating a new process version. Also, if released version is set as valid for one process, it should also be set as valid for the other workspace.

In below example, Project Manager from Project Management Process is added as 'Consulted' for Create Change Request activity in Change Management process thereby establishing a remote association.

This remote association reflects in working version of both the workspaces.

If after establishing remote association shown above Change Management workspace is has process version released, while the Project Management does not, then as shown below newly released process version will fail to show the remote association with Project Manager as Consulted role.

To fix this issue, a new process version of Project Management should also be released. Once the process is baselined, remote associations will appear on both sides.