Answer
Not with an ordinary event action alone — an event action executes with the current end user's own database permissions, and virtually no end user has the direct database access needed to deactivate any user account, even their own. Achieving this safely requires a small custom PL/SQL wrapper package, deliberately granted EXECUTE to a broad end-user permission set, that only ever deactivates the currently logged-in session's own user (never an arbitrary target) and explicitly excludes the application owner and other system accounts from ever being deactivated by it — the event action then calls that narrowly-scoped wrapper rather than any general user-management API directly. Deactivating a user is disruptive everywhere they work, requiring IT intervention to reactivate them even for an accidental trigger, so this kind of automation needs careful, deliberate guardrails rather than a broad or reversible-feeling action.