Root cause for LOST+FOUND

If an process element is removed, but other objects—such as process elements, files, or user assignments—depend on that element and Stages did not receive an explicit order to delete them, those dependent objects are moved to LOST+FOUND to prevent them from being deleted.

All cases listed below are examples of this core problem.

Case 1.1: A work product with a linked file is deleted

Example:

• Create a work product WP1 with a link (or upload a file, or connect to a file in a CMS)
• Create a process version V1 and set it to valid
• Delete WP1 in the working version
• Create a process version V2 and set it to valid

→ LOST+FOUND folder is created for WP1 so that the link is not lost

Case 1.2: A role with a user assignment is deleted

Example:

• Create a role ROLE1 and assign a user
• Create a process version V1 and set it to valid
• Delete ROLE1 in the working version
• Create a process version V2 and set it to valid

→ LOST+FOUND folder is created for ROLE1 so that the user assignment is not lost and prevents the user from losing access rights

Case 2.1: Imported project data/guidance files

Example:

• integrate process version V1 of Case 1.1 or Case 1.2 into a new process
• make the update and create V2 (see Case 1.1 or Case 1.2)
• update integrated process to use V2

→ LOST+FOUND folder is created in the integrated process

Case 2.2: Local project data /guidance files

Project data is added locally in the integrated process for elements imported with a module. If those module elements are deleted with an update of the module or the module is removed completely → LOST + FOUND

Case 2.3: Local sub-elements

If sub-elements are added locally in the integrated process for elements imported with a module. If those module elements are deleted with an update of the module or the module is removed completely → LOST + FOUND

Case 2.3b: Elements are moved to another location which is then deleted with a module update/removal

If an element from module A is moved under an element from module B and that element is deleted because of a module update/removal → LOST + FOUND

Case 2.4a: Using a “structural module” in different versions

If a structural module is integrated with different versions, in the version that is imported last, some elements are missing.

E.g. V2 includes an element FolderXYZ, that didn’t exist yet in V1 but is used in Process 2. If Process 1 is updated/imported after Process 2, FolderXYZ will moved to LOST+FOUND.

Hint: When using a common elements module for structure, tailoring, etc., and importing it into process modules that are then integrated elsewhere, always ensure that only process modules with the same version of the common elements module are integrated together.

Case 2.4.b: Common elements imported in different versions with different element identities

This should be a rare case, but if it happens, it might be difficult to detect. It is a variation of Case 2.4.

The elements in the common elements module can receive new identities, for example:

• If they were deleted and recreated with the same name
• If they were imported by an importer that always creates new identities
• Other reasons for new identities

At first glance, these elements look the same because they have the same name, but due to the different identities, they are considered different objects by Stages.

Case 2.4.c: On-demand problems

When using common elements with on-demand import, a folder element (or another parent element) might be imported into module A.

If it is later decided that the on-demand element is no longer needed in module A, and the folder element is deleted, issues can arise if that folder element is still needed for on-demand elements from other modules in the integrated workspace.

If module A was the last module imported or updated in the integrated workspace, and it is now updated again without the folder element, Stages thinks it needs to delete the folder element. However, since the folder element has sub-elements from other modules, it is moved to LOST+FOUND instead.