Hello this is Vasi from Okta Support,

If the users are created in OKTA you have the possibility to do not send the activation email so you user will be in STAGED status. 

You can provision the accounts to Gsuite so the email will be created by the provisioning job.

Once the email is created you can activate the accounts in OKTA by bulk activation. 

For better and personalized assistance we do recommend you to open a support ticket so we can find your personalized workaround according to your org.

Hi Vasi,

We are creating the users in G Suite, from Okta. On Tuesday I activated the user in Okta, the email apparently bounced with the error, "account does not exist", meaning the targeted G Suite account (as explained by Okta Support). Once the email bounces Okta blocks that email address and the user is, frankly, SOL accessing their Okta account until I file a Support ticket with Okta. Okta then manually 'unblocks' the account. This is an awful experience for a new user.

This is why I asked my original question here. What is Okta's guidance for this workflow?

I only recently by chance ran across documentation informing the reader that 'secondary email' is *also* used for the 'User activation' email, but only *after* I learned from Okta Support that 'secondary email' is used for this purpose... too. I'd read Okta Help's 'Manage People' page, in its entirety; under Add People it explicitly states secondary email is used for user password resets. It states no other purpose for secondary email.

With that information, who would logically consider pursuing that as an avenue related to an activation email issue? And if an org disallows that secondary email for security reasons...

back to how to manage this if Okta's provisioning of a G Suite account collides with Okta's sending of the Activation Email to that account? It blocks the new user's email address from Okta password resets, thus their Okta account?

I have a ticket open, and a call upcoming to review this. I'll update here with the info I receive.

Christopher,

If you add a secondary email address to the user's profile before you activate them, both the primary and secondary email addresses will get the activation email.

In my case, we don't want to send company information to a personal email address.

I am still looking for a solution to this issue where Okta doesn't provide us a way to create provide some other method for an un-enrolled, new user to get a temp password or a link to enroll.

Okta is depending exclusively on the user having access to their email. In our case, with Okta Universal Directory, users don't have email access until they setup their Okta and they can't set up Okta without access to email.

Hi Michael,

Thanks for your reply, I had discovered that by accident, and it's an interface inconsistency on Okta's part. On the Settings>Customizations>General page, under, "Optional User Account Fields", the helper text is completely generic (unlike the other areas on that page), implying you already know what those fields are used for. Only after you click 'Edit' does actionable helper text show up. Okta's lack of 'hover over' info or links to supporting documentation is a failure of web interface best practices.

Another issue you may want to be aware of... with automated (rules-based) provisioning:

• If a user is successfully assigned to a group, via a rule, and an app assigned to the user, via the group, fails to provision for the user (GMail in my case), the app does not appear in the user's 'Assigned Applications'. And, there will be NO user log info about this, at all.

Of course, the problem with this, implicitly, is Okta expects any admin to know every app any user, across an entire organization, 'should' be successfully provisioned to in order to ensure thorough app assignment and provisioning.

So, best to interpret 'Assigned Applications' as 'Provisioned Applications', and prepare to hunt and peck through the various rules-based group assignments to make sure you know what apps the user is supposed to have.