The problem
Contractor accounts are easy to create and easy to forget. When the engagement ends, the account often stays active because nobody owns the cleanup, leaving access open well past the contract.
What AscendCore does
A requester provides the contractor's name, email, end date, and any starting groups in Slack or Teams. An approver sees exactly who gets access, which groups, and until when. On approval AscendCore re-checks that no account already exists for that email (refusing on any uncertainty rather than creating blind), creates the Okta account (the contractor receives an activation email), and adds each listed group independently, so one bad group name never loses the account or the other groups. It then arms the end date: a recurring sweep suspends sign-in automatically at the end of the end date (reversible from the Okta console). The arming is honest by design: if the automatic suspension cannot be scheduled, the approval card says the account is live and needs a manual suspension rather than implying the expiry is set. The creation, each group outcome, and the eventual suspension are separate entries in the audit chain.
Status
Live in production. Provisions time-boxed contractor accounts against a real Okta tenant today from Slack and Teams; on approval it re-checks that no account already exists for the email (failing closed on any uncertainty), creates the account (Okta sends the activation email), adds each listed group independently, and arms the end date so a recurring sweep suspends sign-in automatically (reversibly). The arming is honest: if the automatic suspension cannot be scheduled, the card says the account is live and needs a manual suspension. Creation, each group outcome, and the eventual suspension are separate entries in the audit chain. Access scope and approval routing are configurable per customer.
