​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

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 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.

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