HRIS triggered account disable for employee on maternity leave. She lost access to the benefits portal. Now HR wants IT to "fix the process".
Posted by AudienceOwn3845@reddit | sysadmin | View on Reddit | 92 comments
Workday flagged an employee as inactive when her leave started. That status change fed into our Entra provisioning workflow and disabled her account within 48 hours. Standard automation, works fine for actual terminations.
Except she wasn't terminated. She was on maternity leave. And the benefits portal she needed to manage her insurance during leave is behind SSO. Disabled account, can't authenticate, can't access anything.
HR found out when she called them directly. They were not happy. Neither was legal when they got looped in about potential benefits access implications.
We re-enabled the account manually within a few hours but now I'm sitting in meetings where HR wants a "solution" and I'm trying to explain that the problem is that Workday uses the same status field for leave and termination in a way that our provisioning logic can't distinguish cleanly without custom attribute mapping we never built.
The obvious fix is to add a leave type check before any disable action triggers. We're working on that. But what I actually want to know is how other people have handled the edge cases here like specifically accounts that need to stay partially active during leave. Full disable is wrong. Full enable with normal access is also arguably wrong from a security standpoint since they're not working. Is anyone doing a "leave mode" where you scope access down to just HR/benefits apps and strip everything else temporarily?
Curious if there's a pattern here that doesn't require us rebuilding the whole provisioning workflow from scratch.
NoCream2189@reddit
while i’m sure you will get solution - i would like to just point out that people going on maternity or paternity leave - is not edge case. This should be something built-in to either the workday system or you implementation. I’m kinda surprised this was overlooked
Automatic_Rock_2685@reddit
IDK about this post. Weird account history on OP. Every post on reddit is fucking fishy now it's insane.
jhhnmy@reddit
OP has responded to posts in r/teenagers, says they want a girlfriend in one post, mentions their father-in-law in another... It also just reads like AI.
ZCEyPFOYr0MWyHDQJZO4@reddit
Possibly AI. Probably just posts to farm engagement so they can sell the account.
OneSeaworthiness7768@reddit
If you view the posts they hide (on old.reddit), it’s even weirder. They’re a walking tour guide in Barcelona, Vienna, Istanbul, a hiking tour guide, then an underwater photography guide, they run the family street food tour business, they run a 40-employee agency, it’s a walking tour business, then it’s a bus tour business, their father passed away but also they’re watching their parents struggle with their business…
Everything about this is fake af.
xSecondSalt@reddit
These dang bots lol never ends
hasthisusernamegone@reddit
This is absolutely something that would have been caught at design stage if they'd just spent five minutes going through the various ways people use the platform.
Either the implementation was utterly botched, or this is engagement bait.
xSecondSalt@reddit
Right? My first thought is you guys don’t have a common setup for 12 week leaves ?? This is not an uncommon scenario for us. Perhaps at their size they don’t have to grant FMLA etc. I’m
InflateMyProstate@reddit
As someone else mentioned, I feel like a custom attribute would be the saving grace here.
However, I did want to discuss if it makes sense to have your HRIS locked behind SSO tied to their company user account? Aren’t there cases where a person may offboard in October, but need to log into the HRIS the following April and retrieve prior year W2 information? Or to access previous pay stub information maybe for loans or record keeping? At every org I’ve been at, the HRIS login was a separate identity managed by the provider, not tied to their company account via SSO. I could be wrong here, but just thinking out loud.
rem1473@reddit
Honest question, what happens if they're on COBRA for 3 years?
chesser45@reddit
I assume they get whatever they want as they have the ear of the UK defence complex? /s
chesser45@reddit
For us in a similar position to OP we have an off boarding process in WD that takes the personal email of the user and allows that for offboarded access. As long as you are an active user or on leave you need SSO (as long as it’s not one of those on leave forever things).
wbqqq@reddit
This. It is a bigger identity and authorisation control design.
A person has multiple identities as an employee, and RBAC doesn’t really cover all the cases well: - as a human with access to job application data - as a human to whom a job offer has been made - as an employee generically in an organisation - as an employee with a specific role in the organisation - as a human who is receiving money/benefits (or has done)
Broadly, the simplest approach is to manage 2 linked identities - the human outside the corporate wall (identified by SSN, personal email, personal phone) and the employee inside the corporate wall (identified by employee #, corporate email) and then associating/using the relevant systems with the relevant identity.
Then, go through the various scenarios and determine which identity should be used. Generally, the human identity should be used for anything that exists before and after (payroll, some HR, benefits, pension) and the employee use RBAC and have the automated disabling.
Another question is if an employee terminates, and then rejoins, is the existing employee identity reused? Or a new one created? The human identity is obviously singular.
chesser45@reddit
Thanks for expanding on my comparatively lazy response! Basically what I would have said if I were you and had the energy to say it.
Sinsilenc@reddit
We have it where staff can sign in with sso or their personal login once.
ChadTheLizardKing@reddit
We require HR to maintain standalone accounts for their HRIS system for just this purpose. There are so many reasons that someone is "not an active employee" but would still need access to benefits/pay/etc..
DC_Geoff@reddit
Yep this is my thought too. Where I work we've had convos the past few years about what all makes sense to bring into our SSO, and every time HR or benefits gets discussed, we always agree that terminated staff and people on leave need access so we can't have it behind SSO. Now, that does mean that we have to have separate, strong MFA for that system since it's not tied to our main Entra accounts.
Magic_Neil@reddit
We’ve seen it where employees on leave (or furlough) have their accounts intentionally disabled so they weren’t prompted by someone to login while they’re not allowed to be working*. I love having SSO for portals, but maybe it makes more sense to have an alias with a static login for cases like this, or after someone is terminated for all the reasons you mentioned.
*whether it made sense or not our big brother was serious about compliance and if you were on leave they made sure of it.
RickRussellTX@reddit
I struggle to believe that Workday doesn’t have a status or substatus to identify employees on leave.
2 questions: are you sure that substatus does not exist, or is it the case that your API to Workday is limited or incomplete? And, are we sure that HR selected the correct statuses in Workday? Is there a possibility that they coded it as a standard off boarding termination, but they should have selected something else?
tristand666@reddit
We have an OU for leave that our offboarding and cleanup scripts ignore. Just move the account into there. We also have 60-90 day period before the scripts delete the account so we can revive it if needed in an edge case.
pdp10@reddit
The Platonic ideal is where I.T. doesn't have any privs on the production HRIS system for confidentiality reasons. Ideally, I.T. should be a stakeholder with advisory input, mostly about the linking of systems through protocols and APIs.
Then HR is empowered to go to hell in their own way, with their own appadmins, consultants, SaaS, whatever.
You have to plan for this from the start, just like you have to have a user story for changing user preferred names or legal names. One would think that a big, mature, off-the-shelf package like Workday would default to all of this. Do your records of the project show anything about that?
A similar status is pre-employment. HRIS gives the user an account (Authentication, 'authn')with MFA and lets them start filling out paperwork, without that user having any Authorization ('authz') do to anything whatsoever except HR. Same with terminations, who need their HR account to work on COBRA or exit agreements.
These are all normal HRIS workflows that every HRIS specialization should be thoroughly familiar with.
Gi1rim@reddit
Lol, only in the us "maternity leave" is a edge case
OneSeaworthiness7768@reddit
It’s not, even here. And I don’t think the OP is from the US anyway. The account post history (the ones that are hidden) is sus as hell. I think there’s next to zero chance they work in IT.
Automatic_Rock_2685@reddit
Not even here! But I get the sentiment. OP / their dept messed up, this wouldn't be standard anywhere.
OneSeaworthiness7768@reddit
Our system triggers account disable requests on the employment end date field. LOA’s are handled differently, they don’t get an employment end date in that same field.
HappipantsHappiness@reddit
I'd be mad too. This is a very typical scenario and shouldn't be a surprise under normal circumstances.
Bradddtheimpaler@reddit
I wouldn’t have set up the benefits stuff behind SSO. Do users need to access that stuff before they start? I-9’s, W2, etc.? I wouldn’t want active user accounts for people who haven’t even started working yet. I would have tried to just keep it out of the IT silo altogether so it is just HR’s problem.
Newdles@reddit
Standard practice is to not stick anything with personal access/info and/or personal finance behind SSO if it can't support multiple auth methods. Don't put benefits and your HR tool behind SSO unless service owners can flag an account to not enforce SSO per user.
CeC-P@reddit
See, this is why you have the programmer and/or autistic folks design the system. We're like AI when it comes to finding logical flow errors in large processes.
33nljdrk00@reddit
This is a process problem pretending to be a technical problem. The automation did exactly what it was supposed to do. The bug is in how Workday classifies "on leave" and which of those classifications fire which downstream workflows. Fixing it in Entra is the wrong layer - you'll just be playing whack-a-mole every time HR changes a leave code. Which they will.
The shortest path to a real fix is a 30-minute meeting with whoever owns Workday config, your Entra admin, and whoever runs benefits. Specifically: map every leave type in Workday (maternity, paternity, medical, military, bereavement, etc.) to whether the person should retain access to email, benefits portal, building access, etc. Most orgs have never written that table down and then act surprised when the automation picks one for them.
When HR says "fix the process" - the professional reply is "happy to! Who owns the mapping, and who approves the change?" If the answer is "you", you have a scope problem, not a process problem.
waxwayne@reddit
LOA aka Leave of absence field.
thirsty_zymurgist@reddit
Custom attribute. It's basically the only way we have figured out how to do it. It's not the only one we use either. We sync with our ERP and there are a few more internal key:values that get added to accounts along with status.
TheGreatAutismo__@reddit
The actual fix is voting for candidates who will guarantee universal healthcare that isn't tied to your workplace, but y'all don't want to talk about that.
Ahnteis@reddit
Sure, but we're in r/sysadmin
Droid126@reddit
Users signing into benefits/payroll with accounts tied to their employer seems like the main mistake here.
I have never worked at a place where we used our corporate email to log into payroll/benefits portal.
I was always taught not to do that. Personal emails only. We've been with ADP, Paychex, Paycom, Paycor, the orange rabbit one whose name escapes me. We've always set them up separately from our auth infrastructure.
Jemikwa@reddit
Does your HRIS have a way to change how someone logs into it? The past 3 companies I've been at, HR changes the primary login to use an employee personal email when they leave. This bypasses SSO and lets them use username and password. Former employees need to access W2s and other forms after they're gone, so mandating SSO even for those isn't a good workflow.
This logic could be applied to temporary leave people, but it'd be a bit much if it's only for a few months at most.
Telamar@reddit
Auto-generated username, first IT-related post, formatted nothing like other posts from the user, and finishes with a bit of engagement bait. More than a bit suspicious on whether a human is behind this, and a few AI detectors I ran it through tend to agree.
mythlabb@reddit
Damn, good find.
beagle_bathouse@reddit
Parental leave is BAU not edge case.
nailzy@reddit
Our firm uses conditional access policies for a myriad of sites and it’s all controlled by AD groups. So when a user is on long term sock or long term absence, they are added into that group which prevents them being able to access anything the company doesn’t want them to, whilst retaining access to HR, benefits etc.
beagle_bathouse@reddit
This is the way. Just make sure your CAPs are well managed and don't become spaghetti, also test them for holes with something like https://github.com/Jhope188/ca-policy-analyzer
ljr55555@reddit
That's what we do too. From what legal/HR explained to me, when leave is covered by long term disability, the individual cannot be provided access to work. Because the point of disability insurance is to cover pay while unable to work. If you are able to log in and quick check your email or something ... Then insurance wonders why they are paying out.
Except! Doing the disability paperwork. And you just had a life change event and need to enroll that baby on your insurance plan so need the benefit enrollment portal. And you might want to adjust your 401k withholding, which is personal finance stuff and not work. And. There was a seemingly endless list of not-work work sites people on leave still needed to use.
No magic answer. Options:
HR reps do it for people. They didn't like that answer, but it was possible.
Use site-specific logins for some things. The retirement and 401k are good examples here. A lot of users are former employees. It made more sense to have the provider manage accounts. Dude who left a decade ago can still log into his 401k, and so can the person out on medical leave.
Add a "leave" state which had to be added to all of our SSO configs. "Log in unless a member of group PeopleOnLeave", basically. There's a special list of apps where that has not been added to the sso app config, and any exception goes through HR and legal to make sure everyone is OK with employees on leave using it. Pain to set up, but ongoing maintenance isn't bad. Mostly they forget about it for a new app, call with a high priority issue because someone is unable to log in for "no reason" so obviously all of SSO is jacked up.
DudeOnWork@reddit
This!
Add SSO via application in AAD, assign a group (if needed), manage group membership via scripts, based on custom attributes.
I-am-IT@reddit
Disable HRIS… process solved
sleepyzealott@reddit
Following with some interest. Haven't run into this problem yet, but keen to build towards/adopt a pattern if it'll avoid the problem in future.
My gutt says there's got to be a better option than overhauling security group membership.. be that with filters or middleware that saves membership state before reinstating when required. Shudder.
Maybe a simple CA that limits access is the lazy/smart middleground?
mythlabb@reddit
That’s all we do. CA policy that blocks access to email, Teams, Salesforce, and VPN, but not HR or Payroll apps/sites, if you’re in the EmployeeLeave group. Easy to do if they’re all Entra-authenticated. We probably could/should be doing more but nobody’s complained yet.
We don’t block local login (AD, not Entra) since you have to be physically in the building at that point and disabling the AD object triggers all sorts of workflows. But we are a small org who would know if someone walks in the door and badges in. For a large org that wouldn’t really work.
420GB@reddit
Our HRIS differentiates between terminated and on leave.
Being on leave doesn't trigger the off-boarding processes, but the account is still subject to be deactivated due to prolonged inactivity.
ccsrpsw@reddit
Bigger question - why is the benefits portal using SSO?
People who dont have AD/Entra accounts may need to access it - new hires, termed employees (RIF or otherwise), vendors (you give all vendors AD accounts?) - and so on?
I get the desire to do "everything" via SSO, but our Workday, ADP and a couple of other systems are absolutely not SSO because of these very reasons. Also our Workday has about 5 "LOA" type situations in addition to termination - and 1/2 of them dont disable the AD account depending on the type of leave and where the employee is in the world and employee type.
Sounds like HR messed up their implementation.
SupraCollider@reddit
Locking your benefits portal behind corporate network account SSO is absolutely a terrible maneuver by whoever made that decision. Even if you support SSO login it would still need the ability to have a personal email for communication and logging in without the corporate account. some random on a helpdesk can prevent someone from getting their benefits by locking their account and that is some amateur hour legal and regulatory turmoil to build in to your platform.
Automatic_Rock_2685@reddit
Edge cases lmao
TimmyTheHellraiser@reddit
Benefits portal shouldn't be behind SSO, as many others have said.
Civil_Inspection579@reddit
Yeah this is a classic identity lifecycle gap. Treating leave the same as termination will always break something. A “leave mode” with reduced access is usually the right middle ground.
highdiver_2000@reddit
Way back in GM, mainframe accounts are auto delete with 2 months inactivity.
Some staff take a 2 month long summer vacation.
ExceptionEX@reddit
We don't lock accounts that are on leave, there are too many instances where someone who is on leave may need to communicate with management. People socially interact, in the case of babies, sending pictures is rather common, as are updates to management, extension request, Company wide notifications, and related information (benefit renewals, changes to events, etc...) still need to be sent, we don't want that sort of information broadcast to either users personal email accounts or phones vs text messaging.
I don't see how closing off access to these accounts significantly increases security, because we employ a later approach at access already, they have to connect from specific areas, know password, pass phishing resistant MFA, etc... (arguably people who are away are probably more secure than those who aren't) and we don't want to be involved in when people are taking short amounts of leave for whatever reason isn't IT's business.
OstrobogulousIntent@reddit
TL;DR: this seems common in many companies
Never hit this as an admin, but a co worker of mine got disabled when on paternity leave and had much the same issue. Disabled account meant he could not get to ANYTHING including all the insurance and leave management tools - so when he was wanting to end his leave about a week early (his wife was doing much better than anticipated and he was going stir crazy not working) he couldn't.
Ihaveasmallwang@reddit
It’s not that hard to grab the status of the employee before performing any actions. HR is right in this scenario that you need to fix the process, even if it requires custom stuff. It is not uncommon in the IAM world to need to customize stuff.
kamomil@reddit
When I went on maternity leave, I was told to log in to my email every 3 months or so to keep my account active. I live in Canada and had 12 months leave
alwayz@reddit
No comment on this, but we just switched from Oracle HCM to Workday and Workday is much more restrictive on what you're able to do with the records.
mullexwing@reddit
We went through something similar and setup a specific OU in active directory that had different automatic responses.
Elensea@reddit
Our hris is A,L,T for statuses in the api call. Active leave and terminate.
klauskervin@reddit
Do companies not trust the employees they hire? I don't understand the logic of someone on maternity leave being cut out of everything when they are going to return to work eventually and may have to collaborate with coworkers while on leave.
iceph03nix@reddit
This feels like one of those things where the integration checks for active to enable/disable because someone didn't think about there being other states like LOA.
It does make me happy that all our HR stuff is completely outside IT responsibility. And no SSO for benefits stuff since not every employee has an Entra or AD account
Morkai@reddit
The custom attribute sounds like the way to go.
If CA15 = $true, keep the account active, but remove from all (except those for accessing HR) security groups/DLs (assuming you have other applications/services/platforms provisioned using Entra groups)
Obviously keep a record of what they were removed from, so they can be added back after they return from leave, then blank that attribute.
llDemonll@reddit
We use actual HRIS status in a custom attribute. Our processes check status.
Our HRIS isn’t behind SSO though.
agingnerds@reddit
We have recently did this and its a game changer. It helps with all dynamic groups and makes AD scripting so much easier. Its my favorite change we have made in years.
jeffrey_f@reddit
Look at what triggers the automation to remove the employee. I've seen HR put in the wrong status and the system immediately killed their access. Make sure that HR isn't to blame before you go chasing that rabbit.
ThomasTrain87@reddit
We are in the IT side and we are using workday and don’t have this issue. Folks on leave in our system don’t get flagged as inactive or terminated, they maintain a status of active.
What gets triggered on our side is stale access if they haven’t logged in for 60/90/120 days but we don’t automatically delete the account, only disable it.
We are highly regulated so disablement of stale accounts is a requirement, even if on leave and our standard procedure is to reenable the account then have the user login to reset that clock.
I’d look to tweak the attributes you are using that trigger automatic disablement to be a true termination event, not just going inactive.
Ok_Wasabi8793@reddit
For us in workday for leaves and for people who have left to get T4s they are given an account with their personal email that isn’t behind our SSO.
gzr4dr@reddit
This is how we do it, too. WorkDay with SSO for all users and HR provides email/password access for accounts that are disabled, like in OPs scenario.
ManLikeMeee@reddit
Shouldn't the question be, why HR had marked it as a leaver?
Maybe because I'm in the UK it's different here, but we wouldn't have them marked as left or anything.
english-23@reddit
Someone on leave is not technically supposed to be working so their account should be disabled for working but the problem like in OP's case is they need access to benefits when they're out
Tenroh_@reddit
In the US at places I've worked if you are on an extended leave it's pretty common to have disabled access so you can't actually work or be bothered by it and focus on leave. Not sure if it is written in to the FMLA law or somewhere else. Also a small security aspect with disabling an account you know shouldn't be accessing anything for an extended period of time.
A less than 2 week leave would not always trigger automatic disabling at places I've worked.
jeroen-79@reddit
There is a difference between a leaver and someone on leave.
If that difference has never been explored and implemented and not everyone has a full understanding of what some setting does then you get cases where HR doesn't want someone on leave to have access to work systems and then sets them to disabled which then locks the user out of the employee portal as well.
International-Wind22@reddit
All benefits systems are not behind company SSO. That is a recipe for disaster.
Also all contracts, payslips, anything that is not fully company property goes directly to personal accounts
sir-draknor@reddit
You need to set an access policy in Workday to allow employees on leave to login via user/pass (and ideally MFA), not SSO. Same as you probably have setup for term’d employees.
The “better” solution is to figure out how to differentiate it in Entra based on some custom attributes, but what I just wrote is the fastest solution to implement. Your Workday security admin can have it setup in an afternoon.
St_Admin@reddit
We had the same issue and made HR adjust their BP not to mark people on leave as inactive
My0therAcc0unt9@reddit
Maybe RBAC is the answer. We haven’t implemented this yet, but I’m considering an “employee” RBAC role, with limited access, in addition to your specific job role. Access to things everyone needs gets inherited through the employee role, everything else through your job role. When on leave your account gets removed from the job role and thereby loses access to everything specific to the job role, but maintains the more generic employee access.
I’d appreciate feedback on this approach because it’s something I’m considering doing and would rather hear about perceived issues with it as early in the process as possible.
AtarukA@reddit
If it's private data that may need to be accessed by outsider to the company such as payment or HR infos, it goes on a private email given by the user. Not a company account as it shouldn't be information handled by the company, only information fed by the company.
Siritosan@reddit
I would like to ask if this has been brought up to Workday support. If you are paying for it, use it amd find out bet they have cases like this and may offer a solution
fnordhole@reddit
That isn't an edge case.
Palmovnik@reddit
To me the obvious solution is to not mix work account with benefit accounts.
HR should be managing benefits accounts alone, without intervention from IT, same if you are sending payroll via app. No connection to Entra, let HR handle it.
brokenpipe@reddit
I often find myself saying this is a HR or people management problem when HR/Legal wants to enforce a process via IT that should clearly be theirs to own.
However in this case, this is absolutely an IT problem. You designed the system incorrectly — too harshly in fact — and now you’re rightfully being told to flipping fix it. There are numerous ways to fix this and it all starts with validating HLDs like this with the vendors you work with. This pretty common use case would’ve caught this pretty quickly. Get a Workday consultant and Microsoft consultant involved so you can demonstrate and show to HR, Legal, et all that you’re taking the matters seriously and will be coming up with a permanent fix through this investment.
gumbrilla@reddit
OK, I take care, In my jurisdiction, security might have an issue with accounts remaining open while someone is on leave, but they can get wrecked as its nothing compared to the legal liability if you block someone on mat leave from keeping up with things on their own choosing, so email Teams stuff like that.
The big things though is these are not your decisions as IT. Absolutely Not. These belong to HR. They provide the business requirements, and own the process.
BitsNBytes10101@reddit
We just did a Workday implementation and solved it this way:
All employed users stay enabled.
All terminations get disabled and get moved to an OU that doesn’t sync with Entra.
All leaves (LOA, FMLA, etc.) get put in a conditional access group that denies access to everything except Workday. On their return BP in Workday they get ripped from the group in the morning and they can access all systems.
mrlinkwii@reddit
question why is some on maternity leave even contacting/ using company systems when they legally in most countries ahould be anywhere near them
igiveupmakinganame@reddit
I don’t put HRIS system behind SSO for regular employees
Anthropic_Principles@reddit
I went through this in my last org. with the added wrinkle of trying to ensure compliance with the requirements to manage 'Keep in touch' days. - Need to be able to enable system access on demand to facilitate keep in touch days, need to be able to track number of days taken to use as a possible trigger for end of parental leave.
Finished up with a custom field in HRIS to record extended leave type and managed entitlements based on that.
Access to HRIS vis SSO.
Access to payroll/benefits was via the employees personal ID identity.
rfc968@reddit
Can you allow a different authentication method or select users?
We do this with ours. Once an employee leaves or is on leave, we swap the user to their personal e-mail address. Users need to keep that up to date for obvious reasons. As they no longer log in with a work domain email SSO no longer applies, but their newly set password.
Pristine_Curve@reddit
It's not as simple as going from two employee states [enabled/disabled] to three states [enabled/leave/disabled]. The problem with 'partial' access states like this is that there is never agreement on what exactly the limitations should be. You'll be fighting edge cases the entire time.
Unless you are a very large organization, it's probably not worth automating every edge case.
jeroen-79@reddit
You could go to four states: Enabled, Leave, Disabled, Manual.
In the Leave state you remove what they need to work but keep what they need to be an employee.
If they briefly need to do something that is work then a solution would be to return from leave, do the work and go back to leave.
If they are temporary not doing some work while still doing other work then you can leave them enabled and use the normal authorization process to remove and later readd what they need and not need during this period.
In the Manual state you can do whatever you want to address whatever special situation you need to address.
This would be a non-standard change where you workout what you adjust and how you roll it back later.
Dankitysoup@reddit
Our benefits portal is not SSO for this reason. Users need to access it before onboarding, while on leave, and after termination sometimes.
arbedub@reddit
CA sounds like a sensible approach - where all the 'business' apps require an enrolled device/device condition and lower security apps do not, just MFA.
Then when they are in mat/pat just disable the device.