As a higher-education institution prepared to move Banner to Ellucian SaaS, it had to determine how to preserve a custom eligibility process that depended heavily on the on-premises Banner database.

The process identified which students qualified for a term-based benefit and recorded that eligibility as a student attribute, a Banner record value used here as the system-of-record indicator of eligibility. TouchNet, the institution’s payment system, read that attribute in real time as part of the downstream payment workflow.

Because the customization combined business rules, direct data access, configuration and attribute updates inside the on-premises environment, the SaaS transition required more than replacing SQL queries with API calls. The institution needed to preserve the required eligibility behavior and its downstream use while redesigning how the process obtained data, evaluated policy, updated Banner and recorded processing outcomes.

ABCloudz rebuilt the customization as an externally orchestrated, API-driven workflow with separate responsibilities for Banner data access, eligibility processing, transactional updates, operational state and reporting.

Rebuild the custom Banner eligibility process for Ellucian SaaS while preserving the institution-specific business behavior and the Banner eligibility state used downstream by TouchNet.

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.

A custom eligibility process had grown into a database dependency

The legacy customization was a custom Banner Job Submission batch process that ran database-side logic and combined several responsibilities in one database-driven implementation. It read identity, registration, curriculum, academic standing and enrollment-status data directly from Banner tables. SQL and PL/SQL, Oracle’s procedural extension of SQL, applied institution-specific eligibility rules. A custom configuration table controlled term-by-term requalification behavior, while qualifying students received the eligibility attribute through direct database inserts.

That attribute mattered beyond the batch itself. It represented the student’s eligibility state in Banner and was read in real time by TouchNet, the institution’s payment system, as part of downstream payment processing. It also supported other institutional processes related to program administration and fulfillment. The attribute alone did not mean that the student had completed payment.

The rules also continued to evolve. Eligibility depended on academic and enrollment conditions, while data timing could affect decisions when current-term status information was not yet available.

Business policy, Banner data access, attribute updates, custom configuration and operational reporting were concentrated in one custom database-driven batch process.

The modernization effort started by identifying the behavior the customization provided: determine eligibility from institutional policy, record the appropriate state in Banner and make the outcome available to operational users. Those responsibilities then had to be reassigned to SaaS-compatible components.

Redesigning the batch job as a SaaS eligibility workflow

ABCloudz decomposed the legacy job into distinct responsibilities: retrieve system-of-record data, evaluate institutional policy, determine the required attribute action, submit transactional changes, retain operational state and publish reporting data. The redesign also preserved the Banner eligibility attribute as the downstream state used by TouchNet.

That separation became the organizing principle of the new architecture.

When modernizing a custom enterprise batch process for SaaS, first separate the business responsibilities embedded in the customization. The replacement architecture can then assign each responsibility to the appropriate supported component.

Separate data access from eligibility logic

Supported Ellucian Ethos APIs, part of Ellucian’s integration framework for accessing and exchanging data through supported interfaces, provide the student, enrollment, academic-program, academic-standing and existing-attribute data required by the workflow. The eligibility rules remain outside the API layer.

An external processing service aggregates and derives the information needed for evaluation, applies institution-specific inclusion and exclusion rules and determines the student’s final eligibility state. Rule definitions are maintained through an external configuration layer rather than embedded in database-resident code.

This separates institutional policy from Banner data storage and allows the eligibility framework to evolve without rebuilding a custom PL/SQL process.

The workflow had to preserve term-specific eligibility behavior and the resulting Banner state used downstream by TouchNet while replacing database identifiers, custom configuration and direct writes with supported SaaS mechanisms.

Update Banner only when the evaluated state requires it

After eligibility is calculated, the workflow compares the desired state with the student’s existing attribute state. A new attribute is created only when the student is eligible and the corresponding assignment does not already exist.

RELATED BLOG POST: For another student-state workflow that compares the required outcome with current Banner state before making supported API changes, see Modernizing a Point and Click Solutions immunization integration for Ellucian SaaS.

Before submission, the workflow validates the required identifiers and term context, checks for duplicates within the current run, confirms business-rule consistency and verifies the completeness of the API request payload.

The write itself uses a supported Banner API. One important implementation detail is that the API requires Banner academic-program and study-path context rather than accepting the same internal identifiers used by the legacy SQL process.

How Banner record context is resolved before an attribute write

The API write comes at the end of a short resolution chain rather than acting as a direct replacement for a database INSERT.

The processing service begins with the student identity and academic-program information retrieved through supported APIs. Before an eligibility attribute can be submitted, the workflow has to resolve the Banner record context expected by the target student-attribute API.

A simplified mapping looks like this:

Required API value Role in the request How the workflow obtains it
sgastdnId Identifies the relevant Banner student-general record Resolved from the student’s academic-program context
stspKeySequence Identifies the corresponding study-path sequence Derived from the academic-program context
attsCode Identifies the eligibility attribute to create in Banner; the stored attribute is consumed downstream by TouchNet Configuration or constant for the eligibility attribute
sgastdnTermCodeEff Identifies the effective academic term Supplied by the pipeline term context

The resulting payload can be represented in sanitized form as:



{

  "sgastdnId": "<STUDENT_GENERAL_RECORD_ID>",

  "stspKeySequence": 1,

  "attsCode": "<ELIGIBILITY_ATTRIBUTE>",

  "sgastdnTermCodeEff": "<TERM_CODE>"

}

Neither an institutional student number nor a legacy internal database identifier is sufficient on its own. The workflow first establishes the student’s academic-program context, then derives the Banner lineage values, the record identifiers that tie the request to the correct student and study-path context, required for the supported write.

Before submitting the payload, the pipeline also queries the current attribute state using the same student and term context.

The decision sequence is:

  1. Retrieve the student and academic-program context.
  2. Resolve sgastdnId and stspKeySequence.
  3. Confirm the eligibility attribute code and effective term.
  4. Query the existing attribute state.
  5. If the assignment already exists, perform no new write.
  6. If it does not exist, validate the payload and submit the supported create request.
  7. Capture the API result in the operational processing record.

The documented API path guarantees create behavior only and does not establish supported update or delete operations for this resource. The workflow therefore does not infer unsupported lifecycle operations from the create API. If another attribute lifecycle action is required, it must use the appropriate supported Banner mechanism rather than assuming that the same API supports HTTP update or delete operations such as PUT or DELETE.

Make reruns observable, controlled, and safe

The Future State also moves processing state outside Banner. An external operational store records evaluated students, eligibility decisions, attribute actions, API outcomes, errors and execution metrics. This keeps pipeline metadata separate from the Banner business record and provides the information needed for traceability and controlled reprocessing.

Idempotency is built into the decision flow. Repeated execution can produce the same intended state without automatically creating another attribute record because the workflow checks current state before creating one.

Reporting is handled separately. Curated eligibility outcomes and operational data can be published through Ellucian Data Connect and downstream analytics tools, while transactional eligibility processing remains in the external workflow and supported Banner APIs.

How idempotent processing works across repeated runs

A repeated run begins by reevaluating the student’s eligibility from the current source data and active rule configuration. The pipeline then compares that decision with the current Banner attribute state before deciding whether a transaction is needed.

A simplified control flow is:



Validate execution inputs

        ↓

Retrieve student and academic data

        ↓

Evaluate eligibility rules

        ↓

Determine desired attribute state

        ↓

Retrieve current attribute state

        ↓

Eligible + attribute exists

        → RETAIN / NO NEW WRITE



Eligible + attribute missing

        → VALIDATE PAYLOAD

        → CREATE ATTRIBUTE



        ↓

Capture submission result

        ↓

Persist execution and audit data

The pre-submission validation layer checks more than whether the record exists. The pipeline also verifies required identifiers and term values, prevents duplicate actions within the same execution, checks payload completeness and ensures that the proposed action is consistent with the evaluated business rules.

The operational store preserves the context needed to understand what happened during the run. The underlying data model can include:

  • a unique execution identifier linking records from the same run;
  • the student resource identifier and institutional identifier used during processing;
  • term and processing mode;
  • final eligibility decision;
  • derived values such as credit hours or enrollment classification when required by the active rules;
  • academic standing, academic level, organizational affiliation and other evaluated conditions;
  • structured rule-evaluation results;
  • the logical attribute action selected by the pipeline;
  • API response code and error information;
  • processing timestamps and integration identity.

This metadata remains separate from the Banner student-attribute payload. The Banner record contains the business data supported by the target API, while execution history stays in the operational layer where it can support reconciliation, troubleshooting and controlled reprocessing.

API failures are captured with the corresponding processing context. Temporary API failures can be retried according to the configured retry policy, while the final submission outcome remains part of the execution record.

The design also supports different processing scopes. A full evaluation can process the term population, while targeted or incremental processing can reevaluate selected changes without changing the core decision pattern. In either case, the same current-state comparison prevents repeated execution from creating duplicate assignments.

What the new architecture changes

The institution retained its custom eligibility capability in an architecture designed for Ellucian SaaS. Eligibility policy is no longer embedded in Banner database code, attribute writes use supported APIs and repeated processing accounts for existing state before creating records. The resulting eligibility attribute remains in Banner as the downstream state used by TouchNet for payment processing.

Operational decisions and API outcomes are retained outside the Banner business record, providing traceability and supporting controlled reprocessing. Reporting is also separated from transactional execution, giving Data Connect and analytics platforms a clear downstream role.

The custom eligibility process now separates policy evaluation, Banner transactions, operational state and reporting into clear responsibilities while preserving the business function the institution needed in its SaaS environment, including downstream TouchNet use of the Banner eligibility attribute.

Frequently asked questions

Why couldn’t the legacy Banner job simply be moved to SaaS?

The main issue was the institution-specific customization embedded in the job. It depended on direct Banner table access, custom database configuration, SQL and PL/SQL business rules and direct attribute inserts. Preserving the business function required redesigning those responsibilities around supported SaaS interfaces.

Where does the eligibility logic run after modernization?

The institutional eligibility logic runs in an external processing service. Banner and Ethos provide the system-of-record data needed for evaluation, while the processing layer applies the configured business rules and determines the required attribute action.

Why is Data Connect not used to perform the eligibility updates?

In this architecture, Data Connect is a downstream reporting and analytics layer. Transactional decisions and student-attribute changes are handled by the processing workflow and supported Banner APIs.

How does the workflow avoid creating duplicate student attributes?

Before creating an attribute, the pipeline evaluates eligibility and checks the student’s existing attribute state for the relevant Banner and term context. If the required assignment already exists, no additional create request is submitted.

Can eligibility rules change without rebuilding the integration?

The Future State separates rule configuration from the processing code. Eligibility criteria and thresholds can therefore be maintained through the external configuration model, subject to the institution’s normal governance and validation of policy changes.

What happens when enrollment or academic-status data is delayed?

Eligibility still depends on accurate, available source data. The workflow is designed to run after required upstream data is available, while its scheduling and reprocessing capabilities let the institution account for timing differences instead of assuming that every API value is immediately current.

How does TouchNet use the eligibility attribute, and does it mean the student has already paid?

TouchNet reads the attribute in real time as part of the downstream payment workflow, but the attribute is assigned before payment. It represents eligibility or control state, not proof of payment. Payment or completion of an opt-in process is handled separately.

What happens if an existing attribute has to be removed or end-dated?

The documented create mechanism should not be treated as implicit support for update or deletion. Any removal or end-dating requirement must use the appropriate supported Banner lifecycle mechanism rather than an assumed operation on the create API.

Modernizing a custom Banner process for SaaS?

Custom Banner jobs can contain much more than legacy code. They may encode institutional policy, operational dependencies, data relationships and downstream business behavior. ABCloudz can help identify what a customization actually does, determine what must be preserved or redesigned and rebuild that capability using supported Ellucian SaaS architecture patterns.

Contact ABCloudz to discuss your Banner SaaS modernization project.

Ready to start the conversation?