Workflows with YeshID

A workflow in YeshID is an ordered set of tasks that runs when something happens to a person — they're hired, they leave, they request access, or it's time to review who has what.

Some tasks run automatically through an integration (create an account, suspend a user, grant access); others are checklist items a person marks done. You define a workflow once as a template, and YeshID runs it on demand or automatically whenever its trigger fires.

This guide is about building your own workflows: how to create a template, what every setting does, how to wire up custom provisioner actions, and how workflows run once they're live. For the full catalog of individual task types and what each one does, see Workflow tasks in YeshID.

Templates vs. Runs

It helps to keep two ideas separate:

• A template is the reusable definition "this is how we onboard an engineer." You build and edit templates under Manage > Workflows.

• A run (or workflow instance) is one execution of a template for a specific person - "onboard Jordan, starting Monday." You watch and manage runs under the top-level Workflows section.

Build the template once; run it as many times as you need.

Workflow types

Every workflow has a type that determines what it's for, which tasks it offers, and how it can be triggered. When you select New workflow under Manage > Workflows, you choose one of three to build from scratch:

YeshID also ships built-in templates for access requests, application access, and access removal. Those are named and structured for you; this guide focuses on the three you build yourself.

Building a workflow template

1. Go to Manage > Workflows and select New workflow, then pick Onboarding, Offboarding, or Scheduled.

2. Give the template a clear name (the field reads My custom template name until you change it).

3. Work down the builder's sections — Trigger, Scheduling, Workflow owner, Required Inputs, Actions, and Notifications (each explained below).

4. Add and arrange your tasks in the Actions section.

5. Select Publish to save the template. It's now available to run.

The sections below explain each setting, because the defaults won't always be what you want.

Trigger — when the workflow starts

The Trigger section answers what kicks this workflow off. The Starts when dropdown is where you choose:

Conditions (optional) lets you add rules so the trigger only fires for some people — for example, only employees in a particular department. It's off by default; turn it on only when a trigger needs extra rules.

Scheduling — when it runs, and whether it stages

The Scheduling section controls timing:

• Start at — for event-driven workflows, choose whether the run begins immediately or on a person's date (start date for onboarding, end date for offboarding).

• Stage workflow — the most important toggle to understand. When on, a triggered workflow doesn't run right away; it's created in a Staged state and waits for a person to review it and press Start Workflow. This is your human in the loop. When off, the workflow begins on its own. Stage anything you want eyes on before accounts are actually created or removed.

• For Scheduled templates, you instead set a recurrence — Once, Daily, Weekly, or Monthly.

Workflow owner

The Workflow owner owns the run and is the default assignee for any unassigned tasks. Pick someone who should be accountable for the workflow finishing — if a manual task has no specific assignee, it lands with the owner.

Required Inputs

Required Inputs are the pieces of information collected when the workflow runs. Some are derived automatically from the tasks you've added (for example, a new hire's first name) and are locked. You can add your own with + Add input, give each an Input name, and use the Req toggle to mark whether it's required. Inputs you define here become fields the person running the workflow fills in.

Actions — adding and arranging tasks

The Actions section is the task tree — the actual work the workflow performs. To add a task, select Add task (or click into an empty task row). Each task row is a small text box that works two ways:

• Press the forward-slash key (/) to open the Task actions menu, then start typing to search YeshID's built-in tasks — type add user, for example, to find Add user to application. Pick one to drop it in. (The row's hint reads "Press '/' for Task actions or type in your own manual task.")

• Or just type your own text — without the / — to create a manual task: a free-form checklist item someone completes by hand.

Use the arrow keys to move through the menu, Enter to accept the highlighted task, and Esc to close it.

Notifications

The Notifications section keeps people informed as the workflow moves. You can enable or disable each type independently:

For each one you can edit the Message Template (with variables like the person's name and a link to the workflow, and a Reset to Default option) and choose Delivery Channels — Email, Slack, or Microsoft Teams, depending on what you've connected. See Notifications with YeshID for connecting Slack and Teams.

The task library

Tasks are the building blocks inside the Actions section. They fall into a few broad groups — this is the working set; the complete, behavior-by-behavior catalog is in Workflow tasks in YeshID.

Structural tasks (organize and gate other tasks):

• If condition: Runs its child tasks only when a condition is true (e.g., if department is Engineering).

• Approve workflow: Pauses the workflow until an owner approves. Put this at the top of any access-granting workflow.

• Directory and identity tasks: Create user, Set user org unit, Add user to directory group, Suspend user, Lock user, Delete user, license assignment, and the Google/Microsoft-specific variants (e.g. Transfer Google data, Convert to shared mailbox).

• Application access tasks: Add user to application, Add user to application groups, Add user to application role, Invite user to application, and their Remove user from… counterparts. These run automatically when the app has a provisioning integration, and become a manual checklist item when it doesn't — nothing is silently skipped.

• RBAC — Apply RBAC policy evaluates the person's policies and provisions everything their Eager policies grant. A workflow can hold only one of these. See Role-Based Access Control (RBAC).

• Custom and communication tasks — Custom task (a free-form to-do you define), Send custom email (templated, with merged user data and attachments), and Run provisioner action for user (covered in its own section below).

A note on labels. Built-in task names are fixed and describe what each task does. Only the free-form Custom task takes a name you choose.

Configuring a task

Select any task in the Actions tree to open its details panel. Depending on the task type, you can set:

• Task name: fixed for built-in tasks (the label tells you what the task does). The free-form Custom task is the exception: you give it whatever name you like when you add it.

• Assignee: for manual tasks, the person or role responsible. Automated tasks have no assignee; YeshID performs them.

• Due date: expressed as an offset from the workflow's date (for example, on the start date or a few days after).

• Task-specific parameters — e.g. which application, which group, which role.

Two tasks are worth calling out:

• If condition wraps other tasks so they only run when a rule is true. (Availability depends on your plan.)

• Run provisioner action for user runs a custom action you've defined on an application. (Availability depends on your plan — see below.)

Running custom provisioner actions

Sometimes the built-in tasks don't cover something an app's API can do — adding an onboarding user as an alternate host on a Zoom meeting, opening a Jira ticket, flipping a setting. Custom actions let you script those calls once on the application, then run them from any workflow with the Run provisioner action for user task.

Until you create it under the app's Connect & Integrate tab (step 1 below), it simply won't appear as a choice in the Run provisioner action for user task. Define it on the app once, then run it from as many workflows as you like.

There are two halves to this.

1. Define the custom action on the application

1. Go to the application in YeshID (Access > Applications > the app) and open the Connect & Integrate tab.

2. Scroll down and select Add Action.

3. Give the action a name (and an optional description).

4. Configure the call:

   • Method — the HTTP method (e.g. POST, DELETE).

   • URL Parameters and Headers — as key/value pairs, if the endpoint needs them.

   • Body — JSON that supports template variables so each run uses the right person's data.

Template variables let you drop in live values — {{.User.Email}} for the person's email, {{.Account.ExternalID}} for their ID inside that app, and many more. Wrap string variables in quotes, like "{{.User.Email}}". See Template Variables for every available field.

2. Run it from a workflow

Add a Run provisioner action for user task to your template and configure:

• Application — the app the action belongs to.

• Action — the custom action to run (its description and any parameters appear once selected).

• Directory identity — which account the action targets, supporting placeholders like the user's primary identity.

This task is automated — at run time YeshID calls the action with the running person's data, no manual step required. Because it's a normal workflow task, the call is still visible and auditable alongside everything else.

Triggering and running workflows

A published template can run three ways:

• Manually: Start it yourself for a chosen person (when the trigger is Started manually, this is the only way).

• Automatically: When its trigger fires from your people source. Pair this with Stage workflow if you want a person to review before it runs.

• On a schedule: For Scheduled templates, on the recurrence you set.

Once running, manage everything from the top-level Workflows section, which has three views:

• Workflows — every run, with its type, the person, dates, and status. From here you can Start a staged workflow, Nudge assignees, or delete a run.

• Tasks — individual tasks across all workflows, for people working their assigned to-dos.

• Approvals — approval tasks waiting on a decision.

A workflow run moves through these states:

Individual tasks within a run can be Pending, Blocked (waiting on a dependency or a condition that isn't met), Completed, Approved or Rejected (for approval tasks), or Error if an automated action failed. A failed automated task doesn't silently disappear — it surfaces so someone can resolve it.

Tips and good habits

• Stage anything destructive. Turn on Stage workflow for offboarding and for any onboarding that provisions a lot — a quick human review beats undoing a bad automatic run.

• Put Approve workflow first in access-granting workflows so access is never provisioned before an owner signs off.

• Prefer Apply RBAC policy over a long list of individual Add user to application tasks when access is defined by role — the workflow stays short and tracks policy changes automatically.

• Use conditions instead of separate templates. An If condition task (or a trigger condition) often saves you from maintaining one template per department.

• Reuse custom actions. Define an action once on the application and call it from every workflow that needs it, rather than rebuilding the API call each time.

FAQ

Where do I build templates vs. watch them run?

Build and edit templates under Manage > Workflows. Watch and manage runs under the top-level Workflows section (the Workflows, Tasks, and Approvals views).

What's the difference between staging and running a workflow?

A staged workflow is created but paused — it waits for someone to review it and press Start Workflow. A workflow that isn't staged begins on its own when triggered. Staging is how you keep a human in the loop.

A task in my workflow is a manual checklist item, but I expected it to run automatically. Why?

Application tasks like Add user to application run automatically only when that app has a provisioning integration connected. Without one, the same task still appears, but as a to-do for a person to complete by hand. Connect the integration and it becomes hands-off.

Why don't I see the "Run provisioner action for user" or "If condition" task?

Those tasks depend on your plan's entitlements (custom provisioner actions and conditional logic, respectively). If one is missing from the task menu, talk to your YeshID contact about your plan.

I added a "Run provisioner action for user" task, but the Action dropdown is empty. Why?

The dropdown only lists custom actions that already exist on the selected application. If it's empty, no custom action has been defined there yet. Open the application's Connect & Integrate tab, select Add Action to create one, then come back to the task — it'll appear in the Action list. See Running custom provisioner actions.

How do I add a task to a workflow?

In the Actions section, select Add task (or click an empty task row) and press the forward-slash key (/) to open the Task actions menu, then type to search and pick a built-in task. To create a manual checklist item instead, just type its name without the /.

Can a workflow run on a recurring schedule?

Yes — create a Scheduled workflow and set it to run Once, Daily, Weekly, or Monthly. Onboarding and offboarding workflows are event-driven instead, triggered by changes to a person.

Can I rename tasks?

Only the free-form Custom task, which you name when you add it. Built-in tasks (both automated and standard manual ones) have fixed names that describe what they do — you can't rename them.