## TL;DR
Restore the email connector connection and resend the missed notifications. Open the failed flow execution to read the connector error, reauthorize or repair the email connection it uses, most often an expired authorization for the mailbox provider, test-send from the connector, then re-run the flow for the affected hires with duplicate-send protection.

```text
Okta workflow provisioning notification failed: email connector error
```

## Use this when
- An Okta Workflow that emails hires or managers fails at the email card with a connector error.
- Test executions fail at the same card while earlier cards succeed.
- The sending mailbox recently changed password, security policy, or provider settings.

## Not for this skill when
- Okta system emails such as activation messages fail too. That is Okta notification configuration, not Workflows.
- The flow fails before the email card. Debug the earlier card first.

## Steps
1. Open the Workflows execution history for the provisioning flow for the affected hire and capture the full error detail, the operation that failed, and the identifiers involved, rather than working from the summary banner alone. Keep one hire as the test case for every change so cause and effect stay clear. Verify: the full error detail and one test hire are recorded
2. Open a failed execution and expand the email card to read the connector error detail, noting whether it is an authorization failure, a recipient rejection, or a provider rate response, and record the flow and execution id for reference. Verify: the email card error type is identified
3. Open the Connections area in Workflows and check the email connection health: reauthorize it with the sending mailbox owner if authorization expired, and confirm the sending mailbox itself is active, licensed, and not blocked from sending by a provider policy. Verify: the connection shows authorized and the mailbox can send manually
4. Apply the correction in Okta Workflows and save it, then re-run provisioning for the single test hire only and read the fresh log entry end to end. If it still fails, treat the new detail as the current cause and do not stack further changes on top. Verify: the test hire provisions successfully or a new specific detail replaces the old one
5. Send a test message from the connector card in a test flow to a team address and confirm delivery, because a green connection status alone does not prove the provider accepts sends from the connector. Verify: the hire notification downstream check passes with a delivered test message
6. Re-run the failed flow executions for the affected hires, checking first whether any notification was partially sent, to avoid duplicate welcome emails, and confirm each hire or manager receives the intended message with correct personalization values. Verify: the hire downstream checks pass in their own inboxes

## Why it happens
Okta Workflows email cards send through a separately authorized connection to a mailbox provider, and that authorization decays independently of Okta itself through password changes, provider policy updates, or token lifetimes. The flow logic stays correct while every send fails at the connector boundary, and the failure is only visible inside execution history. Reauthorizing the connection and proving it with a real test send restores the flow, and watching execution failures during hiring peaks prevents silent gaps in hire communications.

## Variants and edge cases
### Recipient rejected errors for some hires
A bad email value from the HR feed fails per-recipient while the connector is healthy. Validate hire emails upstream instead of changing the connector.

### Provider throttles bulk welcome sends
Stagger flow executions or use the provider bulk sending guidance when a large cohort starts on the same day.

### Connection reauthorization keeps expiring
Move the connection to a dedicated service mailbox with an app-level authorization the provider supports for automation, following the provider current guidance.

Compatibility: Applies to Okta Workflows with email connectors such as Microsoft 365 or Gmail connections. Requires Workflows admin and mailbox owner cooperation.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_h06uxJXqiEXvswSJ0gp_7g
