Idea ID: 2685705

Recycle Bin/ Archive feature in ALM Octane

Status : Accepted
over 1 year ago


Present Situation:

Scenario: 1st

If a user deletes an entity (e.g. Requirement, TestCase, Epic, User Story, etc.) then the entity is immediately deleted in the ALM database.

It's and not a good idea to restore the whole database because we can lose data.

Scenario: 2nd 

Admin wants to archive and hide old entity (e.g old Test cases, Epic, etc.), it's not possible.


It's good to have a Recycle bin  feature before to  final delete

It's good to have entity Archive feature.




  • So far we are not using that heavily Octane, but we plan to replace with Octane, and in we have around 20.000 active users in SiteAdmin, whereas over the last 8 years we deleted additional 63.000 users (because we don't want to have > 80.000 users where 75% of them is deactivated). In it is not an issue to recreate an user, because in all entities (like Defects, TestCases, Requirements) the user-id is stored as text, therefore the user can still filter/group/search for the old entities.

    Whereas in Octane it is stored as numeric ID. But in the moment we recreate the user again it is creating a new user ID. As a result you will see in e.g. Defect module entities e.g. created by same name, but internaly stored for two different user ID. Therefore filter/group/search will find only for new user ID.

    And unfortunatelly it happens in such a big organization that especially external colleagues leave the company, and 6 month later they are back.

    As mentioned, so far this is not an issue for us, but maybe it will become an issue, just wanted to bring this up here as a discussion point

  • If you choose to delete an item, it cannot be reactivated after.

    for the option to reactivate you should select the Deactivate functionality (for users, list items, releases etc) and not the delete option.

    in GDPR mode for example, as part of the right to be forgotten, if you delete a user, all the user data is completely deleted from the system. 

    therefore - the recommended flow is first to deactivate an item, and only after you make sure it will no longer be needed, use the delete option.

    hope that clarifies,





  • Makes definitely sense to implement this for normal entities like epic, story, feature, defect, ....

    Within the customization area it is already implemented in a way that e.g. Users, Phases, Fields, Listboxes are not physically deleted. They just change the internal ACTIVITY_LEVEL to 2 (which means deleted from a GUI perspective). But I have not found a way yet how to 'reactivate' a user after he was deleted. The system will create a new user with new ID

  • Indeed a valid request.
    We have the Recycle bin functionality on our backlog, though no planned delivery yet.

  • One nice change could since a test can be set to obsolete, default all searches to hide obsolete tests/tasks so there is less to search through. Would just change the process for tests, but that's one way we currently help search through our tests.