Skip to main content

Pending Requests

When users submit access requests for a knowledge base you administer, you review them on the User Requests page.

Who sees this​

The User Requests page (/user-requests) is visible only to people who are an Owner of at least one knowledge base. If you don't see the link, you're not an admin of any KB.

How to open it​

🔔 Click the notification bell in the top-right header → User Requests.

What you see​

A table with one row per request across every KB you administer:

ColumnMeaning
UserThe requester's display name
ApplicationThe knowledge base they want access to
StatusA coloured chip — pending (grey), approved (green), rejected (red)
ActionApprove / Reject icons — only visible on pending rows

Older approved or rejected requests stay in the list for reference and audit.

Approving a request​

  1. Find the request in the table (filter by Status = pending if there are many).

  2. Click the green ✓ checkmark in the Action column.

  3. A confirmation dialog appears:

    Are you sure you want to approve request of the user {user name}? This will grant the user access to the application.

  4. Click Confirm.

What happens:

  • The request's status becomes approved.
  • The user's Entra OID is added to the KB's assigned_user_oids list.
  • The user receives an email: Access Granted: {KB name} with a button to open the KB.
  • The user can immediately chat with the KB (on next request).

A toast confirms: "Request approved".

Rejecting a request​

  1. Find the request.

  2. Click the red ✗ in the Action column.

  3. A confirmation dialog appears:

    Are you sure you want to reject request of the user {user name}? This will deny the user access to the application.

  4. Click Confirm.

What happens:

  • The request's status becomes rejected.
  • The user receives an email: Join Request Update: {KB name}.
  • The user's access does not change.

A toast confirms: "Request rejected".

No admin note

The current UI does not have a free-text field to attach a reason when approving or rejecting. Users only see that you approved or rejected — they don't see your reasoning. If you need to explain a rejection, send a separate email.

What if another admin already acted?​

Multiple admins on the same KB can review requests independently. If two admins click Approve almost simultaneously, only one wins — the other will see an error:

Join request was already processed by another reviewer

Refresh the page to see the current status.

Notification emails to admins​

When a user submits a join request:

  • The KB creator is on To: of the notification email
  • All other admins of the KB are on CC:
  • Subject: Join Request: {KB name}

Any one admin can approve or reject — there is no quorum requirement. The action takes effect for everyone.

Email-disabled environments​

If your environment doesn't have email configured, users can't submit join requests at all (they get a "Mail service not enabled" error). So if you're an admin and never see any pending requests, the most likely reason is that email is off in your environment — contact Support.

Cleaning up old requests​

Old approved/rejected requests stay in the table. There is no UI button to delete them. If the table gets cluttered, contact Support to bulk-purge old records.