Expand my Community achievements bar.

Do not count / update login specific fields, if "Log in as" was used

Avatar

Level 9

7/2/24

Description - If an admin uses the Log in as function to login as a specific user, this action should not update the fields lastLoginDate and loginCount.

Why is this feature important to you - We need a way to monitor, when a user really logged in to the system. Therefore the fields lastLoginDate and loginCount should be used. To test / double check specific system settings (e.g. object sharing) our admin team often uses the Log in as functionality. Unfortunately this updates the mentioned fields lastLoginDate and loginCount. As far as I found out, this update seems to only be done once a day. So, if you login as another user multiple times on the same day, the loginCount is not increased.

How would you like the feature to work - As there is also an audit for login sessions under the endpoint AUDS, the fields in the USER entry should only be updated, if someone really logged into the account using the corresponding credentials.

Current Behaviour - The fields lastLoginDate and loginCount are always updated, regardless of wether it was a "real" login or an impersonation by an admin.

2 Comments

Avatar

Level 8

7/2/24

The one place you can get some clue as to this behavior is the Audit Log in setup. The Login Attempt records are true user logins and will not reflect an admin impersonation. Unfortunately they also reflect limited data, so it's not a long-term solution.

 

In general I agree though, the audit trail for a user should not be updated when an admin takes an action like that. I had an external user account stay open WAY longer than it should before I figured that quirk out, I just happened to have been persistently picking his account in feature demos.