Info about Permanently Deleted/Destroyed Work Item Azure DevOps

Question

I was wondering how to know who permanently deleted/destroyed work item in our Azure DevOps. We are 100% sure there was a Work Item, we even interacted with it, changing several properties of it. But several days later we noticed that we could not find it neither on the board nor Recycle Bin meaning that Work Item was permanently deleted/destroyed. Our team contains 10 people, is there an info/log saved into somewhere about actions like deleting/permanently removing work items from the board, we need to know what happened to that specific Work Item. There are also other Work Items on the board which are completely fine.

Answer 1

This answer probably won't solve the issue but hopefully it will move the investigation forward for you (and for the next person).

Azure DevOps (aka TFS) uses a database as a backing store. Historically it was commonly Microsoft SQL Server.

There is a work item record created in the database when a work item is created. A 'Delete' is a non-destructive or soft delete. It sets a value on the record and can be undone by a 'Restore'. A 'Destroy' (or 'Permanent Delete') is removing the record in the database. (See Remove, delete, or restore work items in Azure Boards.)

There is a security log that will record events like permanently deleting a team project but I don't think it covers work items.

There is a new-ish enhanced audit feature that has certain requirements and may not be available for you. Also, it would have had to have been enabled and configured before the work item was destroyed.

If this is an on-premise Azure DevOps Server and there is a replication/fail-over/recovery process for the database that uses journaling backups, you may be able to glean something from that.

If this is a cloud Azure DevOps Services instance and it is important enough, it may be worth opening a ticket with Microsoft to see if they can help in any way.

There are separate permissions for 'Destroy' and 'Delete' and users can be restricted from 'Destroy' and still be allowed to 'Delete'. In fact, the default permissions are that 'Contributors' can 'Delete' (and 'Restore') but cannot 'Destroy'. (See Default work tracking permissions & access.) If everyone on the team is an admin, that choice should be revisited.

An approach that some organizations follow is to restrict both 'Destroy' and 'Delete' and a work item that is no longer relevant is expected to be set to a 'Removed' status.