Access Requests with YeshID

Access requests let anyone in your organization ask for an application, a different role, or more time on an app they already have, from within the YeshID app or from Slack/Teams, and route that request through approval to automatic provisioning. Instead of a Slack DM to IT or a manually tracked spreadsheet, every request is a single record you can see, approve, and audit from one place.

Access requests are available on every plan. There are a few things you can customize, like custom roles, time-based (JIT) access, and Application Workflows — and they are gated to specific plans; each is called out below.

What it gives you

• One place to ask and to approve. Requesters use My Access; approvers use Approvals. Both live in the YeshID app, and both are reachable from Slack.

• Rules you set once, per application. Which roles or groups can be requested, who has to approve, whether a request is staged for review before it runs, and how long access lasts are all configured on the application, not re-decided per request.

• Automatic provisioning. An approved request doesn't just change a status — it kicks off a workflow that actually creates the account, and can run extra steps you've defined for that application (see Adding extra provisioning steps with Application Workflows).

• A record for audits. Every request keeps who asked, who approved or denied it, when, and why — the same trail RBAC and access reviews rely on.

Key terms

Submitting a request

In the YeshID app:

1. Go to My Access and select New request.

2. Choose Access to application (or New application, if your organization allows requesting apps that aren't in YeshID yet).

3. Pick the application. If you already have access, the form opens as Request more access and shows what you currently have — a role request replaces your current role, while a group request adds on top of it.

4. Fill in whatever the application's owner has configured: a role, groups, a reason, and any custom fields. If the app offers time-based access, choose a start time and a duration (or leave it open-ended, if that's allowed).

5. Select Submit request.

If the application needs no approval, you'll see a confirmation that it's already being provisioned. Otherwise you'll see who it's waiting on, and a notification when it's decided.

In Slack: run /access-request (or /yeshid access-request) to open the Request an Application modal, choose the application and any details, and submit. You'll get a Slack reply confirming submission, and another when it's approved or denied.

If you can't find a Role field when requesting an app you'd expect one for, ask an admin to check the application's Access requests settings — the field may have been removed from the request form, or no roles may be marked requestable.

Acting on a request

Approvers see requests waiting on them under Approvals, or via a direct Slack notification. From either place, an approver can:

• Approve — moves the request into provisioning.

• Reject — records a reason and stops the request there.

• Nudge — reminds the other people a request is waiting on.

Requesters and approvers can also comment back and forth on a request before it's decided — useful when an approver needs more context before approving.

Once every required approval is in, the request moves into provisioning: YeshID creates the workflow that actually grants access (see below), and the requester is notified once it's set up.

Configuring access requests for an application

Each application has its own Access requests settings (Access > Applications > the app > Access requests), where an admin controls:

• Approvals: which group(s), if any, must approve requests for this app (Technical Owners, the requester's manager, or a named group). Leave this empty and requests approve themselves.

• Workflow start: whether an approved request runs immediately, is always staged for review, or follows your org's default.

• Request fields: which fields appear on the request form, and in what order (role, groups, reason, and any custom fields).

• Time-based access (Business plan): the specific durations (e.g., "3 days", "1 week") people can choose from, and whether picking a duration is required.

Requestable roles

An application can define a fixed list of roles rather than leaving role free text. Each role can be marked as requestable independently, under the application's Roles tab — the request form only ever offers roles marked Users can request role: Yes. Creating and editing custom roles is available on Growth and Business plans.

Time-based access

When an application has time-based access enabled, a request can carry a duration instead of standing access. Access starts when the request is actually granted (not when it was submitted, so approval delays don't eat into the window) and is automatically wound down when it expires — either removing the account or restoring whatever role the person had before, depending on what they had going in. An approver can also adjust how long a specific request's access lasts before approving it, and holders are notified before their access expires so they can ask for an extension if they still need it.

Adding extra provisioning steps with Application Workflows

Approving an access request always creates an Add user to application task to provision the account. If the application needs more than that — a Slack notification to a channel, a custom script action, adding the person to an external group, anything else your integration can do — you don't have to build that per request. You configure it once, on the application, as an Application Workflow, and every future access request (and onboarding, and any other flow that provisions the app) picks it up automatically.

1. Go to the application and open its Workflows tab (Access > Applications > the app > Workflows). This tab requires the Application Workflows entitlement — talk to your YeshID contact if you don't see it.

2. You'll see two rows: Add user to application (runs on provisioning) and Remove user from application (runs on deprovisioning). Select the pencil icon on either to edit it.

3. Build the steps in the workflow editor, the same editor used for onboarding and offboarding templates. Add whatever tasks the app's provisioning needs beyond the base account creation — a notification, a custom action, a follow-up approval, and so on.

4. For the Add user to application workflow, make sure it actually includes a Create user in application task somewhere in it (and the Remove user from application workflow should include Delete user in application) — otherwise YeshID warns you that the workflow won't actually provision or remove the account, since nothing in it creates or deletes the user. You can add the missing step directly from that warning, or save anyway if you're intentionally leaving it out (for example, because a separate step already handles account creation).

5. Turn the workflow on with its toggle. It has to be both enabled and (for provisioning) contain the account-creation step to actually run.

6. Select Save.

Once saved and enabled, that workflow runs as hidden extra steps under Add user to application (or Remove user from application) any time the application is provisioned or deprovisioned through a workflow — an access request being approved, someone onboarding into the app, or a manual grant — with no extra setup per request.

If you'd rather see those steps explicitly in a specific template you're building (for example, an onboarding template), some workflow editors offer an Add integrated action button with a Workflows section listing the app's configured workflow by name and step count — selecting it inserts the same steps directly into that template, instead of leaving them to expand invisibly at run time. This surfaces the same underlying Application Workflow either way; it's just a more visible way to add it to one specific template. (This explicit insertion option may not be available in every environment yet — confirm with your YeshID contact if you don't see it.)

How access requests work with RBAC

If your organization uses RBAC, it can shortcut the approval step entirely: a request that's already covered by a matching RBAC policy is auto-approved (for a Lazy policy, since the policy already says the person is allowed to have it) or auto-rejected (if the app is restricted to policy-driven access only and no policy covers them) without anyone having to act. Access requests and RBAC are meant to complement each other — RBAC for access you already know people should have, requests for the exceptions and one-offs.

The "Monitored by RBAC" checkbox

On an application's Settings tab (visible when your organization has RBAC), you'll find a Monitored by RBAC checkbox. Turning it on does two things:

• It restricts who can request the app, and auto-decides them. Only people already covered by an enabled RBAC policy for that application can request it — and because a policy already says they're allowed to have it, that request is auto-approved. Anyone requesting the app without a matching policy is auto-rejected.

• It's also what makes the app eligible for RBAC's drift-based revocation. If someone ends up with access to the app who isn't covered by any policy, RBAC only flags it as over-provisioned drift — and only offers to remove it — for applications where this checkbox is on. This half isn't mentioned in the checkbox's own tooltip, so it's easy to turn on "Monitored by RBAC" expecting request-gating and be surprised later that it's also the switch controlling whether that app's drift gets flagged for removal at all.

If you enable an RBAC policy for an app and expect YeshID to start cleaning up access that falls outside it, make sure Monitored by RBAC is checked on that application — an RBAC policy alone does not revoke access on apps where it's off.

Notifications

Requesters get a notification (in the YeshID inbox, Slack, or Teams, depending on how your organization is set up) when a request is submitted, each time it moves forward toward a decision, and when it's finally approved or denied — each one naming who it's waiting on or who decided it. Approvers are notified when something needs their action. A separate email is also sent for the same milestones; if you notice the in-app/Slack notice and the email disagree, treat the in-app one as current and let YeshID Support know.

Tips and good habits

• Mark roles requestable deliberately. An unmarked role simply won't appear on the request form — that's often the fix when someone says they can't find the option they expect.

• Use staging while you're setting up a new application's access requests, so you can watch the first few approvals run before letting them provision immediately.

• Put shared provisioning logic in an Application Workflow, not in every place that grants the app. If three different flows (onboarding, access requests, RBAC remediation) all need the same extra step, configuring it once on the application is what keeps them all in sync.

• Use time-based access for anything that shouldn't become permanent by default — vendor access, elevated roles, anything you'd otherwise have to remember to revoke.