Although unstated in the question, here are my assumptions about the system's behavior.
- Deleting Parent1 also deletes the subtree beneath Parent1.
- Changes to Child1 will be lost because Parent1 no longer exists.
My answer is based on those assumptions. Ignore the rest of this answer if those assumptions are invalid.
In the scenario above, Admin1 and Admin2 have conflicting views of the true state of the hierarchy.
- Admin1 thinks Parent1 should exist because Child1 should exist. This is implied by Admin1 editing Child1.
- Admin2 thinks Child1 should not exist because Parent1 is no longer needed.
Assuming both admins have the same role and therefore the same permissions on the objects, neither admin is correct or one of them is wrong and about to make a mistake.
As with any design for handling errors, prevention of errors should precede handling errors.
Recommendation 1: Mark the parent to show there is a child in an edit state.
Hopefully, Admin2 will not attempt to delete Child1. This is not a strong recommendation because I've never seen this done well.
Recommendation 2: Do not allow deletion of the parent.
Most systems I'm familiar with (Windows, IDEs) do not allow deletion of a parent when a child is in use or force you to approve loss of the child and any unsaved work in the child. Those systems display a message saying something like 'You cannot delete this object because a child of this parent is being edited.'
Recommendation 3: Undo
If you allow deletion of Parent1 then you should expect Admin2 to be wrong in some cases and the action will need to be reversed. Reversal of 'marked for delete' should handle this situation.
Recommendation 4: A 'Your work has been lost, sort of' message for Admin1
If you allow deletion of Parent1, then Admin2 needs to know the changes to Child1 will have no effect on the hierarchy because Child1 has been marked for deletion. In other words, you need to tell them 'Thanks for all your hard work but Admin1 decided it was not necessary and, although we could have prevented you from wasting your time, we chose to let you keep going.' (That's written tongue in cheek but describes a potential outcome of allowing both Admin1 and Admin2 to keep working independently.)