​You can use the the new CSU Employee Job Summary page if you share an employee with another CSU campus. You can see job data information and benefits information. ​You can also continue to use the QuickSight Benefits Employee 360 View Dashboard if you share an employee with another CSU campus. You can see job data information and benefits information.

The SSN field for dependents is not required, but it is preferred. This field may be left blank, or populated with either an SSN or an ITIN.

Ben Admin determines all benefit plans, including medical, that an employee is eligible for. The employee's home address and work location zip code and state is included in the benefit eligibility determination, just like in HR9.0. There's no change in how Ben Admin determines an employee's benefits eligibility as a whole between 9.0 and CHRS. The eligible benefit plans are listed inside the Medical ESS tile, and the employee would then select which medical plan they want.

Daily security provisioning queries grant the employee Benefits ESS access to the employee based on the employee's primary benefits campus. The Benefits office does NOT manually give the employee ESS access.​ 

Ben Admin determines benefit eligibility using both the employee’s home and work zip code/state, similar to HR 9.0. Eligible plans are listed inside the Medical ESS tile, from which the employee selects their plan.

Use the On-Demand Event Maintenance page, which allows processing of single events for one person, making it ideal for urgent or retroactive changes

It serves as a queue of pending Benefits Administration (BAS) events that have been triggered (e.g. from Job Data changes, manual entry, etc.) but have not yet been processed by the system. You can review, delete, or manually add events here before they go through automatic or on-demand processing.

Some event types are processed always; others are automatically deleted if they do not affect benefit eligibility. For example, miscellaneous changes (MSC), action changes (ACT), etc., if they don’t change anything relevant (like FTE, employee class, benefit primary job) will be dropped by the nightly process.

Yes, campus Benefits Office staff can manually insert BAS events via the Review BAS Activity page (using an “Add New Row” icon) and can also delete events that shouldn’t be processed (using a delete icon). 
But there are restrictions:

• Some event classes (like TER, HIR, many eBenefits ESS events except NEW) cannot be manually created.
• There are rules about which campuses use which event (for example, full eBenefits ESS vs. view-only).

1. Select your business unit (if you have access to more than one) to view the relevant events.
2. Use “View All” to see all events awaiting processing for the campus.
3. Sort data by clicking column headers, search for specific employees by name or EMPLID, etc.
4. Export the BAS activity table to Excel via a download functionality

A “Process Status” reflects where a BAS Event is in the Benefits Administration (Ben Admin) processing pipeline after it leaves the Ben Admin queue. It helps users and administrators understand whether the event is proceeding normally, has errors, or needs manual intervention.

Event Status shows whether a BAS Event is open, closed, voided, or disconnected. Closed, voided, or disconnected events are ignored by Ben Admin.

Event Status refers to whether a BAS Event is open, closed, voided, or disconnected. These statuses control whether the Ben Admin process will act on the event. In contrast, Process Status describes where the event is in its internal processing journey.

Process Indicator shows how far the system should process or reprocess a BAS Event in the next Benefits Administration run. It is assigned when the BAS Event leaves the Ben Admin queue.

There may be times in CHRS where the ACT BAS event remains at a PR (Prepared processes status) and the Campus Benefits Officer must select the valid option (the applicable benefit plan or waive) and then finalize the event in the On Demand Event Maintenance page. The ability to waive default benefits is new in CHRS.

The On-Demand approach replicates the same backend steps as the nightly batch but is designed for single-person, single-event use—making it efficient for emergencies, though not suited for bulk processing.

The individual's primary job record must be validated (especially in cases of multiple jobs), and it must be confirmed that the participant meets service duration requirements—both checked through On-Demand Pre‑Processing functionality.

The OE (Open Enrollment) BAS event is used to process benefit elections and changes during open enrollment across all campuses, whether in Full eBenefits Self Service mode or View-Only mode.

During Open Enrollment, BAS:

• Determines each employee’s benefit program and eligibility
• Prepares eligible benefit options
• Processes and finalizes benefit enrollments

Full eBenefits campuses typically rely on nightly batch processing (CSUBASOE) and do not usually use On Demand pages. View-Only campuses often finalize manually via the On Demand Event Maintenance page after documentation is approved.

Depending on the type of error, the election may need to be rolled back by setting it to Re-enter, then updating and reprocessing it in the On Demand Event Maintenance page until finalization. Please refer to the Benefits Troubleshooting document for guidance on the specific error and the appropriate next steps.

Remaining OE BAS events that haven’t been finalized are force-finalized via the Benefits Admin COBOL process (PSPBARUN) for each schedule ID

Event coordination ensures only one BAS event per employee is processed at a time and maintains correct sequence based on effective date, priority, and event ID so that events don’t conflict.

Yes. Some CSU rules require action annually—for example, employees must re-enroll in Flexible Spending Accounts (FSAs) each year or their coverage is canceled.

CSUBASOE is a seasonal scheduled job that runs nightly during Open Enrollment to assign BAS Group IDs, create OE events, process and finalize elections, and coordinate other Open Enrollment tasks.

Campuses must define their OE employee population (via BAS GROUP ID), set up OE Schedule IDs with an “O” designation, maintain OE definitions (plans, rules, dates), and configure activity guides and disclosures.

No — BAS processes only one event per employee at a time, following a logical sequence and precedence.

The process extracts an Oracle/PeopleSoft HIPAA EDI 834 file containing dental benefit enrollment data for active employees and their dependents (Delta Dental PPO or DeltaCare USA) and transmits it electronically (via SFTP) to Delta Dental.

Monthly, the interface file must be generated and securely transmitted to Delta Dental no later than the 5th of each month by 3:00 pm, reflecting enrollments from the previous month.

Once per year in December, a “Changes Only” file is generated capturing updates effective January 1 of the next year. It also must be transmitted by the 5th of December by 3:00 pm.

If a campus doesn’t send a valid, error-free file, all employees and dependents from that campus could be considered terminated, causing loss of dental coverage.

Campuses are strongly encouraged to complete processing before the 5th of each month, allowing time to review and correct potential errors before transmission.

• Daily: Review and resolve any CSU Snapshot Unique Constraint errors; ensure the nightly Refresh Benefits Snapshot process ran successfully.
• Monthly (Four‑Step Process):
  1. Verify no unique constraint errors
  2. Verify successful nightly snapshot
  3. Run the HIPAA EDI 834 process (CSUBB012)
  4. Upload the file securely via SFTP to Delta Dental

The process involves handling Level 1 (confidential) and Level 2 (internal-use) sensitive data, and must adhere to CSU security and HIPAA policies. After transmission, the file must be securely stored, and purged within 60 days

Delta Dental validates each file and sends secure emails to campus contacts if errors are found. The campus must correct the errors in CHRS, re-run the interface, and resubmit a full file replacement no later than 3:00 pm prior to the 20th of the month.

Benefit data: new enrollments, coverage codes, plan details, dependents, terminations (e.g., hire, rehire, retirement, job termination)

Personal data: employee/dependent addresses, gender, birth date, smoker status, marital status, student status, etc.

For Open Enrollment Changes Only files:

• Set As Of Date, File Effective Date, File Enrollment Date, From Date, and To Date all to 01/01 of the upcoming year
• File Type must be Update Only File
  These settings ensure only changes effective January 1 are captured.

It automates data exchange between CSU and CalPERS for payroll, retirement, health enrollment, COBRA, and retiree dental information using permitting event codes and related enrollment pages

Address Line 1 allows up to 30 characters. Address Lines 2 and 3 are combined and must also stay within 30 characters total, or the system returns an error.

Assign permitting event code 610 to the BAS event via On-Demand Event Maintenance. Avoid using the CSU Hlth Perm Evt page for this; apply via BAS event maintenance to ensure rows are suppressed.

Because systems can’t handle multiple event codes per plan type on the same day, send only one permitting event daily: audit inserted codes, delete all but one via On‑Demand Event Maintenance, run the outbound interface, then repeat for remaining events on subsequent days.

Contact CalPERS directly. Once CalPERS manually processes the transaction and issues a CalPERS-dependent ID, update CSU CalPERS ID Table accordingly via Benefits → Interface with Providers → CSU CalPERS ID Tbl.

Required documentation for dependents must be collected per verification cycles: annually or every three years based on dependent type. Enter verification via Benefits → Employee/Dependent Information → CSU Dependent Verification, using permitting codes (907, 913, 220) with specific event dates relative to employee birth month. Verified dependents move to history and no longer appear on the current verification page.

It provides a high‑level overview for electronically generating interface files—specifically for Vision, Life/AD&D, and Long‑Term Disability (LTD) enrollments or terminations—and transmits these via FTP to the State Controller’s Office (SCO) on a monthly basis.

Files may be transmitted between the 1st and the 16th of each month, and they must be sent by 11:00 A.M., excluding “NO CYCLE” days or state holidays.

Three deduction types are used:

• Add — for new benefit deductions
• Delete — when deductions should be removed (e.g., terminations or ineligibility)
• One‑Time — used for retroactive transactions and FERP annual deductions

The interface includes:

• Plan Type 14 – Vision
• Plan Type 20 & 23 – Life and AD&D
• Plan Type 31 – Long‐Term Disability (LTD)

There are two modes:

1. Preliminary – generates six reports (ongoing & retro for Vision, Life/AD&D, and LTD) for auditing.
2. Final – produces the same reports plus six interface extract files and writes deductions to the CSU SCO History table.

Files start with TRN, followed by a character:

• V — Vision file
• VR — Vision retro file
• B — Life file
• BR — Life retro file
• L — Disability file
• LR — Disability retro file

Initial one‑time annual deduction appears on both Preliminary and Final files if Deduction Begin Date is within the period.

Subsequent one‑time annual deductions must be sent via a separate CSU FERP Vision Deduction process prior to generating the Final interface.

Use the CSU SCO Interface Inquiry page, locate the relevant transaction for an employee’s vision plan, select “Resubmit Transaction,” and save. It will then be included in the next interface run.

When a QMCSO is received, the campus Benefits Office determines if the employee is benefit-eligible. The campus that owns the employee’s Benefits Primary Job is responsible for:

• Contacting the employee
• Reviewing benefits options with them
• Ensuring QMCSO enrollment is completed by the court-ordered deadline
• Entering the enrollments into CHRS

• If the employee is eligible but not enrolled, enroll the employee and dependent(s) in medical, dental, and vision plans using the HBE BAS event in On Demand Event Maintenance.
• If the employee is in Medical Flex Cash or Dental Flex Cash and QMCSO requires medical and dental coverage:
  • Dis-enroll from Flex Cash
  • Enroll in Medical and Dental plans
• Default plans if no election made by deadline:
  • Medical:
    • PERS Platinum for out-of-state dependents
    • In-state dependents: plan depends on county of residence
    • If no election made, assign PERS Platinum
  • Dental:
    • Delta Dental PPO for out-of-state dependents
    • In-state dependents: plan depends on county of residence
    • If no election made, assign Delta Dental PPO
  • Vision:
    • Enroll dependents if the plan is available to the employee

• Campus Benefits Office contacts the employee by email.
• CalPERS also sends notifications by US Postal Service.

• If both spouses are CSU employees, dependents can be enrolled under the spouse’s CSU coverage.
• If the employee informs the Benefits Office before the QMCSO deadline:
  • They can be dis-enrolled from the spouse’s plan.
  • They and their dependent(s) are then enrolled in the appropriate plans or the default plans.

This report shows errors and warnings by BAS Schedule ID, EmplID, error description, and cause. Review and resolve them daily.

It lists BAS events flagged due to things like address or eligibility changes, disconnected events, or out-of-sequence events.

It displays open BAS events (excluding closed/disconnected/void events). Useful to:

• Track events not finalizing.
• Handle open events in error (“EE” or “PE”).
• Monitor “Assigned” (AS) events awaiting prior event completion.

It captures changes in employee benefits-related data over the last 30 days or a specified range. Includes fields like medical/dental/vision plans, FTE, employee class/type, pay group, job code, benefit program, etc. Mainly used to verify if benefit changes occurred correctly. 

This report displays upcoming or recent benefit terminations for specific plan types, based on coverage begin/elect dates. It includes rehires within 30 days, job eligibility checks, and active job status. Use it for auditing terminations and benefit status