Today, if a user is removed from a tenant, all "assigned" for that user is reset to "unassigned" regardless of past or current, regardless of state. This complicates root cause analysis because all past completed tasks and stories assigned to that user are "unassigned", there is no way to know who did the work. Presently we are only talking about months of history, if you've been in the Beta - potentially we could be talking about years of history.
- All assigned tasks/stories in past sprints/releases and all current tasks/stories in 'Complete' state should retain 'Assigned' value even if the user is either deactivated or removed from the tenant
- Open tasks/stories in the current and future sprints should be set to "unassigned" as a way of notifying the team that someone else needs to do this work
I would like to share in a little more details the behavior around users status in Agile Manager and how historical data is handled:
A user in Agile Manager can be either in status Active or Inactive. A user in status Active can logon to Agile Manager and consumes an Agile Manager license. A user in status Inactive cannot logon to Agile Manager and does not consume an Agile Manager license.
Both Active and Inactive users are considered "Included users" in the Agile Manager project. By Included user we mean a user to whom entities such as user stories and defects can be assigned. These assignments will be saved even if the user status is changed from Active to Inactive and vice versa.
When a user is removed from an Agile Manager project, it means that the user along with all the evidence for the user, such as historical assignments, are removed from the Agile Manager project.
I therefore highly recommend to remove users from Agile Manager only in cases that a user was added by mistake and never used Agile Manager, and to use the Inactive status for all the other use cases, such as: a user retirement, or a user that leaves for a long vacation.
In general I agree - here's my concern. For users with login issues (and we've had a few recently), where the usual change password, etc. does not work, that user has been removed from SaaS and re-added. In a recent case, that action corrected the user access issue. It also deleted ALL of the user's assigned history. If this were to happen for a user with years of history, it would certainly complicate tasks like root cause analysis.
If the need to remove and re-add a user were extremely rare, then what you described would work. Today, though, it seems to be necessary and so would impact production projects when it occurs.