79lk9 (79lk9) asked a question.
So... we have a process that runs on a weekly basis that queries and deactivates users who have not logged in to Salesforce for over 90 days.
Sometimes, a user does need to get back in after that happens, so they submit a ticket to be re-activated in Salesforce. Our Okta team puts them through the standard activation process but nothing happens. Their salesforce user record does not reactivate. I believe it is because Okta does not try to update a user that apparently has no changes from Okta's perspective. In other words, Okta does not know the user was deactivated in Salesforce and according to Okta's settings the user already has access and if there were no changes from Okta's perspective it doesn't actually try to update the user in Salesforce. That is my theory anyway. Can anyone confirm or not? And regardless, can anyone tell me how to resolve this issue (other than "stop manually deactivating them in Salesforce")?
Stop manually deactivating them in Salesforce. 😐
Confirming you are correct. Okta has 'ownership' of the account status in Salesforce but that ownership is driven from Okta's view of the account. If the account remains active in Okta with no status changes, then it has no knowledge of any change in SF and therefore won't trigger a provisioning event.
I'm guessing you don't want to deactivate the Okta account in because of other provisioning activity that would take place. You only want the Salesforce account deactivated ?
If it was me, and I wanted to independently deactivate a Salesforce account without driving that from the Okta account status, I'd write a workflow or two driven from an Okta group membership. Then have your Okta team change their task to add/remove users from that group, which would trigger the Workflow that activates the SF account.
Ok... am I right that it is a limitation of okta that it can't do what I need?
I'd say no. Okta drives behaviour based on activity in Okta. If you decide to make changes in an account in a downstream system instead of in Okta, then expecting Okta to see that event and take action is not what an IdP is expected to do.
That said, you can do it in Okta. You just have to break out your Workflows. There are a number of routes you could do this either by checking the SF status, or by checking the SSO login events in Okta and taking action to unassign the user from SF in Okta, which will deactivated their account in SF.
So doable. You just need to look at your current process.