Workflow Tasks in YeshID
Last updated: June 29, 2026
A YeshID workflow is an ordered set of tasks that run when something happens to a person or an application — someone is hired, someone leaves, someone requests access, or it's time to review who has access to what. Each task is a single unit of work: create an account, add someone to a group, send an email, ask an owner to approve, or remove access. Some tasks run automatically through an integration; others are checklist items a person marks done.
This reference catalogs the task types YeshID offers, organized by the kind of workflow they belong to. Use it to understand what each task does before you add it to a workflow template, and to know which tasks YeshID can perform automatically versus which ones become a to-do for a person. For how to build and run the templates these tasks live in, see Workflows with YeshID.
The task names below are YeshID's built-in labels and can't be changed — they tell you what each task does. The one exception is the free-form Custom task, which you name yourself when you add it.
How workflows and tasks fit together
Every workflow has a type that describes what it's for. The type determines which tasks are offered and when the workflow is triggered.
Workflow type | What it's for |
|---|---|
Onboarding | Set up a new person — create accounts, grant access, send welcome emails. |
Offboarding | Wind a person down — suspend, lock, transfer data, remove access, delete accounts. |
Application access | Grant a person access to one or more applications. |
Application access request | The user-initiated version of the above — someone requests access and it routes for approval. |
Access removal | Revoke a person's access to specific applications, groups, or roles. |
Time-based access | Grant access that is automatically removed after a set period. |
Audit | Review who has access to an application and remove what shouldn't be there. |
New application request | Handle a request to add a new application to YeshID. |
Delete application | Clean up and retire an application. |
Application | Application-scoped automation (e.g. provisioning tied to an app). |
Change request | A generic change that routes through YeshID. |
Custom | A workflow you assemble yourself — including scheduled monitoring. |
A task can belong to more than one workflow type. Add user to application, for example, appears in onboarding, in application-access workflows, and in access requests. The sections below group each task under the workflow where you'll most often use it, and call out when a task is shared.
Building-block tasks (usable in most workflows)
These tasks aren't tied to a single workflow type — they're the structural and communication pieces you combine with the action tasks.
Task | What it does | Who completes it |
|---|---|---|
If condition | Runs the tasks inside it only when a rule is true — for example, "only if the person is in the Engineering department." If the rule is false, those tasks are skipped. | Automatic |
Approve workflow | A checkpoint that pauses the workflow until a chosen person signs off. Nothing after it runs until they approve — use it to hold provisioning or access until a manager or owner gives the OK. | A person (the approver) |
Custom task | A free-form checklist item you define — anything YeshID doesn't automate. | A person |
Send custom email | Sends a templated email to internal users or external addresses. Supports a custom subject and body (with user data merged in) and file attachments. | Automatic |
Onboarding tasks
These run when a new person joins. The defaults create the person's directory identity, place them in the right groups and org unit, grant application access, and send them their welcome details.
Directory and identity
Task | What it does | Automation |
|---|---|---|
Create user | Creates the person's identity in a connected directory (Google Workspace, Microsoft/Entra, Okta, etc.). | Automated |
Set user org unit | Places the user in an organizational unit in the directory. | Automated |
Add user to directory group | Adds the user to one or more groups in the directory. | Automated |
Add user to YeshID group | Adds the user to a YeshID group, which in turn grants the applications tied to that group. | Automated |
Assign Microsoft license | Assigns Microsoft 365 license(s) to the user. | Automated |
Assign Google licenses | Assigns Google Workspace license(s) to the user. | Automated |
Add alias to Google user | Adds an email alias to the user's Google Workspace account. | Automated |
Activate Okta user | Activates a staged Okta account. | Automated |
Send access email to user | Emails the new user their directory sign-in details. (Google Workspace has its own Send the user a Google Workspace access email with a customizable subject and body.) | Automated |
Application access (onboarding)
Task | What it does | Automation |
|---|---|---|
Create user in application | Creates a new account for the user in an app via a configured integration. | Automated |
Add user to application | Provisions the user into an application. | Automated if the app has an integration; otherwise a manual checklist task |
Invite user to application | Sends the user an invitation to join an app through its integration. | Automated |
Add user to application groups | Adds the user to one or more imported groups inside an application. | Automated or manual (depends on the integration) |
Add user to application role | Grants the user a specific role inside an application. | Automated or manual |
Push groups to application | Pushes groups to an app using your configured group mappings. | Automated |
Run provisioner action for user | Runs a custom provisioner action defined for the application. | Automated or manual |
Apply RBAC policy | Applies the user's RBAC policies, granting all the access those policies define. A workflow can contain only one Apply RBAC policy task. | Automated |
Add user to application and its group/role variants are automated when the application has a provisioning integration configured. Without an integration, the same task becomes a manual to-do so a person can grant access by hand and mark it done. See Role-Based Access Control (RBAC) for how Apply RBAC policy decides what access to grant.
Offboarding tasks
These run when a person leaves. They suspend and lock accounts, hand off data and email, revoke access, and — where you want it — delete accounts.
Directory and identity
Task | What it does | Automation |
|---|---|---|
Suspend user | Suspends the user's directory identity so they can't sign in. | Automated |
Unsuspend user | Reverses a suspension. | Automated |
Lock user | Locks all of the user's directory identities across every connected directory. | Automated |
Delete user | Deletes the user's identity from a directory. | Automated |
Turn off 2FA for directory user | Disables two-factor authentication on the user's directory identity. | Automated |
Unassign Microsoft license | Reclaims the user's Microsoft 365 license(s). | Automated |
Deactivate Okta user | Deactivates the user's Okta account. | Automated |
Migrate user email | Migrates the user's email to a new address or domain. | Manual |
Google Workspace (offboarding)
Task | What it does | Automation |
|---|---|---|
Suspend Google user | Suspends the Google account (blocks sign-in, preserves the account). | Automated |
Lock user's Google Workspace account | Full lock: signs the user out, revokes OAuth tokens, resets the password, and removes recovery info. | Automated |
Turn off 2FA for Google user | Disables two-factor authentication on the Google account. | Automated |
Archive Google user | Archives the Google account and deactivates the user in YeshID. | Automated |
Remove Google user from groups | Removes the user from all Google groups. | Automated |
Unassign Google licenses | Reclaims the user's Google Workspace license(s). | Automated |
Convert to shared mailbox | Converts the user's mailbox into a shared mailbox. | Automated |
Set email forwarding alias for Google Workspace user | Forwards the departed user's mail to another person. | Automated |
Transfer Google data | Transfers the user's Google data (Drive, Calendar, and more) to another user. | Automated |
Delete user's Google Workspace account | Deletes the Google account with no data transfer. | Automated |
Delete user's Google Workspace account and transfer data | Deletes the Google account and transfers their data to another user in one step. | Automated |
Access removal (offboarding)
Task | What it does | Automation |
|---|---|---|
Remove user from all applications | Deprovisions the user from every application they have access to. | Automated |
Remove user from application | Deprovisions the user from a single application. | Automated if the app has an integration; otherwise manual |
Remove user from application groups | Removes the user from specific application groups. | Automated or manual |
Remove user from application role | Removes a specific role from the user in an application. | Automated or manual |
Remove user from directory group | Removes the user from specific directory groups. | Automated |
Turn off 2FA tasks exist for offboarding because a departing person often needs 2FA cleared before an account can be locked, transferred, or handed to a shared owner. They are not a way to weaken security on an active account.
Application access and access-request tasks
These power Application access, Application access request, Access removal, and Time-based access workflows. They reuse the same application tasks listed under onboarding and offboarding — granting access uses the Add user to… tasks, revoking it uses the Remove user from… tasks — plus the Approve workflow task when a request needs sign-off before access is granted.
Granting access | Removing access |
|---|---|
Add user to application | Remove user from application |
Add user to application groups | Remove user from application groups |
Add user to application role | Remove user from application role |
Invite user to application | Run provisioner action for user |
Run provisioner action for user | — |
For time-based access, YeshID schedules a removal workflow to run when the access window ends, so the Remove user from… tasks fire automatically without anyone remembering to revoke.
Audit tasks
Audit workflows review existing access and clean up what shouldn't be there.
Task | What it does | Who completes it |
|---|---|---|
Audit application | Reviews access to an application by a user or a group of users so a reviewer can confirm or deny it. | A person (the reviewer) |
Remove access from resource | Removes an identity's access to a specific resource (a repo, project, workspace, etc.) when a reviewer denies a resource-scoped item. Always manual — no integration currently automates resource-level removal. | A person |
Automated vs. manual tasks
The single most important thing to know about any task is whether YeshID can perform it for you.
Kind | What happens | Examples |
|---|---|---|
Automated | YeshID performs the action through a connected directory or application integration and marks the task done itself. | Create user, Suspend Google user, Assign Google licenses, Apply RBAC policy, Send custom email |
Manual | The task becomes a checklist item assigned to a person, who does the work and marks it complete. | Custom task, Migrate user email, Audit application, Remove access from resource |
Automated or manual | Automated when the application has a provisioning integration; manual when it doesn't. | Add user to application, Remove user from application, Add user to application groups/role |
Structural | Doesn't act on a system — it organizes or gates other tasks. | If condition, Approve workflow |
The practical takeaway: connect an integration and the matching tasks become hands-off; leave it unconnected and the same tasks still appear, just as a to-do. Nothing gets silently skipped.
Tips
Use Approve workflow at the top of any access-request workflow so access is never granted before the owner signs off.
Prefer Apply RBAC policy over a long list of individual Add user to application tasks when access is defined by role — it keeps the workflow short and stays in sync as policies change.
For offboarding, decide suspend vs. lock vs. delete deliberately. Suspend is reversible, lock cuts off all sessions and tokens, and delete is permanent — pair delete with a Transfer data or Set forwarding task so nothing is lost.