A higher-education institution was preparing to move its on-premises Banner environment to Ellucian SaaS. As part of that transition, it needed to modernize a custom Banner process that identified graduation applications submitted after semester deadlines and prepared those students for downstream degree processing.

The workflow was important to Registrar operations, but its implementation depended on custom Oracle SQL, direct writes to Banner data and other on-premises components that could not move to the SaaS environment as-is.

Replace the custom late graduation processing mechanism with a Banner SaaS-compatible design while preserving the business rules and downstream degree processing that the Registrar still needed.

To achieve that goal, ABCloudz needed to separate the required business behavior from the legacy implementation and rebuild the selection logic around Banner Native Population Selection, Banner’s rule-based mechanism for defining criteria used to extract sets of IDs for downstream reports and processes. The new design had to preserve the institution’s term-specific late application workflow while replacing the custom on-premises mechanism with a supported Banner pattern.

RELATED BLOG POST: For another Banner modernization connected to TouchNet, this time focused on custom student billing, statement generation and downstream billing distribution, see Modernizing custom Banner student billing with TouchNet for Ellucian SaaS.

Why the existing late graduation process could not move directly to SaaS

The institution used a custom Banner Job Submission process to handle graduation applications received after established semester deadlines: March 15 for Spring, July 15 for Summer and November 15 for Fall. Banner Job Submission is the framework used to submit and run Banner reports and processes.

The process read graduation application records from Banner, identified students who met the late-application criteria and placed them into separate Spring, Summer and Fall populations. Those populations were then passed to Banner’s delivered degree-processing job for downstream updates.

The business workflow still mattered. The problem was its custom implementation.

The custom process ran as an Oracle SQL job. It read directly from Banner graduation data, inserted and deleted population-selection records in Banner tables, depended on custom utility functionality and generated reports through SQL*Plus, Oracle’s command-line and batch SQL tool. Those dependencies made the customization unsuitable as the institution moved to Banner SaaS.

The challenge was to preserve the institution-specific late applicant logic and its downstream Banner workflow while removing the custom database-level mechanism that implemented it.

Rebuilding late graduation processing with Native Population Selection

Which parts of the custom late graduation process represented required business behavior, and which parts existed only because of the legacy implementation?

Separate the business rule from the legacy implementation

The first step was to identify the behavior that still had to exist after modernization.

For the Registrar, the process was straightforward: evaluate graduation applications, determine whether an application arrived after the deadline for its graduation term, place qualifying students into the correct term-specific population and pass that cohort to SHRDEGS, Banner’s delivered degree-processing job.

The custom Oracle job was one way to implement that behavior. Direct writes to Banner population-selection data, custom script execution and the associated package dependencies were not business requirements.

That distinction defined the modernization boundary. ABCloudz could preserve the late graduation workflow without reproducing the custom technical mechanism that had supported it on premises.

Move cohort selection into delivered Banner functionality

ABCloudz moved the selection logic into Banner Native Population Selection configured through delivered Banner functionality.

The source data remained in Banner’s graduation records. The new rules use the student PIDM, Banner’s internal person identifier, as the selection key. They evaluate the graduation term, compare the graduation application date with the corresponding Registrar deadline and apply the required degree status condition. Qualifying records are then associated with the corresponding Spring, Summer or Fall population.

This required more than copying the original SQL. Banner Population Selection uses a more constrained query environment than the custom Oracle process, including limitations around some SQL string functions. The selection logic therefore had to be expressed in a form that the delivered Population Selection capability could evaluate reliably.

See how the late applicant rules map Banner graduation data into the correct Population Selection.

From SHRDGMR record to Population Selection

The future-state logic can be understood as a sequence of decisions rather than a direct translation of the legacy SQL.

Banner data Role in the selection logic
SHRDGMR_PIDM Becomes the Population Selection key for a qualifying student
SHRDGMR_TERM_CODE_GRAD Determines the Spring, Summer or Fall processing bucket
SHRDGMR_APPL_DATE Is compared with the deadline for the applicable term
SHRDGMR_DEGS_CODE Applies the required degree status condition

The core decision flow can be represented in sanitized pseudocode:



For each graduation record that passes the documented base eligibility filters:



    determine the graduation term



    if Spring:

        compare application date with March 15



    if Summer:

        compare application date with July 15



    if Fall:

        compare application date with November 15



    if the application is after the applicable deadline

       and the required degree status condition is met:



        select the student's PIDM

        place the student in the matching late application population

The three resulting populations are organized by graduation term:



Spring  -> Spring late-applicant population

Summer  -> Summer late-applicant population

Fall    -> Fall late-applicant population

The Population Selection rules define the cohort, while SHRDEGS remains responsible for downstream degree processing.

Validation of the selection logic

The project specification defines validation at several levels.

First, the base cohort is checked to confirm that the Population Selection identifies records that meet the required degree status criteria.

Second, the logic is tested independently for each term:



Spring -> applications after March 15

Summer -> applications after July 15

Fall   -> applications after November 15

Finally, the resulting population is verified as usable by downstream Banner processing.

The underlying Banner Population Selection mechanism may still populate Banner selection data used by SHRDEGS. The architectural change is that institution-specific code no longer performs custom direct DML to create that data. Population creation is handled through delivered Banner functionality.

Keep the existing downstream degree-processing step

Modernizing the custom selection mechanism did not require redesigning the complete graduation workflow.

The new Population Selection logic still produces separate Spring, Summer and Fall late-applicant populations. Those cohorts remain inputs to SHRDEGS, Banner’s delivered degree-processing job. The future state also retains controlled cleanup and audit reporting through supported Banner mechanisms.

This keeps the modernization focused on the part of the process that needed to change.

When modernizing a Banner customization, the migration target is often the required business behavior rather than the legacy object that implements it. Separating the two makes it possible to preserve the workflow while moving it to supported platform capabilities.

What changed for the institution

The completed design moves late graduation cohort selection from a custom database-driven job into Banner Native Population Selection.

The institution no longer depends on institution-specific SQL that directly inserts or deletes population extract records. The required late application rules are expressed through delivered Banner functionality that fits the SaaS architecture.

The business process remains familiar to Registrar operations. Spring, Summer and Fall late applicant cohorts are still produced, and SHRDEGS remains the downstream Banner process that consumes those selections.

The modernization changes the implementation boundary without replacing the surrounding graduation process.

Late graduation cohorts are now generated through Banner Native Population Selection rather than the previous custom direct DML mechanism, while the institution retains its term-specific selection logic and downstream SHRDEGS workflow.

Frequently asked questions

Why could the existing custom late graduation job not simply be moved to Banner SaaS?

The customization depended on an on-premises Oracle SQL job, direct DML against Banner data, custom utility functionality and SQL*Plus-based reporting. The late graduation business rules could be retained, but the custom execution mechanism had to be replaced with a SaaS-compatible Banner pattern.

What parts of the legacy late graduation process were preserved?

The future state retains the term-specific late application logic, the three Spring, Summer and Fall populations and the use of those populations by SHRDEGS for downstream degree processing.

How does the new process identify late graduation applicants?

Banner Population Selection evaluates graduation records from SHRDGMR. It uses the graduation term to determine the applicable deadline, compares the application date with that deadline, applies the required degree status condition and selects the student PIDM for the appropriate term-specific population.

Does the new design still involve GLBEXTR?

Banner Population Selection can still use Banner selection data associated with GLBEXTR. The change is in how that data is created and managed. The institution-specific process no longer performs custom direct inserts and deletes against the table. Population creation is handled through delivered Banner functionality.

How was the new Population Selection logic validated?

The specification includes validation of the base qualifying cohort, separate Spring, Summer and Fall deadline checks, verification that the term-specific population is created correctly and confirmation that the resulting population can be used by downstream Banner processing.

Need to modernize a custom Banner process?

Legacy Banner customizations often combine required business rules with implementation patterns that no longer fit a SaaS architecture. ABCloudz can help identify which behavior must be preserved, separate it from legacy technical dependencies and redesign the process around supported Banner capabilities.

If your Banner SaaS modernization includes custom jobs, SQL logic, direct database dependencies or institution-specific operational processes, contact ABCloudz to discuss the right modernization path.

Ready to start the conversation?