Okta Workflows can automate identity logic without writing a single line of code, but its true power lies in its ability to model state changes rather than just simple event-to-action triggers.
Let’s see it in action. Imagine an HR onboarding process. When a new employee is added to Workday (our HRIS), Okta Workflows should:
- Create an Active Directory (AD) user.
- Assign them to a default Active Directory group.
- Create a Google Workspace account.
- Send an email to the new hire with their login details.
Here’s a simplified Workday to Google Workspace provisioning flow:
{
"name": "Workday New Hire Onboarding",
"description": "Automates provisioning for new hires from Workday.",
"triggers": [
{
"type": "Workday",
"event": "New Employee",
"config": {
"connection": "workday-prod",
"filters": [
{
"field": "employeeStatus",
"operator": "EQUALS",
"value": "Active"
}
]
}
}
],
"cards": [
{
"id": "create_ad_user",
"type": "Active Directory",
"action": "Create User",
"config": {
"connection": "ad-corp",
"username": "{{trigger.data.employeeId}}",
"firstName": "{{trigger.data.firstName}}",
"lastName": "{{trigger.data.lastName}}",
"email": "{{trigger.data.email}}"
}
},
{
"id": "add_to_ad_group",
"type": "Active Directory",
"action": "Add User to Group",
"config": {
"connection": "ad-corp",
"user_identifier": "{{cards.create_ad_user.userId}}",
"group_name": "AllEmployees"
}
},
{
"id": "create_google_user",
"type": "Google Workspace",
"action": "Create User",
"config": {
"connection": "gsuite-corp",
"primaryEmail": "{{trigger.data.email}}",
"name": {
"givenName": "{{trigger.data.firstName}}",
"familyName": "{{trigger.data.lastName}}"
},
"password": "{{secrets.default_password}}"
}
},
{
"id": "send_welcome_email",
"type": "Gmail",
"action": "Send Email",
"config": {
"connection": "gmail-it",
"to": "{{trigger.data.email}}",
"subject": "Welcome to the Team!",
"body": "Hi {{trigger.data.firstName}},\n\nYour accounts have been provisioned. Your username is {{trigger.data.employeeId}} and your temporary password is {{secrets.default_password}}.\n\nBest,\nIT Department"
}
}
]
}
This flow is triggered by a "New Employee" event from Workday. The trigger.data object contains information about the new hire, like employeeId, firstName, lastName, and email.
The first card, create_ad_user, uses the Active Directory connector to create a user. Notice how it pulls firstName, lastName, employeeId (for username), and email directly from the Workday trigger data using Jinja templating ({{trigger.data.field_name}}).
Next, add_to_ad_group adds the newly created AD user to the "AllEmployees" group. Crucially, it references the userId output from the previous card (create_ad_user) using {{cards.create_ad_user.userId}}. This is how Workflows chains actions together, passing data between them.
The create_google_user card does the same for Google Workspace, using the email, firstName, and lastName from Workday. It also pulls a default_password from Okta’s secret store, which is a much more secure way to handle sensitive credentials than hardcoding them.
Finally, send_welcome_email uses the Gmail connector to send an email to the new hire. It personalizes the message using data from the Workday trigger and the AD user creation card.
The real power here is how Workflows manages the state of the identity lifecycle. It’s not just "if Workday event, then do X." It’s "when a new hire enters the Active state in Workday, transition them through AD user creation, group assignment, Google Workspace provisioning, and finally notify them." The flow definition itself represents this stateful journey.
The most surprising thing about Okta Workflows is that its "helper functions" — the small, single-purpose operations like "Get User," "Format Date," or "Lookup Value" — are often the most critical components for building robust, resilient flows. People often focus on the big system integrations, but it’s the humble helper functions that allow you to transform, validate, and enrich data between those integrations, preventing errors and enabling complex logic. For instance, using a Lookup Value card to retrieve a user’s department from a CSV file before assigning them to a specific AD group based on that department is a common pattern that relies entirely on a helper function.
Eventually, you’ll want to handle the case where an employee leaves the company.