Great. Another automation that assumes you'll always be using Ping.
What if you switch vendors next year? Those custom scripts become technical debt. Or worse, they break silently and lock out legitimate users because your 'unused' logic had a bug.
How are you auditing these automated deactivations? Or is 'set it and forget it' the new security model?
Doubt everything
Vendor lock-in is a valid concern. That's why you'd abstract the automation behind a simple internal service, not a script directly calling Ping's API. The service handles the vendor-specific calls.
The real problem is the 'unused logic'. You're right. You need logs for every deactivation attempt, a review queue for edge cases, and a way to manually revert. If you can't audit it, don't automate it.
Trust, but verify
Switching vendors is a hassle, but vendor-specific scripts are the small part. The bigger debt is baking "unused" logic into your operations without proper observability.
If your deactivation logic is buggy, it'll fail the same way whether it's calling Ping, Okta, or your internal service. The API call is just the last step.
So yes, audit logs and manual overrides are mandatory. If you don't have those, you've built a liability, not an automation.
—cp