Degree Works

Link to library

Video 1

Banner/SIS (Student Data)

Roles are not assigned directly in DW, but rather extracted from Banner.

• REG users – highest level of authority.

Periodic bridging - Banner course catalog (DW Course Master), equivalency extract

Data bridge = extract

Configuration and validation tables

• How do we want to treat the data when the auditor creates an audit for X school?

• These settings can be changed

At install, several validation tables were loaded. Extracted ONCE. Degree, major, concentration, minors, cy, ct, program codes. Because when the tables are changed, if extract is run again, all settings would be lost.

Controller

Used to access Banner tables

Scribe

Foundation of the audits

Responsive dash

Looking at an audit, processing exceptions. Refers to the latest version of what the audit looks like

• Petitions, notes, exceptions, SEPs

DAP22/Auditor

The process that generates the audit (process button). When you click process, it runs a new audit. Pulls together from RAD, DAP, and UCX tables.

RAD tables

Anything that comes from Banner lives in a RAD (Repository Audit Data) table in DW. SIS → RAD

DAP tables

Anything added directly to the database lives in DAP tables (Degree Audit Process). Scribe, exceptions, SEPs. Scribe/responsive dash → DAP

UCX tables

Where validation and configuration tables are stored. Universal Code Extension. Controller → UCX

Composer

Modify what the web looks like; institution branding. Separate log in.

Transit

Also separate log in. Batch reports and processes.

4 sites

Responsive Dash, Controller, Scribe, Transit

When does DAP22 run in the timeline of when data is extracted?

• Process run every single night (“Banner extract student”) which goes to Banner to bring in new students and identify changes for existing students.

• When the student data is updated in RAD, it kicks off DAP22 which is the algorithm to run a new audit. A new audit is generated when the Banner data we’re bridging for a student is updated. (grades posted, major changed)

• If nothing changes, you don’t get a new audit.

  • Refresh timestamp shows the last time DW asked Banner if there were any changes.

  • Hover over date refreshed and you can see the last time there was a Banner data change that was fed to DW.

  • Historic audit dates - Every time process button is clicked

• does it also include data changes fed to DW?)

(time stamp: 25:12)

• If Scribe is changed, the nightly process will not generate a new audit - only does it if Banner data changes.

Nightly: Courses, equivalencies, curric rules (what-if) extract - extracted to UCX and RAD tables

Nightly: Student changes extracted to RAD tables

• If there are changes, a new audit is run

• If no changes, no new audit run

Validation tables from Banner - one time ever - extracted to UCX tables

Degree Works URLs

Configuration

STU307 Degree code table (STVDEGC)

• Ordered according to the key

• Can manage codes on DW side, doesn’t feed back to Banner.

• Can remove what we don’t use/don’t teach. For example, if we’re pulling in degrees faculty have earned (if we use Banner HR), we could remove those degrees.

• These degree values can be used in search - all search values come from STU307 table.

• For each degree, you can choose whether to show as option in SEP pick list, TA SS pick list, what-if pick list, adv search pick list (if it’s blank, it assumes Yes)

Student Card (time stamp 1:16:05)