Access Requests with YeshID

Access Requests let the people in your organization ask for access to an application, and let the right approvers grant or deny that access — all without a ticket, a spreadsheet, or a back-and-forth in DMs. A request can be made from Slack or from the YeshID app, it routes to whoever you've designated as an approver, and once approved YeshID runs the workflow that actually provisions the account. Every request, comment, and decision is captured for auditing.

Access Requests are a good fit when you want employees to self-serve access to tools, but you still want a clear, reviewable approval step (and a record of who asked for what, why, and who said yes) before anyone gets in.

What it gives you

• Self-service access: employees request the apps they need from Slack or the app, instead of filing a ticket.

• A real approval step: requests route to the approvers you choose (technical owners, managers, or named groups), in the order you choose.

• The context you need to decide: requesters pick a role, give a reason, and answer any custom questions you require, so approvers aren't guessing.

• Time-boxed access: optionally require that access is granted only for a set duration, after which it's removed automatically.

• An audit trail: the role, reason, custom-field answers, and the approve/deny decision are all recorded.

Key terms

How a request flows

1. A person submits a request (from Slack or the app), choosing the application, a role if applicable, a reason, and answering any custom fields. If time-based access is enabled, they also pick a start time and duration.

2. YeshID routes the request to the app's approval groups in priority order.

3. Approvers get a notification (in Slack and in the app) and either approve or deny. They can comment back to the requester first if they need more detail.

4. Once every required approval is granted, YeshID kicks off the workflow that provisions the account with the requested role.

5. The requester is notified of the outcome, and the app appears in their My Apps.

Requesting access

In Slack

1. In Slack, type /request and press Enter.

2. Fill in the form:

   • Requesting for: yourself by default. (Admins can request on behalf of another person.)

   • Select application: pick the app you need. If it isn't listed, use Or request a different app to request one that isn't in YeshID yet.

   • Select role: choose a role if the app has requestable roles (this is optional; a default is used if none is set).

   • Reason for your request: a short justification.

   • Custom fields: answer any additional questions the app requires.

   • Time-based access: if enabled for the app, set Start date, Start time, Timezone, and Access duration.

3. Submit. You'll get a confirmation that your request was sent.

4. If an approver has questions, you'll be notified in Slack and can respond in the thread.

5. When the request is approved (or denied), you'll get a Slack notification with the outcome.

In the YeshID app

1. Go to My Apps from the left-hand menu.

2. Click Request an application.

3. Select the application you're requesting. To request something not listed, type its name and choose Add new app ___.

4. Complete the request:

   • Select your role (if the app has requestable roles).

   • Enter a reason for the request.

   • Answer any custom fields the app requires.

   • If the app uses time based access, set your start date/time and duration.

5. Click Submit request.

6. Track the request from My Apps. If there are comments from an approver, you'll see an indicator; click the application to read and respond.

7. When it's approved, the app moves into your My Apps.

Approving and actioning a request

Approvers can act on a request from Slack or from the YeshID app. Whoever is in the app's approval groups gets notified.

In Slack

You'll receive a task notification from YeshID in Slack. From there you can:

• Click Complete task to approve the request. This advances the request and, once all required approvals are in, kicks off provisioning.

• Click Reject task to deny it. A Reason is required when rejecting.

• If there's follow-up work or you want the full context, click the link in the message to open the request in YeshID.

In the YeshID app

1. Open the request — either by clicking the link from the Slack notification, or by going to the Workflows page and filtering by Workflow Type → Access Request (you can also search workflows by name, person, status, assignee, or type).

2. If the app has multiple approval groups, they appear in priority order under the approval list. Click into the request to comment with the requester if you need more detail before deciding.

3. When you're ready, click Approve (or reject). Approving advances the request to the next group, or — if you're the last required approver — kicks off the workflow that adds the user to the application with their requested role.

Setting up access request settings (admins)

Access request behavior is configured per application. Open the application in YeshID and go to its Access Requests tab. From there you can set up approvals, requestable roles, custom fields, and time based access.

Approvals — who signs off

Under Approvals, define the approval workflow for the app by adding approval groups in priority order. A requester must be approved by each group, in order, before they get access. Click + Add Group and choose a type:

Drag groups to reorder them; the order is the sequence approvals are requested in. Use more than one group when you want layered sign-off (for example, Manager first, then Technical Owners).

Requestable roles

Roles control what level of access a requester is asking for, and the choice is recorded for auditing. On the application's Roles settings:

1. Add or edit a role.

2. Turn on Users can request role.

Only roles with Users can request role enabled appear in the role dropdown when someone requests the app (in Slack or the app). If no requestable role is set, a default is used.

Custom fields

Custom fields let you collect extra information on every request — a justification, a system name, a cost center, and so on. On the Access Requests tab, under Fields:

1. Click + Add Field.

2. Give the field a name and pick a type:

   • Text — free-form text.

   • Dropdown (single select) — one choice from a list of options you define.

   • Dropdown (multi-select) — one or more choices from a list you define.

3. For the dropdown types, add your selection options.

4. Turn on Make this field required in access requests if an answer is mandatory.

Custom fields appear in both the Slack form and the app's request form, and requesters' answers are recorded with the request.

Time based access

Time based access grants access for a fixed window instead of indefinitely. On the Access Requests tab, under Time based access:

• By default, access duration is Unlimited unless you set time-based options.

• Click + Add timeframe to define the durations requesters can choose. Each timeframe is a number plus a unit — hours, days, or weeks.

• Use Allow unlimited access time frame to control whether requesters may also choose unlimited access, or must pick a fixed duration.

When a request with time based access is approved, access is granted starting at the requester's chosen start time. YeshID automatically schedules the removal for when the duration expires — at that point it runs a task to revoke the granted access (removing the user from the application, or reverting them to their prior role). For applications connected with a deactivate, delete, or remove-user action, this happens just-in-time in real time, so access is pulled the moment the window ends without anyone needing to remember to clean it up.

A note on group-based apps

Some applications are set up so access is granted through application groups rather than directly. If an app is configured with Only access via groups, requests grant access by adding the person to the appropriate group. This is set on the application's main details, not the Access Requests tab.

Tips and good habits

• Start with the approver you'll actually use. For most apps, Technical Owners or Manager is enough. Add layered groups only where a second sign-off genuinely matters.

• Require a reason and any must-have custom fields. A one-line justification and a required field or two turn approvals from guesswork into a quick yes/no.

• Use time based access for sensitive or short-term tools. It removes access automatically, so you don't rely on someone remembering to clean up.

• Name requestable roles clearly. The role a person picks is what shows up for the approver and in the audit log — make it obvious.