Why We Show You What the Button Will Do

The short answer: before any consequential commit in ApolloSRM, releasing an admissions decision, withdrawing a student, posting a batch of payments or federal aid, the screen states in plain language exactly what that commit will do, and if the action is blocked, the button names the reason before you reach for it. We call this surface a run sheet, and it is computed from the same facts the server checks at commit time, so what it says and what happens cannot drift apart.

Every school has a story like this one. A bursar posts a payment batch and finds out afterwards that the control total did not match. A registrar changes a status and discovers a week later that the change was withdrawal class, which started a federal clock nobody was watching. A financial aid officer posts a disbursement run and three awards silently go to held, discovered only when a student asks where their money is. In each case the system knew. It just waited until after the click to say so.

What is a run sheet in a student information system?

A run sheet is a pre-commit summary that answers three questions in one place: what will this action do, what is standing in its way, and what happens next. Before a launch, mission control walks a flight check, every station reporting go or no-go before anyone lights an engine, and a run sheet is the same discipline applied to a school office. Withdrawing a student shows the compliance work the change will file: the R2T4 worksheet task, the bursar review, who will be assigned. Posting a payment batch shows the control total against the items, and refuses honestly when every item is on hold, because posting zero dollars while freezing the list helps nobody. Drafting an admissions decision shows exactly what the committee is committing to, and shows just as clearly what it is not committing to, because releasing that decision to the applicant is a separate, deliberate act.

How is this different from a confirmation dialog?

A confirmation dialog asks whether you are sure. A run sheet tells you what you would be sure about. The difference is where the facts come from: our run sheets derive from the same checks the server runs when it accepts or refuses the commit. The disbursement preflight reads the same Title IV gates the posting path enforces. The withdrawal ceremony classifies the status from the same catalog the compliance chain fires on. That is the property that makes the surface trustworthy: a preview that uses different math than the commit is a second opinion, and second opinions drift.

What does a blocked action look like?

A disabled button with no explanation is a dead end, so ApolloSRM does not ship them on these screens. When a commit is blocked, the reason is stated next to the button in words: the control total does not match and here are both figures, this student has an open verification for that award year, this batch has nothing pending to post. Financial aid goes further with a preflight across the whole queue: before you post a disbursement run, you can see which awards would be held and why, award by award, instead of finding the holds in the results.

Does previewing an action weaken the controls around it?

No, and this is the part we care most about. The run sheet never moves a gate; it makes the gate legible. The release gate that keeps a draft decision invisible to an applicant, the two-person control on grade changes, the rule that a named human originates every admissions decision, the refusal to auto-retry money operations: all of those hold exactly as they did. Automation gets the same treatment as people, by the way. A workflow can be dry-run end to end, walking the same steps past the same validator, reporting what every step would do while structurally unable to send, post, or write anything. Seeing the consequence and being protected from the consequence are not competing goals. The first is how the second earns trust.

Frequently asked questions

What is a pre-commit preview in an SIS?

It is a statement, rendered before a consequential action is confirmed, of exactly what the action will do: which records change, which compliance work gets filed, which items would be blocked and why. In ApolloSRM these previews are computed from the same server-side facts the commit itself checks, so the preview cannot disagree with the outcome.

How do you prevent a bad disbursement batch from posting?

Two layers. The preflight shows, per award across the whole queue, which items would be held and the specific gate that would hold them, before anything posts. And the posting path itself re-runs every gate inside the money transaction, so even a stale preview cannot let an ineligible item through.

Can staff see why an action is blocked before trying it?

Yes. On consequential screens a blocked commit names its reason in plain words next to the action, a mismatched control total, an open verification, nothing pending to post, instead of failing after the click and leaving the reason in a log.

Does a preview ever replace an approval step?

Never. Previews are additive. Decision release, grade changes, and money movement keep their own gates, permissions, and named-human requirements. The preview exists so the person clearing those gates knows precisely what they are clearing.