One of the key principles of Stages is that every process element should only be modeled once. 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 process interfaces between the two workspaces.

Process interfaces allows creation and management of process elements in the processes they belong to. It also fosters communication between functions about their dependencies on each other. Process interfaces are indicated by double-arrow icon and name of workspace they belong to. In the following example, an activity in the Change Management process requires the consultation of the Project Manager and Risk Manager roles which reside in the Project Management workspace. This creates a process interface between the two workspaces.

Process interfaces are created by typically selecting roles or work products from another workspace within the same workspace collection (TODO: see here for details ) or by using the Browse option when adding the association.

One of the recommendations for process versioning is to not set working version as valid due to the impact on process interfaces.

During the life of the source process (e.g. Change Management), if the working version is set as valid; and the target processes (e.g. Requirements Management) it interfaces with have a separate valid and working version, then the source process will show two interfaces (e.g. interface 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 one of 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 process interface as it was previously deleted. This might potentially introduce an error in working and future baselined version of missing process interfaces.

The recommended practice is when a process where the interfaces are modeled in the working version is baselined by creating a process version, then the process(es) which have such associations should also have working version baselined by creating a new process version.

In the following example, Project Manager from Project Management Process is added as 'Consulted' for Create Change Request activity in Change Management process.

This process interface reflects in working version of both the workspaces.

If after establishing interface shown above Change Management workspace has process version released, while the Project Management does not, then as shown below newly released process version will fail to show the interface 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, interfaces will appear on both sides.

In summary, a process interface appears on both sides only when both of the workspaces are either in working or both have a distinct version.

When processes which interface with each other are integrated in the same workspace, then the interfaces are transformed into regular process association in the integrated workspace. In below example, roles belong to Change Management, Project Management, Risk Management and System & Software Design process modules have been integrated into Software Engineering workspace. As all the processes and roles now reside in the same workspace, the interface appear as regular associations.