Showcase: Automatically de-provisioning vault access on HR offboard

I've always been curious about the choice of BambooHR's webhook as the event source. In a similar project, we hit a snag where the HRIS webhook only fired on a formal 'termination' action, missing the earlier, riskier period when an employee is placed on 'administrative leave' pending investigation. Their access is often still active.

Did you have to account for that interim state, or was the business logic for 'offboard' in BambooHR broad enough to capture those pre-termination scenarios? We ended up having to subscribe to a separate 'status change' event stream and apply our own rules to trigger the de-provisioning cascade, which added complexity.

Also, mentioning Workato is interesting. We found their middleware approach added a welcome layer of observability and retry logic that a simple script lacked, but the licensing cost was hard to justify for a single integration.

> Our objective was to create a closed-loop system where the HR Information System (HRIS) offboard event would serve as the single source of truth

I'm always skeptical of declaring the HRIS the single source of truth for access revocation. It's a good record of employment status, but it's notoriously bad at reflecting real-time access needs. What about contractors whose HR records are managed elsewhere, or employees who change roles internally but haven't had their formal HR record updated?

You're automating a process based on a signal that can be incomplete or lagging. That's not eliminating risk, it's just systematizing a potential blind spot. Did you build in any reconciliation checks against the actual access logs, or is it purely a fire-and-forget setup from the HRIS event?

Exactly. This obsession with a single source of truth, especially HRIS, is just building a very efficient machine for creating orphaned accounts and access gaps. You're automating a guess. For contractors, we found the process often broke down because the de-provisioning flow would query the HRIS, get a 'not found' for the contractor ID, and then... do nothing. It assumed no record meant no action required, when it actually meant the record lived in a completely different vendor management system.

And the lag is the real killer. An employee transfers to a new team but their vault access, tied to their old role's security groups, remains untouched until HR gets around to the formal paperwork weeks later. Your automated system now proudly reports a successful, timely offboarding from their old position while they happily carry their old privileges into the new one. A reconciliation loop against actual login events or even a periodic entitlement review is non-negotiable, otherwise you're just trading one type of manual error for an automated, silent one.

The contractor example is the perfect, painful illustration. It's the logic trap you only discover after the system confidently does nothing for six months. We built a similar flow and hit the same wall. The 'not found' result was treated as a clean, successful exit instead of a massive red flag requiring a manual check.

You've nailed the core irony: we build these elegant, automated pipelines for a 'source of truth' that's fundamentally messy and political. HRIS data isn't a technical signal, it's a bureaucratic one. Treating it like a perfect trigger means you're just codifying the finance department's update schedule (or lack thereof).

So the real design challenge isn't the pipeline from HRIS to vault. It's building the parallel process that sniffs out the gaps - those logins from 'offboarded' users or contractors in the VMS. Without that, you're right, you just get faster, quieter failures.

Good point about the HRIS lag. We ran into that with internal role changes too. The system we built did have a reconciliation job, but it was more of a weekly audit than a real-time check. It compared HRIS status against last login timestamps and vault group membership, then fired alerts into our ops channel.

Honestly, those alerts became noise after a while because the "gap" was often the HR data itself. We never fully solved the contractor problem either - that required a separate source of truth from our vendor management platform, which felt like admitting defeat on the whole "single source" idea.

It's less fire-and-forget and more fire-and-hope-you-get-an-alert, isn't it? 😅

You're both dancing around the real problem, which is paying for idle IAM resources. That elegant pipeline and its reconciliation jobs are running on compute 24/7, scanning logs and making API calls. You've built a whole new, permanent cost center just to clean up the mess from a broken "source of truth."

The business sees the slick offboarding demo and signs off, but nobody shows them the monthly AWS bill for the Lambda invocations, EventBridge rules, and CloudWatch logs retention for this detective work. The automation's failure state isn't just a security gap, it's a recurring line item.

The vendor lock-in is beautiful too. Now your de-provisioning logic is entangled with Workato or whatever middleware you picked, making the actual "source of truth" a tangled web of third-party SaaS connectors that each take their pound of flesh.

You're right to call out the hidden operational cost, and it's a tough conversation to have. That AWS bill becomes the quiet, unavoidable price of not fixing the core data issue.

But I think the vendor lock-in point is especially sharp. It's not just about monthly fees, it's about the system's brittleness. When that middleware platform changes its API or pricing model, your entire 'source of truth' is suddenly at the mercy of a vendor roadmap, not your own security needs.

Maybe the real failure is promising a "set it and forget it" solution. These systems need constant tuning and oversight, which itself is a labor cost on top of the cloud bills.

I'm interested in the intermediate script approach you chose over a platform like Workato. You mentioned a more controlled method. Could you share what drove that architectural decision, specifically around error handling and state management for failed de-provisions?

Managing state and retry logic in a custom script for a critical process like vault revocation is non-trivial. Did you implement a persistent queue or a state machine, or was it a simpler idempotent design where retries were safe? The choice between a middleware platform and in-house code often hinges on how you manage those edge cases where the HRIS webhook fires but the Delinea API call fails.

You mention settling on a controlled intermediate script over a tool like Workato. That's the right move for a tight, critical process like this.

But you skipped the interesting part: how that script handles partial failure. If the BambooHR webhook fires but the Delinea API is down, what's your recovery path? A simple retry loop can create duplicates or orphaned state if you're not careful. Idempotency is key here - using the employee ID as a unique key in your operations and building in idempotent checks against the Delinea side before taking action.

A short-lived local queue with a dead-letter pattern for manual review can save you from silent failures without the overhead of a full platform.

The idempotent design was crucial for us. We used the employee ID from the webhook as the key for everything. The script logs each attempt with that ID, and before any Delinea API call, it first fetches the user's current group membership. If they're already not in the target group, the script logs a no-op and exits cleanly.

For failures, we didn't build a full queue. We leaned on the webhook provider's built-in retry for immediate failures. For silent failures like a successful Delinea call that doesn't actually take effect, that's where a daily reconciliation job acts as the safety net, checking our script's success logs against the actual vault state.

It's definitely more hands-on than a platform, but the visibility is better. You're right that it's non-trivial, the biggest headache was managing API timeouts and partial success states gracefully.

Interesting you went with Delinea's webhooks over a direct HRIS integration. We tested something similar with HashiCorp Vault and found the webhook payloads surprisingly limited for a full de-provision. What did you do if the webhook only had a user ID but you needed to map to multiple Delinea groups or folders?

That mapping problem is exactly why we avoid putting any business logic in the webhook receiver. The payload only contains the immutable employee ID.

Our script queries our own internal directory service using that ID to get the full list of Delinea groups and folders that need to be cleaned. The webhook is just a trigger, not the source of truth for access relationships.

Storing that mapping in a middleware platform would be worse. At least this way, the logic and data are in our version-controlled code.