Managing SSO Logins (Reuse issue w/kickouts)

[cmakai]

For those companies who are currently using SSO (Single Sign On), how do you manage your Login IDs? We are dealing with an issue where our IT system will randomly generate a login for a User and unfortunately it also "recycles" these logins. I am running into kickouts for the following reasons: 1) The associate came in with a hire date, was assigned an ID but did not complete I-9 paperwork or something happens to change their start date. Workday terms them out which causes the previously assigned login which already came into Concur to be re-assigned to another user. 2) An associate is terminated so their login is reassigned to another user. Because of these two issues, I receive daily kickouts.

I've learned that we cannot delete users (even if we know they've never had expenses) and there's no "purging", so I'm trying to come up with a solution. We've gone to IT and they cannot change their process, so it's up to us to solve this. The only thing I can think of is possibly looking into a change in the way we load associates. Right now, I believe our system is looking for a Start date, then it loads the associate, but maybe there's a better way?

Has anyone dealt with these issues? Does anyone have any suggestions? One solution I was given was to change the term's login ID, which I've already been doing - but because we are a retail industry, many of our associates are seasonal and get rehired, so that's not a good solution for us.

[Mass]

Hi, we also have issues where our IT recycle email addresses from time to time even though this is bad practice.

Our user maintenance is handled by integration, so to get around it we amend the email address at the point of termination.

eg. If our user Login ID was userabcd@burlington.com with an employee ID of 012345, we would amend the email address to read userabcd012345@burlington.com when terminating as this keeps it unique.

[cmakai]

Thank you. This still doesn't solve the issue of if 012345 gets rehired. They will kick-out then, but it does solve the issue on the front end.

How are you creating this "amendment"? Do you do a weekly file import or is this something imbedded in your daily (I'm assuming you have a daily) employee import file (300 records)?

[KevinD]

@cmakai and @Mass you may notice small changes to each of your posts. We do not recommend posting personal information here on Community. I deleted @cmakai's username and changed @Mass posts to not contain the actual username.

I am not sure what solution you will find to the issue you are having since your IT system is the one generating the user IDs. I don't believe the original system design was for user IDs to get randomly generated by a third-party system. Is it possible for the IT system to use some other piece of data to recognize that a user is being rehired and to also also automatically amend user IDs at the time of the profile being deactivated?

[cmakai]

When the question was posed to IT, I got the feeling since we are SSO and the internal system they utilize for generating these loginID's is something they've been using for awhile, that they would much prefer a workaround on our side than to make a change on their side. This is why I wondered how others handled their SSO logins. Prior to SSO we used associate IDs which were no problem at all - every one was individual.  But because the login is now tied to SSO it's the one they use for every other system the company has.  I always think "I can't be the only one with this issue" but maybe everyone else has a more advanced system for generating those IDs.