YeshID release notes: November 2026

This release gives you a look before things change: review task due dates before a workflow starts, preview how a date mapping will affect onboarding and offboarding, and see exactly what Rae will change before you approve it. Offboarding now creates removal tasks for the access a person holds when it runs, large unexpected offboardings wait for an administrator, and Google Workspace, Microsoft Entra, and Okta accounts join Applications and access reviews.

Changes to know about

Action needed

• If your integration templates use optional custom person fields, check the mappings that can be empty. A missing value now renders as an empty string instead of a placeholder, and SCIM or custom HTTP updates may send that empty string to the destination, where it can clear the field.
• If you had an import-only Lucidchart connection, it now uses SCIM. If its old token is rejected, replace it with a Lucid SCIM admin-management token.
• If you call the YeshID API, check the changes under API changes below.

Works differently now

• On the Run Workflow page, Immediately is no longer preselected, so choose it when a workflow should start now. Required yes/no inputs also need you to pick Yes or No.
• Remove user from all applications now works out what to remove when it runs on the person's end date, not when the workflow is created.
• When one directory sync or HRIS import would start offboarding for a large share of people at once, YeshID stages those offboardings for an administrator to start instead of starting them.
• Tasks held for approval wait until every required approval is given. Rejecting, cancelling, or skipping an approval no longer releases them.
• Existing Remove user from directory group tasks keep their saved list of groups. To remove the person's current memberships when the task runs, open the task in the template and select All groups.
• CSV export is no longer available from an application's imported group and member tables.

Workflows

Review and adjust task due dates before a workflow starts

The redesigned Run Workflow page puts the person, required inputs, tasks, and notifications on one form. Once you choose a run date, each task's due date appears as an actual date and time that you can check and change before you start. Templates still store relative offsets and work for every run.

The form asks you to decide a few things instead of assuming them:

• When to start: Immediately is no longer preselected.
• Required yes/no inputs: pick Yes or No.
• The name: a run from a saved template can keep its generated name or use your own. A workflow you start from scratch needs one.
• The person: Scheduled workflows can run without a person. Onboarding, offboarding, and change workflows still need one.

If the person isn't in YeshID yet, you can create and select them without leaving the page. Create person in the drawer saves the person right away, before you confirm the workflow. Cancelling the workflow afterward leaves that person record in place.

Offboarding covers the access a person holds on their end date

Remove user from all applications now waits until its scheduled end date, then builds removal tasks from the access the person holds at that moment. Access granted after the workflow was created, such as an application added during a notice period, is included in the removal tasks, subject to the configured label filters. Until it runs, the task stays open, so the workflow can't finish early with nothing removed.

You can also include or exclude applications by label. For example, exclude a label you use for applications that need separate data-transfer steps, and handle those on their own. An exclusion wins when an application matches both filters; leave both empty to include every application.

Running the task early asks for confirmation and leaves out access granted afterward. There's no per-application preview before it runs, and an invalid label in its configuration stops the task instead of removing more than you intended.

Fewer application workflow tasks get stuck

Role and group tasks, including Push Groups, can now find a person's account in an application even when its name differs from their current YeshID email, for example an account set up under an earlier email address. YeshID falls back to the account linked to that person and doesn't rename it at the provider.

The fallback applies when the task is for a specific person, asks for their account by current email, and exactly one account in that application is linked to them. It doesn't apply to custom account names or to people with more than one linked account there.

If an application-provisioning workflow sat In progress with no error while its own Create user subtask never started, that's fixed. Dependencies on unrelated tasks still apply.

Remove someone from the directory groups they're in when the task runs

With All groups selected, Remove user from directory group looks up the person's memberships in the selected directory when it runs, including groups added after you saved the template. You no longer have to keep a group list up to date. Selecting or clearing an individual group turns All groups off.

In this mode, Google Workspace and Entra dynamic groups are skipped, because their rules control membership. Other provider restrictions can still prevent a removal. The task tries every remaining group and reports each group it couldn't remove and why. An error can mean some removals succeeded and others need your attention.

Send a departing person's Google data and email alias to their manager

One offboarding template can now hand off every departing person's Google data. Google Workspace's Transfer Google data and Set forwarding email alias tasks can use Offboarding User's Manager as the recipient instead of a fixed person.

The manager must be active when the workflow is created. If no active manager is available, choose another recipient on the failed task and retry it. Forwarding an alias still needs a Google account deletion task earlier in the workflow.

Held tasks now wait for every approval

Tasks held for approval now wait until every required approval is given, so nothing runs while an approval is still outstanding. Rejecting, cancelling, or skipping an approval doesn't release them, and running a task directly can't get around an active hold.

This fix doesn't undo earlier runs. If a task ran before all its approvals were in, review any accounts it created.

Directories and people

Preview the workflows a date mapping will change

You can now map custom directory attributes to Start date and End date, then see how people's dates and their onboarding or offboarding workflows would change before you confirm. The preview points out workflows that would start immediately. If stored End date values change before you confirm, you'll need to review a fresh preview.

Once End date is mapped, directory syncs can overwrite dates entered by hand in YeshID. A blank or missing source value clears End date, except for suspended directory accounts, and a value YeshID can't read leaves it in place. Start date is more forgiving: a blank or unreadable value leaves the stored date in place.

For Entra and Okta custom attributes, enable Fetch all fields so YeshID can read the value. An inactive People source writes dates only after you activate it and a later sync runs. Removing the End date mapping leaves existing dates in place.

Large offboarding changes wait for an administrator

If End date changes from one directory sync or HRIS import would start offboarding for more than five people and more than a quarter of the people that source is responsible for, YeshID saves the new dates but stages those offboardings instead of starting them. They appear in Workflows with the Staged status for an administrator to review and start. A mistake in a source field can't offboard a large part of your organization at once.

Because clearing a person's End date cancels their scheduled offboarding, large clears from a directory are held back too. The same thresholds apply, measured against that directory's people who already have an End date. YeshID doesn't apply those clears, and the rest of the sync still runs and is reported as partial. To apply them, fix the source field, or review and confirm the End date mapping in People settings.

Set each person's manager from the directory attribute you choose

In a directory's field mappings, you can now choose one attribute to fill YeshID's built-in Manager field. Use an attribute that holds the manager's email. That email has to match an identity in the directory that's linked to a person in YeshID.

When set, this mapping overrides the manager the provider reports. Without it, nothing changes. An empty value, or one that doesn't match, leaves the current manager in place instead of clearing it.

Unsuspended Google Workspace accounts stay unsuspended

We fixed a case where a profile update already under way when an Unsuspend task ran could suspend the Google Workspace account again. Profile and organizational unit updates no longer write back a suspended or archived state they read earlier.

Manage new cloud directory connections in Applications

You can now connect Google Workspace, Microsoft Entra, and Okta directories from the application catalog. Each new connection gets an application page with its accounts, groups, read-only roles, and resources in one place, including each account's MFA status. Groups, Roles, and Resources are available on every plan. New connections count toward your plan's directory limit.

Existing directories keep their current pages until YeshID converts them. Conversion isn't automatic or self-service, and reconnecting an existing directory doesn't convert it. Contact YeshID if you'd like yours converted.

A newly connected additional directory starts with its People source disabled. Enable it if the directory should contribute people. Only accounts first seen after you enable it create new people; accounts already there can link to existing people by matching email. Existing additional directories don't get a People source automatically, and reconnecting doesn't recreate or re-enable one.

Update several directory accounts at once

Select multiple accounts in a directory application to change their groups together, or to run any operation that every selected account supports. If the selection includes a suspended account, Manage groups is disabled for all of it. Password reset, aliases, and data transfer are still one account at a time, and bulk removal and unmapping aren't available.

Access reviews

Review cloud directory accounts alongside your applications

Access review campaigns and templates can now include Google Workspace, Microsoft Entra, and Okta directory application accounts. This uses the application pages described above, so an existing directory needs YeshID's conversion first. Reviewers can request supported group changes but can't change roles.

Remove Access creates a manual remediation task. The assignee removes the access, and a later directory import can verify that the person no longer has a live account on the application. The review decision itself doesn't delete the account.

Capture a snapshot when some application data is out of date

For an access review's first snapshot, application data now counts as stale after seven days instead of 24 hours. If some imported data is still stale or missing, the campaign owner can acknowledge it and capture the snapshot anyway, instead of waiting on every import. The confirmation lists each affected application and how old its data is. A campaign with nothing in scope still can't be captured.

Confirming doesn't refresh any data. The snapshot keeps the evidence available at capture time, and later imports don't update it. Re-capturing an existing snapshot works the same as before.

Remediation + Verification shows your latest decisions

When you return to the Remediation + Verification tab after certification decisions change, the scope summary and worklist now refresh instead of leaving an old empty or incomplete list on screen. The refresh updates what's on screen; it doesn't carry out or verify access changes.

Applications and integrations

Let eligible people request access through approval

People can now find and request applications they're eligible for without being given access automatically. In an RBAC policy, set an application to Gated: people in the policy can see and request it, and their requests go to the application's approvers.

To make sure a person approves each request, configure approvers for the application and check overlapping policies. A matching Lazy or Eager grant can still approve the request automatically, and so can an application with no approval groups.

See what Rae will change before you approve

Rae can now preview the application account, role, and group changes it proposes before you approve them, for the changes your permissions and plan allow. When you approve, Rae checks again; if the targets or steps have changed, you'll be asked to approve a fresh preview.

For bulk account additions, the preview names up to 50 people and summarizes the rest. Approving queues provisioning: an approved addition can still be waiting for the account to be created in the application.

Mark shared accounts as non-human

If your organization has Access Graph, administrators can now mark an unlinked resource that represents a user, such as a shared account, as non-human. It then shows Not a person in the Person column instead of Unlinked, which tells shared accounts apart from accounts that just haven't been linked yet. The mark survives imports.

A resource linked to a person can't be marked, and a marked resource can't be linked to a person. Cloud directory application accounts can't be marked non-human or assigned an owner. Access Graph is included on the Business plan. On another plan, contact YeshID to check availability.

Refresh application data more often

On the Pro and Business plans, you can schedule application syncs as often as every hour, or every 2, 3, 4, 6, 8, or 12 hours, for fresher data in access reviews and reports. Once a day is still the default. Start times are staggered by up to 30 minutes, so a sync may not start on the exact minute.

If a sync is still running when the next one is due, the next one is skipped. Sync now, Activate import, and deleting the application are unavailable until the running sync ends. A sync that runs longer than six hours fails.

Search across all imported groups and members

Search, sorting, and paging now cover the full collection in an application's imported group and member tables, and the totals count every result. You can find a group or member in a large application without the page first loading every row.

See every import in an application's integration status

An application's integration status now takes every enabled import into account: a running or failed import other than Import Users shows in the overall status. If you disable Import Users, its old success banner no longer stays behind.

Connect Zendesk with OAuth

New Zendesk connections from the catalog use OAuth 2.0. YeshID connects through a client you create and control in Zendesk, with only the users:read and users:write scopes. Existing API token connections keep working, and you can switch them to OAuth when you're ready.

To set up OAuth:

1. In Zendesk, create a confidential OAuth client and register the YeshID callback URL.
2. Grant the client the users:read and users:write scopes.
3. In YeshID, enter the Client ID and Client Secret.
4. In the Base URL, Authorization URL, and Access Token URL fields, replace the subdomain placeholder with your Zendesk subdomain.

Bring Swif accounts, teams, and devices into YeshID

The new Swif integration is in beta. You can import, create, update, and delete employee accounts, and import teams and devices, with each device linked to the employee who owns it. Setup needs a Swif organization API token and the correct region, US or EU.

Swif employees are imported as application accounts, not as new YeshID people. Locking, wiping, restarting, and reassigning devices stay in Swif.

Choose the Lucid endpoint you need

Lucid replaces the Lucidchart catalog entry, and you can now edit its SCIM endpoint. Existing SCIM connections keep their endpoints and don't need to reconnect if they're working. Lucid SCIM requires a Lucid Enterprise plan and an administrator with a SCIM token.

Former import-only Lucidchart connections now use SCIM. If an old token on one of those connections is rejected, replace it with a Lucid SCIM admin-management token.

API changes

If you call the YeshID API, update your clients for these changes:

• Audit item JSON now uses accountId instead of orgApplicationAccountId.
• GET /api/v1/users no longer includes the applications field, which was always null; appCount remains. To read a person's application accounts, use GET /api/v1/applications/user/:id with an API key that has the application or application.readonly scope. user.readonly alone isn't enough.
• POST /api/v1/application/:id/map-users now returns mapped and skipped results, showing which accounts were mapped and which weren't, instead of an empty object.
• People without admin access no longer see sensitive configuration in application list and detail responses. For ordinary members and audit-only readers, these responses show provisioning status without integration request details, configuration that holds credentials, raw errors, or the HRIS collection reference. Organization administrators, service users, and application administrators still get the full configuration.

‍