This article describes the triggers and actions available when you connect Okta to HappyFox Workflows, and lists the IT operations you can automate with this integration.
Applicable Plans: ✔️ Basic ✔️ Team ✔️ Pro ✔️ Enterprise
Triggers
Okta triggers allow HappyFox Workflows to start automatically when identity or access events occur in your Okta organisation. Use these triggers to respond to user lifecycle changes without manual intervention.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Triggers
Triggers start a workflow automatically when a specific event happens in Okta. They have no configurable input fields — the workflow fires as soon as the matching Okta webhook event arrives. You can narrow which events actually start an execution by adding conditions to the trigger step in the workflow builder.
All Okta triggers fetch the affected user's full profile from the Okta API at the time the event fires and make the following fields available to subsequent steps:
Common trigger output fields (available in all Okta triggers)
| Field | Description |
|---|---|
id |
The Okta user's unique ID. |
status |
The user's current status (for example, ACTIVE, DEPROVISIONED, SUSPENDED, LOCKED_OUT). |
created |
Timestamp when the Okta account was created. |
last_login |
Timestamp of the user's most recent sign-in. |
login |
The user's Okta login name (typically their email). |
email |
The user's primary email address. |
firstName |
The user's first name. |
lastName |
The user's last name. |
| Any other Okta profile field | Additional profile attributes configured in your Okta tenant are also passed through. |
User Lifecycle Triggers
User Activated
Fires when an Okta user account transitions to the ACTIVE state — for example, when an admin activates a newly staged account or reactivates a deprovisioned user.
What fires it: Okta user.lifecycle.activate event received via webhook.
Data available: All common trigger output fields listed above, reflecting the user's profile and status at the moment of activation.
User Deactivated
Fires when an Okta user account is deactivated and moves to the DEPROVISIONED state, revoking all sessions and access.
What fires it: Okta user.lifecycle.deactivate event received via webhook.
Data available: All common trigger output fields listed above, reflecting the user's profile and status at the moment of deactivation.
User Profile Updated
Fires when any field on an Okta user's profile is changed — for example, a name, email, job title, or department update.
What fires it: Okta user.account.update_profile event received via webhook.
Data available: All common trigger output fields listed above, reflecting the updated profile values at the time of the change.
Tip: Use workflow conditions on this trigger to react only to specific field changes — for example, firing only when department changes to a certain value.
User Account Auto-Locked
Fires when Okta automatically locks a user account after too many consecutive failed sign-in attempts. Unlike the other user triggers, the locked-out user is identified from the event's actor field — because the user is the one triggering the lock by attempting to sign in — not from the target list.
What fires it: Okta user.account.lock event received via webhook.
Data available: All common trigger output fields listed above, reflecting the profile of the user who was locked out.
Group Triggers
User Added to Group
Fires when a user is added to an Okta group. In addition to the standard user profile fields, the trigger also includes data about the group the user was added to.
What fires it: Okta group.user_membership.add event received via webhook.
Data available: All common trigger output fields listed above, plus:
| Field | Description |
|---|---|
group_<group_name> |
An object containing the full group record for the group the user was just added to. The key uses the group name with spaces replaced by underscores (for example, group_IT_Support for a group named "IT Support"). Includes the group's id, type, profile, and other Okta group attributes. |
Note: If multiple users and groups appear in the same Okta event batch, a user's trigger data may include groups they were already a member of, not just the newly added group. This is a known edge case in the Okta event format and is unlikely to affect most single-user workflows.
Actions
Okta actions let you manage user accounts, security settings, group membership, and app assignments directly from a workflow step.
User lifecycle
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
User security
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Group management
|
|
|
|
|
|
|
|
|
App access
|
|
|
|
|
|
|
|
|
See Okta User Lifecycle Actions in HappyFox Workflows to learn more on how to configure each action
Use cases
Automated employee onboarding from a support ticket: When an IT onboarding ticket is created in HappyFox Help Desk, automatically create the new user's Okta account, add them to the appropriate group, and assign them access to the apps they need — eliminating manual provisioning steps and reducing the time between a new hire's start date and their first login.
Account lockout self-service resolution: When Okta fires a User Account Auto-Locked trigger, automatically create a ticket in HappyFox Help Desk and notify the agent assigned to IT support — so lockout incidents are tracked, prioritised, and resolved without the user needing to call the help desk.
Employee offboarding on ticket closure: When an offboarding ticket is resolved in HappyFox Help Desk, automatically deactivate the departing employee's Okta account, remove them from all groups, and revoke their app access — ensuring access is terminated consistently without relying on manual checklists.
MFA reset from an IT support ticket: When an agent resolves a ticket requesting an MFA reset, automatically trigger the Reset user factors action in Okta — removing the manual step of switching between HappyFox Help Desk and the Okta admin console to complete the request.
Profile change notification to IT: When Okta fires a User Profile Updated trigger — for example, when a user's department or manager changes — automatically create or update a HappyFox Help Desk ticket to notify the IT team, so they can review whether the user's group membership and app access still match their new role.
Temporary access suspension for security incidents: When a security-related ticket is raised — such as a report of a compromised account or suspicious login activity — automatically suspend the user's Okta account while the investigation is underway, and reactivate it once the ticket is resolved.