Managing Database User Access

Summary

This stage is where you maintain the questions on the database request form and review faculty requests to access a database — deciding who is approved, denied, or sent back for revision, handling several people at once.

Body

RDLA User Guide · Stage 3 of 6

This stage is where you maintain the questions on the database request form and review faculty requests to access a database — deciding who is approved, denied, or sent back for revision, handling several people at once.

Maintaining the database request form questions

Before any faculty member can request access, someone has to decide what they are asked. The database request form is that set of questions — the very answers you will review and approve later in this guide. This part of the tool lets you maintain those questions: review the ones in use, retire ones you no longer need, and add new ones.

The request-form questions screen

You work on a single screen headed with the instruction: “Review and edit existing database request form questions, expire ones no longer needed by setting Valid To Date/Time, or add new ones below.” The existing questions are listed for you to edit in place, and you can add new ones underneath.

Adding or editing a question

For each question you add or edit, you can set the following. Required fields are marked.

  • Question Type — pick the kind of question from the dropdown. Required.
  • Question Display Text — a friendly label shown to the faculty member. Optional.
  • Question Text — the actual question wording. Required.
  • Picklist Options — for picklist-type questions only, list the answer choices here. Optional.
  • Valid From Date/Time — when the question starts appearing on the form. Required.
  • Valid To Date/Time — when it stops appearing on the form (see the Golden rule below). Required.
  • Order — the position of the question on the form, as a number. Optional.
  • Required — tick if the faculty member must answer this question. Required.
  • Display on Form — tick to show this question on the form. Required.

Golden rule

To retire a question, don’t delete it — set its Valid To Date/Time to now or a past date. The question simply stops appearing on the request form from that point on, while its record and any answers already given stay intact. For a question that should keep showing, set a Valid To Date/Time well in the future.

Finishing

When you finish, you’ll see the confirmation “Database request form questions have been successfully updated.” Your edits, expirations, and any new questions are all saved together.

Tip: The questions you set here are exactly what a faculty member answers when requesting access — and the answers you review and approve later in this guide, under “Working through the requests.”

Walkthrough:


Before you start

This tool opens from the database record (typically from a button or action on the record page) and opens in its own screen.

Nothing is saved until you click Finish — you can close the window at any time to discard changes.

What this tool does

It shows the faculty who have requested access to the database, grouped by where their request stands, and lets you set each requestor’s Database Request Status — approving, denying, or sending requests back for revision — for several people at once.

Getting started

Open the access tool from the database record. You land on the User Decision screen, which shows Database: (the database name) at the top, a short set of instructions, and the status buckets below.

Golden rule

Nothing is saved until you click Finish. You can close the window at any time to prevent changes from being saved.

Working through the requests

The User Decision screen

The top of the screen names the database and tells you to “Select a Database Request Status below to view the faculty in that bucket.” From here you can:

  • View the Faculty Resource Access Met records for each database access requestor.
  • Update the Database Request Status for multiple records at a time.

Open a status bucket

  • Requests are grouped into buckets by status. Open a bucket to see the faculty in it: Not Submitted, Access Requested, Under Review, Needs Revision, Denied, Expired, and Approved.
  • Each bucket shows a Database Access Requestors card listing the people in that status.

Review a requestor

  • Each requestor row shows their Name, Resource Contact Name, Database Request Status, and Date Access Approved.
  • Expand a person to review their Faculty Resource Access Met answers — the Question Text, their Question Response, and whether the Criteria were Met — so you can judge the request.

Update status in bulk

  • Select one or more people (tick them in the card), then use the ‘Set Database Request Status’ control to set them all to the same status at once — for example moving several requestors to Approved or Denied together.
  • You can work through the buckets in any order and update as many people as you need before finishing.

Finishing

Click Finish to save your status changes and return to Salesforce. A confirmation reads “Your changes have been saved.” Click Finish again or close the screen to return to Salesforce.

What happens automatically — access expiration

You do not have to manually expire lapsed access. A background job runs every day and checks approved Database Users and Database Funders that are flagged to expire.

When a person’s End Date has passed, their status is automatically set to ‘Access Expired’ and the date is recorded. Those records then appear in the Expired bucket the next time you open the access tool.

Tip: You can reopen this tool at any time as new requests come in or circumstances change.

Walkthrough:

Details

Details

Article ID: 9155
Created
Thu 9/10/26 1:18 PM
Modified
Thu 9/10/26 1:26 PM

Related Articles

Related Articles (1)

Contains all documentation for the Research Database Lifecycle in Salesforce.