Hi! Great question, when you enabled provisioning, you have "Enable" "Update" & "Disable" checked, correct? It has been my experience that as soon as those are checked and saved, the process begins immediately. Particularly if users have already been created in the integrated application, it may not be apparent as no changes would be made.

See here: Configure provisioning for an app integration

When setting it up, you should see that enabling the API integration was successful which is really the first step. You can use "Test API Credentials" as a way to do that assuming the integration has already been setup. Once that is complete, ensure that you have the boxes above checked off as appropriate in the "To App" section of the integration. I have seen that this often takes effect rather quickly, do you see any errors associated with the app either within the app view or at the Tasks page? If you assign a user to the app (a test user as an example) to the app, are they created in the target app (assuming they were not there already)?

I hope this helps! Please reach out if you have any questions or comments on this - happy to help!

Oh I see that I was not descriptive enough. I changed the configuration in "To Okta", and I think you are referring to "To App" provisioning settings. I see those checkboxes there, but not in the import settings.

It does seem like my changes took effect though. I'm still interested in answering this question so that I can predictably test similar provisioning changes. I'll keep in mind to try your trick and test if changes are made immediately next time.

Well, at least I don't see the user in assignments. In our directory, I was hoping that I would see the user's account be disabled or deleted, since I configured the "To Okta" configuration in my IdP app (Google Workspace) to auto-confirm exact matches. However, the user still exists in the directory, even though their account has been disabled in Google Workspace, and there is no longer a reference in the Okta app assignments.

Got it, so you are specifically looking to make a change to the user account in Okta based on action in Google Workspace, as opposed to the other way around. I understand that you are not seeing the user deactivated although that is what you expect, correct?

Please take a look here: Google Provisioning, specifically the section titled "Configure Profile and Lifecycle Sourcing". This section talks about how to configure the app in Okta to "Deactivate" a user when "a user is deactivated in the app". Are your settings currently set for "Deactivate"? The options are "Deactivate, Suspend, & Do Nothing". Deactivate is defined as:

• Deactivate: The Okta user is deactivated and is no longer be able to sign in or access Okta. If re-activated in Google Workspace in the future, the Okta user will go through the re-activation process in Okta. The user will go through the initial Okta user setup procedure again.

I hope that helps! I look forward to your reply.

This looks like exactly what I need!

I'm not able to test it at this time because I assume this trigger is event-based, and I need an approval to reactivate and deactivate the recently terminated user, but I'll let you know if I was successful if the thread is still open the next time we deprov.

Either way, thank you so much for your help, Don!

Hey Don, and Okta community members,

I was able to verify a successful deprovisioning by use of the "Import Now" button. It even recognized partial matches since the username was appended with "_dep" in Google Workspace! I presume this will also work well with the automatic nightly provision job but I'll have to wait to test that another day.

Thanks a bunch for your help Don! I hope your solution can help others as well!