# Locked OPRID Scheduled Processes
LLMS index: [llms.txt](/llms.txt)
---
-
Target Database:
—
-
Context Type:
—
-
Alert Severity:
—
-
Triggered Time:
—
-
Firing Context:
—
## Locked OPRID Scheduled Processes Alert
**Alert ID:** `locked_oprid_processes`
**Category:** Process Scheduler
## What This Alert Detects
This alert finds queued or scheduled Process Scheduler requests where the submitting operator's account (OPRID) is currently locked in PSOPRDEFN (ACCTLOCK = 1).
When an operator account is locked after a process has been queued, PeopleSoft will refuse to run the process, or run it under the locked account and immediately fail. PeopleSoft does not surface this condition anywhere obvious: Process Monitor shows the job queued, the operator's user page shows them locked, but nothing connects the two. This alert does.
Common scenarios:
- A service or batch account had its password expire and was locked
- An employee left and their account was locked, but scheduled jobs were not transferred
- A security lockout from failed login attempts affected a batch account
## Severity Logic
All findings are reported at **Warning** severity. Every queued or scheduled process with a locked submitting account is flagged.
## What Gets Checked
The alert queries PSPRCSRQST joined to PSOPRDEFN for process requests in Queued or Scheduled run status where the submitting OPRID has ACCTLOCK = 1.
## Alert Details
Each alert item includes:
- Process name and instance number
- Submitting OPRID (with link to User detail page)
- Current run status (Queued, Scheduled, etc.)
- Scheduled run date/time
- Recurrence name (if applicable)
## Configuration
```yaml
alerts:
checks:
locked_oprid_processes:
enabled: true
excludeProcesses: [] # Process names to ignore
```
| Setting | Default | Description |
| ------------------ | ------- | ------------------------------------------------ |
| `excludeProcesses` | `[]` | List of process names to exclude from this check |
## How to Respond
1. Click the alert link to open the Process Monitor detail page for the affected instance
2. Identify the locked OPRID shown in the alert
3. Navigate to the User detail page to review the account lock status
4. Either unlock the account (if appropriate) or re-queue the process under an active operator account
5. For recurring processes, update the recurrence definition to use a non-locked operator
6. Investigate why the account was locked. If it was a failed login lockout, check the Failed Logins alert for additional context
## Tables Queried
| Table | Description |
| ---------- | ------------------------------------ |
| PSPRCSRQST | Process Scheduler request queue |
| PSOPRDEFN | Operator definitions (user accounts) |