One of the key features 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.

It allows central management of process elements in the process they belong to and 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.

It is highly recommended to not set working version as valid. When a process is newly created, the working version by default is also the valid version. The process should be baselined and marked as valid so that the working version no longer continues to be the valid version.

End users should always view the released baselined process which is the valid version of a process in Stages. If the working version is set as valid, users view the process which is still been updated by modelers and is not ready to be viewed or used.

Another reason to refrain from setting working version as valid is the impact it has 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.

'Analyze Change Request' activity uses 'Functional Specification' work product as an input through remote association as this work product belongs to Requirements Management. Requirements Management has a separate working version and valid version. Thereby making the remote association link to each version separately and showing twice.

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.