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 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 the 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 a 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 the Change Management process.

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

If after establishing the interface shown above the Change Management workspace has a 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.

To make versioning for process interfaces easier, Stages provides a feature to analyze and manage interfaces of a process version. To do that navigate to the Management section of the process and navigate to “Process Interfaces”. This page will show all the interfaces the currently selected process version has to other workspaces.

Selecting a remote workspace will display the interfaces to this workspace. If you select the working version of this workspace, it will also allow you to show only the changed interfaces. Those will show only the workspaces that also need to be released for the interface changes to show up.

When a new version of a workspace with modified interfaces is being released, the “New Version” dialog will show a new switch “Release interfaces in other workspaces”.

Workspaces are only listed if the user has the “Process Interface Release” write permission for those workspaces.

If the option described above is set, an interface release version will be created in those workspaces.

In contrast to normal versions, interface release versions are not based on the working version, but on the valid version of a workspace. They only contain the interface changes:

To be clear:

Interface Release Version = Previous Valid Version + Interface Changes

Those versions are automatically named with “… - 1”, “… - 2”, etc.

In the example above, version “QM V1.9” is the previously valid version and version “QM V1.9 - 1” was created as an interface release version.

If process owners want to directly create an Interface Release Version without releasing their Working Version, they can use the “Release interface” operation of the “Working Version” in the “Process Version” dialog:

In the next dialog, the interfaces to be included in the Interface Release Version can be selected:

After this step, the normal version creation dialog appears, but instead of a normal version, an Interface Release Version is created that contains the content of the valid version plus the selected interfaces.

The creation of interface release versions can also be controlled via release automations. Through automations, the owners or approvers of interfacing workspaces can be included in process reviews and approvals. This can be used to ensure that process interfaces are always approved by both parties before they are released.

Learn here how to use release automations for managing process interfaces.

When interfacing processes are integrated into the same workspace, the interfaces are transformed into regular process associations. In the below example, roles belonging to Change Management, Project Management, Risk Management, and System & Software Design process modules have been integrated into the Software Engineering workspace. As all the processes and roles now reside in the same workspace, the interfaces turn into regular associations.