Table of Contents

How to handle elements in LOST+FOUND

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.

We recommend that you contact your Method Park by UL Solutions consultant to analyse the root causes of elements in LOST+FOUND.

All cases listed below are examples of this core problem.

1. LOST + FOUND after the release of a new valid version

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

Example:

→ 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:

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

2. LOST + FOUND while using modules

Case 2.1: Imported project data/guidance files

Example:

→ LOST+FOUND folder is created in the integrated process

Case 2.2: Local project data /guidance files

Project data is added locally to the integrated process for elements imported with a module. If those module elements are deleted during a module update or if the module is removed completely, the elements are moved to LOST+FOUND.

Case 2.3: Local sub-elements

If sub-elements are added locally to elements imported with a module in the integrated process, and those module elements are later deleted during a module update or if the module is removed completely, the sub-elements are moved to 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 from module B is deleted due to a module update or removal, the element from module A is moved to LOST+FOUND.

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

If a structural module is integrated with different versions, the version imported last may have some missing elements.

For example, V2 includes an element called FolderXYZ, which didn't exist in V1 but is used in Process 2. If Process 1 is updated or imported after Process 2, FolderXYZ will be 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 the process modules being integrated use the same version of the common elements module.

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:

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.