SUNY UX/UIWorking draft for discussion

Supporting evidence

These notes preserve source details and limits. Original internal files open in the private project repository and need access.

Functional requirements, draft 0.16

Source: October 22 FRD. D-04, internal draft, LCP/CRD update. It contains 13,632 paragraph elements and 602 tables, including nested tables. Locators below use section and rule IDs; extraction table numbers count top-level tables. Body paragraph numbers count direct body paragraphs, including blanks. These are not Word page numbers.

The full supplied document has been read. The draft defines intended behavior. It is not evidence that the behavior has been built or tested. Its approval table is blank and approval date is TBD.

Purpose, scope and status

Profile, identity and access (section 4)

Creating an account and asking for information

Account creation and sign-in use SUNY's public identity provider and Global ID. A matched identity should prompt the person to use their existing account; it should not silently attach a new attempt to that identity. Failed authentication needs a route to retry, account creation or identity help. [BR-ACC-001, 005, 007–009; DEC-PRF-008–010; tables 23–25.]

BR-ACC-002 requires first name, last name and date of birth. It adds an emergency contact below an unspecified age threshold and conditionally requires SSN. Without SSN, it calls for at least three of four alternatives: campus ID, phone, postal code, or another identifier type/value. The rule does not explain how a new learner without a campus ID or identity document completes this. Treat this as a requirement to clarify and test, not a recommended intake pattern. Optional fields include former/middle name and race/ethnicity. Earlier demo feedback is not a substitute for this current draft rule.

A public inquiry does not require an account. The rule limits it to information needed to respond and route the question; it excludes date of birth and the full learner demographic set. Name/email, optional phone, context and optional outreach consent are described. BR-PRI-001 lists phone among minimum examples, while BR-PRI-005 calls it optional. Resolve required fields before designing the form. [BR-PRI-001–005, section 4.2.2.]

Inquiry routing can use automated assignment, with an unassigned queue for manual handling. Signed-in learners get available profile fields prefilled. Exact routing and additional prefill fields remain open. The public inquiry capability still has an LRN suffix, which the document flags for correction. [OPN-PRF-011–012.]

Figures 4.1–4.2 show browsing before account creation, then return to course registration/payment. They show the successful route, not the full identity-recovery behavior. Figure 4.3 includes portal, phone and walk-in inquiries; general and course-specific paths; form validation; automatic/manual routing; staff response and status updates. Routing criteria are explicitly left for later definition.

Learner profile and history

Learners can view their profile and history across campuses, edit permitted contact/preferences/interests/career-goal fields, and add/change/remove a preferred campus. Source-owned fields need a correction request. Changes are logged. Campus synchronization follows ownership rules to avoid overwriting campus data. Interests and career goals do not drive Release 1 recommendations. [BR-PRM-001–004, 008–010; ASM-PRF-11; sections 4.3.1–2.]

History includes current and past activities, status, grades, completion and earned credentials. Other modules own its detailed rules. Whether the preferred-campus field is the same field used for search remains a named question. [OPN-PRF-002; PRF-REC-LRN-001–004.]

Employer and campus roles

Permission rules across the service

Section 4.8, BR-ACP-001–046, uses native platform permissions and separates allowed actions from allowed records. A role does not grant another campus's data. Campus job titles may differ; people can hold the permissions their work requires. Campus View Only, Coordinator, Functional Administrator and System Administrator are subdivisions of Campus Personnel, with distinct powers. Technical administration does not imply functional authority.

Employers see only training information allowed by their employer relationship, including in a multi-employer cohort. Instructors see assigned learners. Statewide access and sensitive actions need explicit authority. Creating records does not imply deletion rights. Access is audited, reviewed and removed when the supporting role or relationship ends. The capability-by-persona matrix is intended to govern all channels. [Section 4.8, tables 53–68.]

OPN-PRF-010 asks whether former employer-visibility rules have been fully replaced by the shared access rules. Appendix E and the remaining modules still need reading before this matrix can be relied on as complete.

Catalog and discovery (section 5)

What people can find and decide

Public users browse across campuses without an account. They can see descriptions, schedules, location, instructors, prices/discounts/deadlines, capacity/waitlists/cancellation, credentials, funding criteria and credit-pathway information. They can ask a question before registration. Campus identity remains visible inside a common service. [Sections 5.1–5.2; CAT-SRC-PUB-001–004; CAT-DTL-PUB-001–007.]

The draft supports combined keyword/filter search, result counts, pagination, campus/location/delivery/date filters, and date/name/price sorting. It still names instructor keyword search, unlike the Jira story clarification. Programs and courses can both appear. The exact study categories and delivery terms need governance; page size and response-time/volume targets remain open. [BR-SRC-003–004, 009–014; DEC-CAT-014–015, 033; OPN-CAT-020, 023–024.]

A favorite/watch list is a Could capability for signed-in learners. Public users use browser bookmarks. A preferred campus should affect order without hiding other campuses. Explicit filters take precedence over automatic location; then preferred campus, profile address and consented geolocation apply. Without location data, use a campus-neutral order. The eight location scenarios include keyword relevance before geographic relevance for multi-campus matches. [Section 5.3.1; BR-SRC-008, 012–015; table 5.9; DEC-CAT-024, 028, 037.]

There are unresolved wording differences: the use-case goal says a default campus filter, while the rule says re-rank only. BR-SRC-011 puts campus/proximity before the selected sort; the scenarios put keyword relevance first. OPN-CAT-022 still asks about persistent/per-search controls after DEC-CAT-028 describes both. These need one consistent behavior.

Availability, eligibility and credit

Publication means visible to the intended audience, which may be public or a specific employer. Visibility and ability to register are separate. A course can appear before section data arrives, with Coming Soon and registration unavailable. Later section data attaches to the same record. Closed registration may remain visible until archive criteria apply. Programs can include a mix of active and future courses. [BR-MGT-020–022; BR-SRC-005; DEC-CAT-004–007, 018, 027, 034.]

The exact state transitions, dates and waitlist-only interpretation of “Open for Registration” remain unresolved or assigned to D-06. BR-MGT-010 says only Published/Open-for-Registration records appear, which conflicts with Coming Soon and closed-but-visible rules. Do not silently choose one. [OPN-CAT-002, 004, 015–016.]

Age is the only course eligibility condition the system evaluates. In the catalog, eligibility is information and does not block viewing, inquiry or starting registration. Missing date of birth produces an unable-to-verify message. Other prerequisites are shown for self-check or a manual process. Funding eligibility is separate from course eligibility and belongs to the funding authority. [BR-DTL-007–008; DEC-CAT-032, 036.]

Credit pathways describe an existing academic decision made outside NCSIM. NCSIM does not evaluate, award or post academic credit. Details include offering and accepting campuses, majors, courses, degrees, credit amounts and an articulation date. The Yes/No filter and displayed pathway require a recorded articulation date. Data without that date stays hidden. The source/refresh rules, handling old data, and meaning of the displayed date remain open. [BR-DTL-003–006, 012, 015; BR-SRC-017; DEC-CAT-039; OPN-CAT-021, 033.]

A course may carry occupational titles and one free-text career field. These are display-only in Release 1, not search criteria, automated pathways or labor-market analytics. Wave-one funding handling captures intent and supports campus follow-up/reporting, without external financial integration. [BR-DTL-014; DEC-CAT-022.]

Employer differences

An employer evaluates a cohort: seats against group size, schedule, worksite location, cost and credentials. The draft adds an intended cohort size and a message such as 12 seats available out of 20 needed. Worksite location replaces personal location. Employer catalog functions share existing capability IDs; the absence of employer-specific IDs does not mean the scenario is absent. [BR-DTL-010; BR-SRC-016; DEC-CAT-020, 031.]

Private/hybrid offerings are supported. Public release is a manual action under the employer agreement, not automatic expiry. The authority, evidence of agreement, partial release, replacement hold and notification recipients remain open. Released public seats use public capacity/waitlist rules. Employer account licensing and separation of organization data also need confirmation. [DEC-CAT-021; BR-MGT-029; OPN-CAT-028–030.]

How campuses maintain the information

Three participation models are described: direct Salesforce use, existing-system integration, and structured manual contribution. A program contains courses, a course has offerings, and offerings have schedules. Each activity has one owning campus and a source system. Similar activities from different campuses remain separate records. Shared/consortium ownership is still open. [Tables 5.3–5.4; DEC-CAT-010, 013; OPN-CAT-014.]

Staff create and maintain titles, descriptions, objectives, skills, audience, fees, eligibility, sections and credential/credit information. Dates may follow terms or span them. Required-field and logical validation precede publishing; creation and changes are audited. No formal publication approval workflow is required in the stated baseline. The date example requires start before end, which needs reconciliation with same-day courses and the Jira build validation. [BR-MGT-008–009, 017, 024–028; DEC-CAT-009.]

Source-owned campus-system data is read-only in Salesforce; staff make changes at the source. Some passages allow NCSIM-owned fields on integrated records, so field ownership needs to be explicit. Campus systems confirm readiness and send standard data. Historical activities are archived; hard deletion is a separate, restricted exception routed to central administration. [BR-MGT-001–007, 013–015, 027; DEC-CAT-002–005, 011.]

Changes after registration begins need governance and may need messages about dates, delivery, location, instructor, price, capacity or cancellation. Messages identify the activity, change, timing and next action/contact. The complete trigger/audience list and low-enrollment postponement process remain open. Shared credit/non-credit sections expose only the non-credit seat allocation. [BR-MGT-019, 023, 035; OPN-CAT-017, 031; DEC-CAT-038.]

The central administrator governs standards and the master index, while campuses own their content. Section 5.6's opening says the central administrator inherits every campus capability; section 4.8 explicitly rejects automatic inheritance. Resolve this against the permission matrix. Other open items include edit/publish/archive/delete role authority, unpublished-record visibility, twice-daily sync adequacy, and statewide governance. Some entries say Deferred while describing further role sessions; do not infer a confirmed Release 2 decision from that wording alone. [OPN-CAT-010–011, 013, 032.]

Failures and figures

The integration table requires recoverable failures, record-level batch results, readable translated error messages with references, released seat holds on failed transactions, unaffected campus orders preserved, support routing and reconciliation. Technical retry/retention detail belongs elsewhere. These are specified behaviors, not observed implementation. [Section 5.1.8, tables 76–77.]

All five catalog figures were inspected. Figure 5.1 shows search, filters, detail, optional inquiry and registration handoff. Figures 5.2–5.3 show creation in Salesforce or a campus system, validation, success/failure, data transformation and publication readiness. Figures 5.4–5.5 show edits, archive, publication and synchronization, including a catalog-only Coming Soon state and later section attachment. Their notes leave triggers and conflict handling for later design. Some figure labels put Data Cloud before Salesforce and describe bidirectional sync, which differs from the source-owned, one-direction rules and October architecture. Keep these as diagram/text discrepancies.

Enrollment and registration (section 6)

Starting, paying and confirming

Program enrollment and course-section registration have separate states. Registration requires an authenticated learner account; the earlier guest-registration capabilities are explicitly removed. Identity is created or found when registration starts, before validation/payment. Minors do not need an SSN. General profile data is prefilled, offering questions are answered directly, and responses stay attached to the learner and registration. A multi-course form asks general questions once and adds the relevant conditional and offering questions. [ASM-ENR-01, 07; DEC-ENR-008; BR-REG-001–003; BR-APQ-001, 003–004, 006.]

A cart can contain courses from multiple campuses where policy and payment setup allow. It groups them by owning campus and can start registration for all items in one action. People can remove individual items or cancel all pending registrations before payment; explicit cancellations are recorded. [BR-REG-007–010; DEC-ENR-001.]

The course's source system owns seats. Capacity is checked again and changes only on confirmed actions. Failed, cancelled or expired payment releases a seat, keeps an appropriate pending/failed record, and allows retry or support. The cart can remain until manually cancelled. Registration is incomplete without required payment confirmation. Payment received without source-system confirmation becomes a support exception. Free/sponsored routes need their own precise confirmation rule. [BR-RIN-002–005; BR-REG-004–006; DEC-ENR-003–004.]

Seat-hold wording conflicts: BR-REG-004 includes initiation/manual-validation/payment stages, BR-REG-006 says only while payment is underway, and BR-ELG-005 says no hold while an application is reviewed. Figure 6.3 explicitly reserves a seat during prerequisite review. Preserve this discrepancy before promising a held place.

Prerequisites and programs

Age validation is system-driven. Other conditions can be informational or require campus review, with uploaded supporting material, approval, requests for more information or denial. Approval lets the person continue registration and may trigger reminders. Program enrollment registers the relevant sections, subject to sequence and prerequisites. Whether someone can reserve a next-level course while taking its prerequisite, and how pre-launch completions are recognized, remain open. [BR-ELG-001–008; BR-REG-015; OPN-ENR-002, 016–017.]

This leaves a scope tension with the capability stating that prerequisites are not system-evaluated, and with catalog wording that only age is enforced. The differences may reflect manual versus automated checks, but program-sequence behavior still needs an agreed explanation.

Waitlists and withdrawal

A learner joins a waitlist only when the section is full and can see position/status. Offers are sequential, first-come-first-served unless an approved campus policy changes priority. Offers expire after a configured period; declined/expired places go to the next eligible person. Acceptance or decline requires signing into the portal, not responding directly in email. Staff overrides need authority, reason and audit. [BR-WLM-001–004; DEC-ENR-006.]

Dropping before the start/campus cutoff removes an activity from the learner's profile view. Withdrawing after the cutoff preserves it as Withdrawn and captures last attendance. Learner withdrawal is allowed before the relevant end date and before a final grade. Staff can act while the grade is absent, Not Reported or Incomplete. Withdrawal from a program affects remaining courses without final grades. Completed learning should be preserved. [BR-WTH-001–010.]

Staff can record reasons, processed dates and effective drop dates. Administrative Withdrawal is distinct internally, although course status/grades appear as Withdrawn to the learner; program display can be selected by staff. There are conflicts to resolve: BR-WTH-009 uses the course start date despite the configurable cutoff; BR-WTH-014–015 say all program courses change despite the completed-course protection; OPN-ENR-007 says withdrawal at any time although BR-WTH-001 adds limits. [BR-WTH-006–009, 012–016.]

Employer and grant-funded training

Bulk registration validates each employee and supports partial success with individual errors. Employer seats are separate from public seats. Replacement follows a campus cutoff; exceptions go to campus review. Rejection retains the original registration and gives the employer a reason. Removing an employee hides unfinished activities but preserves completed courses. Maximum batch size and invoice/accounting connections remain open; 10,000 is a candidate, not an approved limit. [BR-BLK-001; BR-WFC-018–024; OPN-ENR-008, 015; INT-ENR-003.]

Dedicated/consortium training is available to the participating employers and retains employer affiliation. Campus staff manually record planned/actual learner counts, budget and reimbursement, grant association/splits, provider and employer type. A grant is optional for employer-funded training; one grant may cover multiple cohorts. Actual attendance may differ from the projection. Learners may pay nothing at registration, with employer billing after attendance/costs are final. Reports support reconciliation and SUNY grant forms. [BR-WFC-001–017.]

A removed employee's seat stays in the employer allocation until explicitly released. Public release follows the public waitlist. Authority, agreement and notifications remain with the catalog open questions. The module assumption says no employer waitlist unless confirmed, while other rules mention separate employer waitlist handling. Excess actual enrollment versus planned numbers also remains open. [BR-WLM-005; BR-WTH-011; ASM-ENR-12; OPN-ENR-009, 013.]

Prices and discounts

All 32 BR-DSC rules were read. Campuses can configure fixed or percentage discounts, dates, eligible activities and combinations, with a floor of zero. Show original price, each discount and the final amount before payment. Early-bird eligibility depends on completed registration by the cutoff, with a visible deadline when adding to cart. Bundles apply within one campus, may depend on a named group or count, and should be discoverable before checkout. Cancellations can change discount eligibility and the refund under campus policy. [Section 6.4.1, table 173.]

Multi-registration discounts may cover a parent/guardian acting for several learners. A single program price is separate from a bundle discount. Gift certificates are described as redemption codes, not stored-value balances. These rules establish scenarios to investigate; they do not provide evidence of how often people use them.

Staff, instructors and changes

Staff can support phone/walk-in and late registration with controlled exceptions, messages and audit history. Quick registration can bypass waitlists; exact eligibility overrides remain open. Only staff can swap sections, within the same course and campus. Equal-fee swaps may avoid payment processing; fee/term/aid/grant/partial-payment differences require administrative handling. [BR-ADM-001–005; BR-SEC-001–005; OPN-ENR-010–011.]

Question sets are reusable, versioned and marked required/optional. Campuses edit their own offering questions, cannot duplicate general questions, and changes apply only to future registrations. The presented question version is stored with each answer. [BR-APQ-002, 005, 007–011.]

Instructors see assigned rosters, status, late adds/drops/transfers and waitlist position/date. Financial details are excluded; only the sponsor's name appears. These new rules still await ITBA review. Central oversight is explicitly authorized, not unlimited access. Automatic program completion from separately passed courses is routed toward Credentials. [BR-RST-001–006; OPN-ENR-012, 014; ENR-ADM-NAD-001.]

Historical migration scope, third-party learner-data obligations and the full notification matrix remain open. Integration entries describe campus pull/acknowledgement, payment handoffs, program synchronization and access to campus resources. Several return-path details are unfinished. [OPN-ENR-004–006; INT-ENR-001–007.]

What the 12 registration figures show

Figures 6.1–6.3 show course choice, identity, age/eligibility, seat check, application review where needed, payment and confirmation. Figure 6.3 includes more-information and denial routes, and the disputed seat hold. Figure 6.4 shows timed offers and the next person in line, but labels registration confirmed before a note about subsequent payment. Figure 6.5 shows withdrawal validation, applicable refunds, released seats and notification; its generic Removed status differs from the text's Dropped/Withdrawn distinction.

Figures 6.6–6.10 cover employer setup/login, employee data, registration/payment, employee removal, and campus assistance with review, cancellation or registering on behalf. They do not show the full partial-success batch experience. Figure 6.11 covers staff promotion/cancellation and subsequent payment. Figure 6.12 covers assisted learner registration, profile creation, capacity and payment. Profile creation remains contested in section 4. All visible steps, decisions and sticky-note comments were read; these diagrams are specifications, not observed tasks.

Finance and billing (section 7)

This section is a template placeholder. Payment, invoicing, aid/funding, refunds and financial reporting are all Pending. Do not fill these gaps with the older proposal and call that the current specification. Adjacent enrollment/discount rules supply some behavior but do not complete the finance module. [Body paragraphs 402–404; tables 194–195.]

Learner Center (section 8)

Learners should see their own activity across participating campuses in one signed-in space, linked through SUNY Global ID. This is a draft requirement, not evidence of how learners currently use a portal. No direct learning-management-system connection, assignments, submissions, appointment booking, or broad learning-pathway recommendations are included in Release 1. Some older capability codes still mention LMS; the revised wording narrows their meaning. [Section 8 overview, decisions and capability tables; extraction units 1122–1242.]

Progress and history need careful wording

Course progress means a final outcome, not a percentage of lessons completed. Program progress is passed required courses divided by all required courses. The latest section attempt controls the course's contribution. The draft distinguishes Enrolled, Pending Completion, Completed and Not Completed. Stopped Attending can still have a passing earned grade. No Show appears to learners as Never Attended. Activities with no grading have date-based treatment; all-ungraded programs become Completed after their end dates. [Section 8.2.1, BR-DSH rules.]

The precedence of these states needs confirmation. A failed course alongside unfinished courses raises an unresolved comment about whether the program is still Enrolled or already Not Completed. A successful retake should trigger recalculation, but the comment asks for confirmation. BR-DSH-024 includes pending and waitlisted records, while ASM-LCP-10 describes active and historically completed records only.

DEC-LCP-004 removes unfinished withdrawn activities from the Learner Center, while BR-WTH-003 preserves withdrawn history. Alan Meng's comment suggests separating active activities from history. That suggestion is not an approved resolution. Dropped or employer-removed unfinished activities are hidden, while completed work remains. Course details should remain accessible without repeating the catalog search. [Section 8.2.1; section 6.2.4; unresolved comments.]

Guidance, skills and support

Orientation materials can be videos, documents or guides, with campus-controlled publication, versions and targeting. Materials may be labeled mandatory or optional, but Release 1 does not track or enforce completion. Tutoring and other support can be linked. Alerts remain until acknowledged, resolved, expired or dismissed under their configuration. [Section 8, support/orientation and dashboard rules.]

Skills come from campus-defined course or program outcomes after positive completion. They are display information, not learner-entered claims or independently verified skills. Career information is limited to campus-entered occupational titles and a free-text field. Related programs contain a learner's registered or completed course and belong to that campus. They are not an AI recommendation or a broad career-pathway engine. Credit pathways are informational. Programs do not combine courses across campuses. [DEC-LCP-007–008; deferred OPN-LCP-001, 005–009.]

Updates depend on data ownership

SIS updates arrive on a configured schedule. Failed updates should alert staff and, where applicable, show the last successful update. NCSIM calculates program status from final course outcomes rather than simply importing the SIS program status. BR-LCI-005 makes SIS data authoritative unless an override is approved; BR-LCI-006 also allows local grade entry regardless of course origin. The Credentials rules further restrict editing an existing SIS grade. These rules need to be reconciled before defining correction screens. The enrollment integration's program synchronization wording is also broader than the Learner Center's wording. [BR-LCI-001–006; INT-ENR-006; BR-TRK-003.]

Credentials and outcomes (section 9)

Learners should be able to understand their progress, see earned credentials, and request historical credentials from the issuing campus. Release 1 excludes direct LMS and external credential-platform integration. Micro-credential discovery remains a separate unresolved track; definitions mentioning micro-credentials do not establish their release scope. [Section 9.1; DEC-CRD-003; OPN-CRD-003.]

Completion, eligibility and issuance are separate

Passing all relevant courses can make a learner eligible for a program certificate, including courses completed separately without prior program enrollment. BR-ADM-006 and BR-TRK-031 describe automatic program enrollment in that case. A program can remain Enrolled indefinitely when someone withdraws from one part and never returns; the closure rule and owner are still open. [Section 9.2.1; DEC-CRD-005; OPN-CRD-002.]

A certificate is not issued automatically. First, recorded outcomes establish eligibility. After the relevant end date, authorized staff can generate it using the campus template. Generation issues it and makes it available for the learner to download and print. Staff can print individual certificates; batch printing is excluded. Only a designated campus administrator can revoke one. Corrected outcomes, reissue, notifications, audit retention and who issues a program certificate remain open. [DEC-CRD-006; BR-TRK-014–018; OPN-CRD-005.]

What learners can see

The wallet combines available credentials across campuses through Global ID, subject to sharing policies and permissions. It shows available issuer, dates, type, validity, verification and relevant outcomes. Actual professional-development hours or learning credits must be shown, not merely the maximum available amount. Campus-owned SIS credentials remain owned there. This sits alongside credentials generated within NCSIM, so the source should remain distinguishable. [BR-PRT-001, 003–005; BR-TRK-019, 029–030.]

Figure 9.1 shows signing in, opening credentials, choosing view or upload, entering details, and seeing status, validity, expiration and completion information before viewing/downloading/sharing. Its upload route does not show conditional verification or rejection. The overview's statement that no flow exists does not match this included figure. [Table 230; image26.]

Learners can upload external credentials with identifying and issuer information, and request old SUNY credentials through a campus support ticket. Campus staff can upload directly. BR-TRN-003–004 describe conditional campus verification and Pending Verification. However, DEC-CRD-001 removes the earlier verification capability in favor of direct upload and support tickets. This is an unresolved mismatch, not permission to assume all uploads are verified. [Sections 9.2.3 and 9.4.2; tables 235, 244–246.]

Grades and corrections

Instructors can work only with assigned sections. They cannot overwrite a grade already supplied by SIS or an outcome set through an action such as withdrawal. They can review all or some roster entries before saving. Once a credential is issued, they cannot edit its outcome or revoke the credential. The exact point before issuance when an instructor can correct a grade is unresolved. [BR-TRK-003–005, 018, 027; OPN-CRD-004.]

The grading modes are letter grades (A–D pass, F fails), satisfactory/unsatisfactory, attendance only, varied completion/certificate eligibility, and not applicable. In the varied mode, Completed - Not Certificate Eligible is a positive completion outcome but does not qualify for a certificate. Stopped Attending requires both an earned grade and last attendance date. Instructors may choose Incomplete, Stopped Attending or No Show, but may not manually choose system-driven withdrawal/drop/removal states. [BR-TRK-013, 020, 022–026.]

There is a specific exception to clarify: BR-TRK-026 forbids user-entered grades for Not Applicable, while BR-TRK-020–021 say certain outcomes are available regardless of grading mode. Campus administrators can make authorized corrections; withdrawal/drop outcomes come through the corresponding actions. Overdue Not Reported or Incomplete grades trigger notifications and an aging view. [BR-TRK-011–012, 021, 026.]

Campus staff see outcomes and uploads relevant to their campus, not another campus's activities merely because the learner also attends their campus. Central administrators manage identity matching and conflicts through Global ID, including people with no earlier enrollment. The central credential-verification capabilities remain listed despite the narrower campus verification decision. [BR-TRK-017; sections 9.5.1–9.5.2.]

Communications (section 10)

Learners should receive relevant messages and find their history in My360. The draft supports email, SMS and in-app messages. Email and in-app start enabled; SMS starts unchecked. Required operational messages cannot be opted out of. Optional messages can. The exact required-message list, which messages accept replies, and whether in-app alone counts as an active channel remain open. [BR-ANN-001–004; BR-PFC-001–005; DEC-COM-006, 017; OPN-COM-002–004.]

English plus the twelve listed NYS languages are assumed for the learner experience: Spanish, Chinese, Russian, Yiddish, Bangla, Korean, Haitian Creole, Italian, Arabic, Polish, French and Urdu. Staff Salesforce screens remain English. Messages use the chosen language when a translation exists, otherwise English. The broader translation promise in ASM-COM-05 should be read alongside this fallback. Prospective learners' translation support is still a question. [ASM-COM-01, 04–06; DEC-COM-007; OPN-COM-006.]

A public information request needs no account. One unchecked box captures future email and SMS outreach consent together; email is normally the first available channel. On conversion to a learner, only needed contact data transfers, not prospect communication history or preferences. Figure 10.1 instead says preferences transition to the learner profile. Marketing is deferred to Release 2 in DEC-COM-002, while the public inquiry flow includes outreach. Confirm the release boundary before showing a marketing journey. [DEC-COM-015–016; figure 10.1.]

Authorized staff can target and schedule campus announcements without coding. SUNY owns shared templates and campuses may adapt them. Each channel has its own template. There is no approval workflow within the system. Release 1 banners are removed manually, despite expiration controls shown in figure 10.5. Central mandatory messages may override campus targeting. Instructor messages are restricted to assigned rosters or subsets; their own sent history and permitted replies are visible. These new instructor rules still need ITBA approval. Direct one-to-one messaging is not confirmed; appointment scheduling is excluded. [BR-ANN-005–016; DEC-COM-008–012; OPN-COM-008–009.]

Marketing Cloud is the identified delivery service, not proof that marketing campaigns are included in Release 1. Failure handling uses platform retry and logs; no custom retry flow is promised. Exact configuration ownership, authoritative preferences/history, returned delivery data and provider scope are referred to the technical specification and working group. History retention is undefined and deferred; read/open tracking for administrators is also unconfirmed. [DEC-COM-013–014; OPN-COM-001, 007, 010; INT-COM-001–002.]

Figures 10.1–10.5 were read. They cover inquiry consent and routing, message history and action links, preference validation/confirmation, and staff preview/audience checks/sending/reporting. Figure 10.4 requires email or SMS to remain active, which is stricter than the open in-app-only question. Figure 10.5 includes open/read metrics and expiry controls that the text does not confirm. Figure 10.1 routes inquiries toward case handling and notes confirmations regardless of marketing consent; its no-opt-in branch should not be interpreted as refusing the requested help. These differences need owner review.

Feedback and surveys (section 11)

Learners can submit eligible reviews and course/instructor evaluations after completion. Reviews require successful completion. Other surveys may target a population without activity completion. Ongoing unsolicited feedback uses a support case; proactive mid-course feedback remains open. Employers cannot answer on learners' behalf. [BR-REV-001; BR-EVL-001; ASM-FBK-01–03; OPN-FBK-006.]

What a learner is committing to

Responses are identifiable and attached to the learner profile. Anonymous collection is excluded for Release 1, subject to checking existing campus practices. Instructors see aggregated results with identities hidden, including counts and percentages that do not identify who responded. This is a restricted view of identified data, not anonymous submission. Campus access follows privacy rules. [ASM-FBK-05; DEC-FBK-001, 017; BR-EVL-006–007; BR-SRV-017–018; OPN-FBK-013.]

A submitted response is final, with no learner edit/delete. Earlier responses are read-only. Partly filled responses cannot be saved; leaving loses the answers. Survey links open another tab/window from email or My360. At least one reminder is required, but frequency, stopping rules and maximum count remain open. Translations are manually configured per question in supported Salesforce languages. Prefill is limited to Contact fields and cannot prefill course information through the stated standard tool. These are documented platform claims, not independently tested limits. [BR-REV-005; BR-EVL-003–005; BR-SRV-012, 019–020; DEC-FBK-002, 008, 011, 013, 018–019; OPN-FBK-003.]

Viewing others' reviews is removed. Public catalog reviews and public instructor feedback remain open questions. Do not add ratings to discovery on the assumption they are approved. [DEC-FBK-021; OPN-FBK-001–002.]

Creation, access and reporting

Published/assigned surveys are fixed; changes require a new version. Templates remain within their campus. Each activity association needs a separate survey record and link, created by cloning. Questions may use ratings, multiple choice, text or matrices. A reusable question bank beyond templates remains open. Activity-linked audiences follow that activity; the separate ad hoc distribution capability is removed. Central administrators retain cross-campus aggregate analytics, not system-wide survey creation/distribution. [BR-EVL-009–010; BR-SRV-004, 009–013; DEC-FBK-003, 006–007, 012, 020, 022–023; OPN-FBK-011.]

Instructors can create surveys only for assigned activities and distribute to their registered learners, but these new rules still await review. Survey scope and permissions also remain open. A reference to nonexistent capability FBK-SRV-INS-011 needs correction. [BR-SRV-014–018; OPN-FBK-007–009, 020.]

Reports use submitted responses only. Retention is intended to use archiving, with duration deferred to Release 2. Hiding comments without notification and automatic offensive-language detection are unapproved questions. No standard automated flagging capability was identified in the document; do not assume an AI feature is authorized. [BR-EVL-011; DEC-FBK-009; OPN-FBK-014.]

Figures 11.1–11.4 were read. They show invitation, separate-window completion, required-field checks, confirmation, immutable activity-linked survey setup, and results filtering/reporting. The results figure includes threshold alerts and notification rules marked to be determined. It also refers to masking “if anonymous,” which must be reconciled with identified collection. The general-survey rules allow more timing options than the completion-triggered example flow.

Support (section 12)

Public visitors and learners can seek help without first solving the problem themselves. The draft offers an inquiry form, knowledge articles and a chatbot. Each case has an identifier and confirmation. Signed-in learners can see case history, status, resolution and updates, and respond while the case permits it. Public inquiries use supplied contact details. [BR-SCM-001–005, 027; sections 12.2–12.3.]

Chatbot answers must use approved resources. Account-specific answers require authentication and remain within that learner's permissions. Every chatbot interaction creates a case for tracking. An unresolved conversation should continue as the same case with its context, not require repeating the issue. DEC-SUP-006 also says cases not opened by the learner are saved Closed, which needs reconciliation with the unresolved-case route. Automatic closure is not evidence that the person was helped. [ASM-SUP-01; BR-BOT-001–008; DEC-SUP-001–006.]

Live chat is conditional on SUNY/campus enablement and its release timing is unconfirmed. The chatbot and related knowledge-management release are also undecided. The capability promising live-agent escalation should not be presented as an available staffed service. Existing knowledge articles, exact routing, priorities, status definitions and additional staff/employer permissions remain open or pushed. [OPN-SUP-001, 003–004, 006–008.]

Release 1 cases stay within NCSIM. The retained external-helpdesk capability is explicitly not implemented in this release. Campus staff handle their campus's cases; a central team handles other cases. Staff can record phone, email or in-person help, even if resolved immediately. Closing requires a reason and resolution notes. Internal notes are separate from learner messages, with confirmation before sending. Ownership/action history is retained and overdue cases notify their owner. [BR-SCM-006–017, 028; DEC-SUP-007–010.]

Figures 12.1–12.6 were read. They show self-service, escalation with context, requests for more information, resolution notifications, staff-assisted cases, and campus technical/enhancement requests. Figure 12.6 assigns a role to the SUNY administrator although that support persona is still unconfirmed in OPN-SUP-007. Public case tracking and responses in the figures need a defined access method; the explicit reply rule covers authenticated learners. The text's accessibility-support-resource capability does not by itself establish accessible support interactions.

Reporting (section 13)

Campus staff need reliable counts and outcomes, with access limited by role and campus. Reports must distinguish program enrollment, course registration and course completion. A person can have several registrations, so these measures are not interchangeable. The reporting baseline is iterative, and its sample fields are illustrative, not a settled data model. [Sections 13.1–13.3, 13.9–13.11.]

The catalog covers warehouse update health; learners' own progress/feedback; instructor evaluation summaries; engagement and attendance; demographics and trends; unduplicated learner counts; completion/non-completion; activity effectiveness and type; campus lists/status; possible credit pathways; partner/employer participation; role-based measures; compliance; billing/receivables; and survey summaries. All entries and sample-field lists were read. No table contains real performance results or agreed targets. [Tables 358–370.]

Authoritative accounting, expenses and profit/loss belong to Finance and its source systems. Release 1 skills reporting uses recorded course/program skills and occupational titles only. Employment/wage outcomes and broader skills-to-jobs or learning-pathway analytics are excluded. Potential academic credit is different from credits actually awarded or a learner's later credit-bearing enrollment. Those actual records live elsewhere, so pathway-continuation reporting still needs a data source and agreed definition. [DEC-RPT-001–003; ASM-RPT-01; OPN-RPT-001, 003–004.]

Instructor reports cover assigned activities only. Employer reporting is provisional with no dedicated capability or approved data-sharing boundary. Sample inventories listing employers as consumers do not settle access. Controls call for audit history, appropriate masking, encryption and performance checks. These are requirements, not completed verification. [Sections 13.3, 13.8.2–13.8.3, 13.11.]

Detailed requirements appendix (Appendix A)

Appendix A contains the detailed requirements and crosswalks, not just repeated background. Read it alongside the module rules. All registers and traceability tables were read. The following details add to or qualify the earlier sections:

All capability crosswalks were read, including tables 386, 390, 394, 397, 404, 409 and 414. Table 415's “Built” status describes populated FRD sections, not working software. Finance remains Pending.

Glossary and references (Appendices B–C)

All glossary entries and references were read. Important distinctions include program enrollment versus course-section registration; account creation versus login credentialing; drop effective date versus processed date; grant versus financial aid; and recorded skills versus broader future pathways. My360, Learner Center, Learner Portal and Learner Dashboard name the same experience. The glossary uses “persona” to mean an access role; it does not establish researched behavioral groups. [Table 416.]

Some glossary text is older than the detailed rules. It describes instructor LMS interaction despite no Release 1 integration, includes an unresolved note on “Instructional Activity” versus NCAT, lists enrollment statuses that differ from the Learner Center model, and groups program-level pricing under bundling although BR-DSC-031–032 separate them. Do not use the glossary alone to settle these rules.

Referenced D-01 work plan, D-02 charter, D-03 business requirements and D-05 technical specification are not supplied as standalone documents in this pack. Appendix C specifies Open Badges v2.0+, WCAG 2.1 AA and PCI DSS. This supplies a badge version absent from the module definition. WCAG 2.2 elsewhere in the source set remains a baseline question. [Tables 417–419.]

Data fields (Appendix D)

All rows in tables 420–457 were read, including examples, notes, mapping comments and open questions. These tables call themselves authoritative, but contain unfinished entries and inconsistencies. Example names, dates, amounts and codes are sample data, not learner observations.

Catalog structure and planning information

Terms contain code/year/session, campus and default registration dates. Programs carry identifiers, name/code/description, goal, type, award, completion basis, requirements, approval/lifecycle status, effective dates and funding indicators. Program approval remains an explicit question. One program description row is mislabeled Campus ID, followed by a blank Catalog Description row. [Tables 420–422.]

Courses contain campus/subject/number/title, non-credit indicator, resource needs, area of emphasis, system ID and optional short name/program link. Narrative fields include description, prerequisites, co-requisites, eligibility, recommended preparation, objectives, outcomes, skills, instructional language, target population, assessment, textbooks and materials. Skills standardization and NACE alignment are only a parking-lot suggestion. Instructional language is separate from the website or message language. [Tables 423–425.]

Classification fields include employer sponsorship, usual offering cadence, activity type, CIP, NAICS and SOC codes. HESC-approved lists and CIP/SOC crosswalks remain questions. Contact hours, credits and possible CEUs are separate measures, with minimum/maximum values and possible extra fees or outside-class hours. “Credit for Evaluation Approved” remains in the data table despite the terminology question. [Tables 426–428.]

Offerings have section ID/number, parent course, term, lifecycle/publication states, modality, start/end dates, minimum/maximum registration, refund schedule, instructors/program manager, registration window and waitlist controls. Some required/optional labels conflict with their justifications. Required term linkage also needs reconciliation with courses allowed to span terms or use independent dates. Schedule records carry location, virtual link, days, local-campus start/end time, room and building. [Tables 429–436.]

Registration and cost records

Participant records link the learner, offering, status/date/reason and waitlist position. Transaction fields include optional IP addresses, referral channel, promotional code, education/industry, funding follow-up and suppression, source system, submission time and late-registration flag. Goal/reason for taking the course is optional; its example “Upskill for current job” is not research evidence. [Tables 437–439.]

Cost records include fee, payment status/method, discount type/code/amount, bundle and final amount. Employer allocation/replacement and staff section swaps have separate records. Drop date and reason support refunds and review. Open questions still cover channel values, late-registration permissions, multiple bundles, discount combinations and swaps. [Tables 440–444.]

Examples of field-definition issues: Registration Status Date is typed Currency; Offering/Section ID is typed Date; a learner identifier example contains letters but is typed Numeric; Fee Amount is typed a fixed-option dropdown; payment-status justification discusses marketing attribution. These are reasons to validate the dictionary with its owner, not to build forms from the column labels alone. [Tables 437, 440.]

Identity, contact and inquiry fields

The learner account tables place permanent address, race/ethnicity, ancestry and legal sex at initial account creation, with several marked Required. This differs from the lighter main account rule, which calls race/ethnicity optional. A “prefer not to respond” option remains a question. The ancestry note makes a legal claim, which is recorded as the document's rationale and has not been independently verified. Mailing and permanent address mappings are flagged for review. [Tables 445–446; BR-ACC-002.]

Email can have multiple values; campus email is system-generated at registration. Phone is required for accounts but optional for inquiries in its notes. Campus IDs can repeat and require validation; Global ID should reuse a matched record. Emergency contact, former/preferred names, suffix and other identifiers have separate fields and several unfinished rules. [Tables 447–450.]

Inquiries do not collect DOB, but this appendix adds required age acknowledgement, conditional birth year, required ZIP, required areas of interest and a SUNY acknowledgement. Those go beyond the minimum inquiry form in the module. Optional inquiry fields include campus interest, learning mode, comment, preferred contact method/time and future-opportunity marketing consent. Prior SUNY/EOC attendance is required in another account field, with matching still needed. [Tables 445, 449, 451–453.]

SSN is conditional. Citizenship/residency and general ID fields are conditional or optional, with unresolved mappings and a question about whether identifiers are needed beyond Global ID creation. Additional student-type/level/degree/college/field/cohort fields have optional sample values, including undergraduate examples. Their presence does not expand the non-credit scope. [Tables 453–456.]

Age eligibility lists Eligible, Not Eligible and Not Applicable, omitting the unknown state called for when profile data is missing. Manual applications include status, supporting documents and an approval-to-registration deadline. The deadline wording says the application can expire if registration is not completed, reinforcing the need to explain what approval does and does not secure. [Table 457; CAT-DTL-LRN-001.HLR-01.DR-01.]

Permissions matrix (Appendix E)

All 263 capability rows and all six permission columns were read. The matrix explicitly governs functional access subject to separate record-level, campus, employer and teaching-assignment restrictions. A Yes is not unrestricted access to every record. [Table 458, printed table 13.61; BR-ACP-044–046.]

The matrix has material internal inconsistencies:

These are specification discrepancies. No live permission exposure was tested or established. Do not implement access directly from this table without resolving the affected cells with the owners.

Comments and tracked changes

Five comments were read, including one reply. All have unresolved metadata. Syed Khan's October 22 comment says he is removing OPN-CAT-034; four tracked deletions remove that question's ID, priority, wording and disposition. It asked whether public users should have the credit-transferability filter. Do not count the deleted row as an active open question.

Alan Meng's comments dated October 23 in the Word comment fields (October 24 UTC in extended metadata) address: keeping waitlisted records until an activity starts; reconciling withdrawal history with removal from the active Learner Center; and program status/progress when some courses are passed, one failed and others not yet taken. A reply repeats the five-course example and asks about recalculation after a successful retake. These are unresolved review comments, not approved rules. The affected passages are OPN-CAT-034, BR-DSH-024, BR-WTH-003 versus DEC-LCP-004, and the program-status rules in section 8.2.1.

Reading coverage

Read all sections 1–13 and Appendices A–E, all extracted body/table text, all 263 matrix rows, five comments including the reply, tracked deletions, headers and footers. Footnotes/endnotes contain no substantive text; no body text boxes or external document chunks were found. Source locators use the original rule IDs and top-level table numbers rather than unstable Word pagination.

All 37 PNG assets were inspected, including the SUNY Digital Transformation Project logo and every process figure. Five SVG alternatives were also rendered and inspected. Their eight embedded image assets were checked separately where the SVG renderer showed black blocks: seven are blank note backgrounds; the eighth says to confirm required fields, publication/archive status and outbound-sync eligibility. These match the catalog validation flow. Figures 10.1 and 10.5 were enlarged to check every small note. Their annotations include parent-directed communications for minors and external communication-platform examples, which remain conditional or broader than the current module decisions.

Extraction units 0–2450 have been read, with the long final permissions table split into individual rows to avoid truncated output. Notes preserve material rules, exceptions, unresolved questions and conflicts. This is document analysis, not approval, implementation verification, a legal review or a user test.

Related topics: cross-source findings.

Back to the prototype review