Recently, I tried to delete a user from a Dynamics NAV 2013 database but got an unexpected error message: “The user cannot be deleted because the user has been logged on to the system. You must set the user’s state to Disabled”.
My first thought was that the user was logged on into the database at that very moment, and that NAV was preventing me from deleting an user with an active session. But when looking into the session list it appeared that the user did not have an active session.
Next thought was that NAV asked me to prevent the user to log in by setting the user state to Disabled. But that proved to be wrong:
So what to do? Luckily, one of my colleagues knew the trick: delete the user personalization.
And yes, after deleting the record for the user from this list, I was able to delete the user record.
This personalization record is created automatically when a user logs in the first time. It is updated each time the user exits the application with the latest used language and company the user was logged in to. So NAV interprets the existence of this record as ‘the user is active’ and prevents you from deleting the user. Not a very informative message, and in my opinion not a very nice design either.
But now you know how work around this message!
– UPDATE –
After I wrote this post, I got an email from Microsoft with an explanation that this behavior is by design. For audit reasons it should not be possible to delete a user, who has performed a transaction in the database. Because a user who has ever logged in, has a record in the User Personalization table, they choose to test this table. So the error message must read: “The user cannot be deleted because the user has probably performed a transaction in the system. You must set the user’s state to Disabled”.
I have suggested to check the G/L Entry table rather then the User Personalization table. Probably more tables are needed, I don’t know, I’m not an auditor. Anyway, if you are sure that the user hasn’t performed any important transactions, feel free to use the described workaround. If you are not sure, or want to save the user because of auditing reasons, just disable the user.