User Requests

The User Requests feature allows administrators to manage the intake of new users and the return of inactive ones. This centralized dashboard ensures that every person gaining access to the platform is vetted, assigned the correct permissions, and linked to a valid sponsor where necessary.

As an administrator, you can use this page to approve or deny pending requests, view historical review notes, and set account expiration dates to maintain system security.

Page Overview

• Purpose: To act as a gatekeeper for platform access by reviewing registration and reactivation applications.
• When to use it: Use this page when you receive notifications of new sign-ups or when an existing user needs their account re-enabled.
• What you can do here:
  • Filter requests by type (New User vs. Reactivation).
  • Search for specific requesters by name, email, or sponsor.
  • Review the "Reason for Access" provided by the user.
  • Assign roles and set account expiry dates during approval.
  • Provide feedback to users via review notes.

Page Layout

• Top bar: Displays the page title and a brief description of the management tasks.
• Main area: Contains the search and filter bar at the top, followed by a table listing all requests with the columns Type, Name, Email, Sponsor, Status, Requested and Actions.
• Review Dialog: A pop-up window that appears when you click "Review" or the "View" icon, containing the full details of the request and the decision-making form.

Main Features

Request Filtering and Search

• What it's for: Quickly locating specific requests among a large volume of entries.
• Typical use: Filtering the list to show only "Pending" requests to identify work that needs immediate attention.
• Result: The table updates in real-time to show only the records matching your search text or selected filters.

Request Review and Decisioning

• What it's for: Formally approving or denying a user's request for access.
• Typical use: Checking a user's "Reason for Access" and "Sponsor Email" before granting them a specific role in the system.
• Result: The user's status changes from "Pending" to "Approved" or "Denied," and they are notified of the decision.

Expiry Management

• What it's for: Setting a hard date for when a user's access should automatically end.
• Typical use: Granting temporary access to a contractor or guest user.
• Result: The account will be scheduled for deactivation on the selected date.

Detailed Feature Documentation

Search and Filter Bar

• Purpose: To narrow down the list of requests based on specific criteria.
• Where to find it: Located at the top of the main card in the center of the page.
• What you'll see: A search field, two dropdown menus for Type and Status, and a Search button.

How to use it:

1. Type a name or email into the Search by name, email, or sponsor... (Press Enter) field.
2. Select a value from the Filter by type dropdown (e.g., "New User").
3. Select a value from the Filter by status dropdown (e.g., "Pending").
4. Press Enter or click Search to refresh the list.
5. Click the X icon in the search bar to clear your search text.

Review Dialog

• Purpose: To view the full context of a request and submit an approval or denial.
• Where to find it: Click the Review button (for pending items) or the Eye icon (for processed items) in the Actions column.
• What you'll see: A window showing the user's details, their reason for the request, and (if pending) fields to select an action, role, and expiry date.

How to use it:

1. Click Review on a pending request.
2. Read the Reason for Access or Reason for Reactivation.
3. Select "Approve" or "Deny" from the Action dropdown.
4. If approving a new user, select a role from the User Role dropdown.
5. (Optional) Click the Account Expiry Date (Optional) field to select a date from the calendar.
6. (Optional) Enter a message in the Message to Requester (Optional) box.
7. Click Approve Request or Deny Request to finalize.

Complete Workflows

Workflow: Approving a New User

• Goal: Grant a new user access to the system with a specific role.
• Prerequisites: The request must be in "Pending" status.

Steps:

1. Locate the user in the table and click Review.
2. Verify the Sponsor Email. An orange alert icon means the address does not belong to a user of the workspace, and no notification was sent to it.
3. Ensure the Action dropdown is set to Approve.
4. Select the role from the User Role dropdown. Choosing a role other than the default role needs the Assign roles to users permission.
5. Click Approve Request.

• Expected result: The dialog closes, a success toast appears, and the user's status updates to "Approved" in the table.

Workflow: Denying a Request with Feedback

• Goal: Reject a request while explaining why to the user.
• Prerequisites: The Review account requests permission.

Steps:

1. Click Review on the relevant request.
2. Change the Action dropdown to Deny.
3. In the Message to Requester field, type the reason for the denial (e.g., "Invalid sponsor email provided").
4. Click Deny Request.

• Expected result: The request status changes to "Denied," and the message is saved in the Review Notes.

Who can review requests

This page, and the approve and deny actions, need the Review account requests permission. It covers requests for a new account and requests to reactivate an account. Without it, the page is not listed in the Administration menu and its address is refused.

Two kinds of people are told by email when a request arrives:

1. The sponsor named on the request, when the requester gave a sponsor email.
2. Members of the user accreditation reviewer group, when a group is set for it in System Settings.

The email links straight to the request for recipients who hold Review account requests. A sponsor or group member who does not hold the permission is informed of the request but cannot approve or deny it, so give the permission to the role of the people who should decide.

Approving a request with the default role needs nothing more. Approving it with any other role also needs the Assign roles to users permission. An approval that would give a role with administration permissions is refused when your plan has no free administrator seat. See Role Management.

Limits and guardrails

• One decision per request: Once a request has been approved or denied, the review form is locked so the outcome cannot be silently changed. Reopening requires a new request from the user.
• Default account expiry: If you approve without setting an expiry date, the system applies the workspace default (90 days unless changed in System Settings). This prevents guest accounts from living on indefinitely by accident.
• Default assigned role: The Default Role set in Access Settings is pre-selected in the approval form, which speeds up routine approvals and reduces the risk of forgetting to set a role.
• Audit trail: The reviewer, the timestamp, and the review notes are always recorded against the request.

What happens behind the scenes

• New user approvals: When you approve a new-user request, a full account is created with the name, email, role, and expiry you chose. The requester is emailed a password-reset link - setting the password also verifies the email address, so no extra verification step is needed. A branded approval email tells them who reviewed their request and welcomes them in.
• Reactivation approvals: For a returning user, the existing account is re-enabled with a refreshed expiry date, and an approval email is sent.
• Denials: The requester receives a denial email, and any message you typed in the "Message to Requester" field is included so they understand the reason.

Tips and Best Practices

• Sponsor Verification: If you see an orange alert icon next to a Sponsor Email, it means that email is not currently in the system and the sponsor was not notified. Double-check the spelling before approving.
• Default Expiry: If you leave the Account Expiry Date (Optional) field blank during approval, the default expiry period applies (90 days).
• Sorting: Click the Requested column header to sort by date, helping you find the oldest pending requests first.

Troubleshooting

Issue: Cannot find a specific request

• Symptoms: The table is empty or the expected user isn't appearing.
• Cause: Active filters are hiding the record.
• Fix: Click the reset button, or set both filters back to Filter by type and Filter by status and clear the search field.

Issue: Approve button is disabled or fails

• Symptoms: Clicking the button does nothing or shows an error toast.
• Cause: A required field, such as User Role for new users, has not been selected.
• Fix: Ensure all fields marked with a red asterisk (*) are filled out before submitting.
• Prevention: Always select a role from the dropdown for "New User" types.