BCEL1014d: What Is My Offboarding Trigger for Okta?


Why Select Okta?

For organizations where Okta is their source of truth, or they have a system (such as HRIS or AD) that is pushing user data to Okta, it’s best for them to select an Okta trigger. With Okta, there are two available options: User is Disabled and User is Added to a Group + Group IS [Offboarding Group Name].

OPTION: User is User is Deactivated (BetterClouders Most Common Method)

If the first step of the offboarding process is to disable the user in Okta, this should be selected as BetterCloud’s offboarding trigger. It should be kept in mind that disabling a user in Okta may also suspend the user in Google, so it’s best to check if this Okta changes pushed to Google. If it does, Google users must be unsuspended before performing actions such as email forwarding, delegation and others actions which require the user to be active in Google.




 Quick action, taken from the directory


 Impact on other assigned apps

 Immediately cuts access to Okta + Apps



 User's status changes in BetterCloud


User is Added to a Group + Group is [Offboarding Group]

We’re often seeing BetterClouders utilize User Added to Group + Group Is [offboarding group] as their offboarding trigger when they DO NOT have an HRIS or AD system pushing to Okta. Creating an Okta Group specifically for offboarding allows organizations to keep track of their employees who are being/ have been offboarded, while ensuring that disabling the account can occur at the appropriate time. In the offboarding workflows, the user’s password can be changed and all sessions can be cleared, preventing them from authenticating again with Okta. Then, all offboarding for Google and other applications can be performed, finally resulting in the user being deactivated and all access to all other applications being cut.




 Keeps users organized


 Must create a Group if one doesn't exist

 Can open offboarding to non-IT users


 Access not cut immediately

 Deactivation timed in the Workflow



Why Wouldn’t You Select Okta?

If an organization has an HRIS that is pushing users to Google, or their HRIS is a native BetterCloud integration, their starting application should be either of these locations. Keep in mind, the goal here is to start at, or as close to, the source of truth as possible. If an organization is using Okta as their source of truth, this should be the starting point for offboarding.

Are You Using an HRIS or IdP?

If the organization is using an HRIS, as mentioned above, they’ll want to make sure that they’re syncing user data and changes directly to Okta. That way, if the user is disabled in the HRIS, it will push that change to Okta, which will then be reflected in BetterCloud. In this case, the trigger for offboarding would be User is Disabled.

Are There Other Options?

If an organization is changing a user’s password and clearing their sessions in Okta itself as a way to block users, they’ll need to select either the disable, or the move user to Group option moving forward. These events will ensure that BetterCloud’s WHEN/IF conditions are met, and the automated offboarding Workflow kicks off properly.

What Should I Keep In Mind / Review Once My Workflow Is Created?

If an organization is cutting off access in Okta, and disabling a user, how does that impact other applications? Are they unable to make changes on inactive users in any other integrated applications (such as Google)? This is critical to evaluate, ensuring offboarding works properly and all transfers, removals, forwards, and other offboarding actions run as intended.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request