How can we help you?

Fee recovery and school automation solve different problems, but they share one operating rule: preview the effect, keep access controlled, and review the evidence after a run. Supervised fee recovery works overdue invoices through a staged follow-up queue. The automation rule builder handles repeatable “if this happens, do that” school operations from a reviewed action catalogue. Neither a queued message nor a completed rule run proves that a parent received a message or that money was collected.

What fee recovery actually uses

Recovery preview calculates a deterministic pay-likelihood score from 0 to 100 from bounded collection history and shows its reasons. An optional model may make a bounded adjustment, but the baseline, eligibility policy and escalation ladder remain deterministic. Treat the score as prioritisation support, not as a promise that a family will pay.

Eligible accounts move through Reminder, Follow-up, Firm notice, Final notice and then a Human call task. The last stage creates operator work; the product does not place the call. Before dispatch, the campaign rechecks the current invoice and takes a one-at-a-time claim. Paid, cancelled, voided, zero-due, opted-out and already-claimed records are suppressed. Automated outreach uses approved templates; model-written recovery copy is not autonomously sent.

What school automation can run now

A rule has a trigger, optional conditions and an ordered set of actions. The current school catalogue contains 41 action types: 24 ready and 17 unavailable. Appearing in the catalogue does not itself make an action usable. The main builder offers only ready actions; unavailable concepts are disclosed separately with the missing control and cannot be newly selected, saved or run. An older rule that contains one remains inspectable so an administrator can repair it, but the action still fails closed.

The ready set covers staff notices, assigned follow-up tasks, driver and vehicle document-expiry checks, approved-template WhatsApp or SMS, bounded student and admissions updates, homework, initial report cards, pending leave, certificate revocation, complaints, parent-teacher meetings, controlled fee and accounting work, and diagnostic or audit records. High-impact actions require approval of the exact rule version by a different authorised person before a separate activation step. The system rechecks the current plan, permissions, approved version and activating staff account when the rule runs.

The 17 unavailable concepts include unrestricted email or free-text messages, arbitrary external calls and event chaining, automatic attendance or marks changes, certificate issue, visitor check-in, substitute assignment, automatic lead creation, direct invoice or student lifecycle status changes, model-output chaining and long-running named workflows. Keep these in their supervised module or use a staff task until the missing validation, review, durable delivery and correction controls exist.

Build and activate a rule

1. Open Automation and choose an event or an interval, daily or monthly schedule. Scheduled times are UTC.
2. Add conditions and choose from the Ready actions. Review the access and approval information shown for each action.
3. Use Simulate with a representative event. It makes no business record change and executes no action. It follows the selected nested or if/else path, renders the supplied sample values and points to unresolved fields. Because earlier actions do not run, their live outputs cannot be filled in; simulation also cannot prove that a live provider or school-record operation will succeed.
4. For a high-impact rule, submit the exact current version for independent approval. Approval does not enable the rule; activation is a separate recorded decision.
5. Review the run, every step and the affected school record after execution. Any edit or rollback pauses the rule and invalidates stale approval and activation authority.

Read run health and evidence

Run history uses the whole selected period, not just the visible page. The All, Running, Blocked, Skipped, Successful, Partial and Failed figures are controls: selecting one filters the ledger, and selecting a row opens its trigger, rule version and step evidence. Success rate uses only action outcomes: Successful, Partial and Failed. Blocked, Skipped and Running do not enter that denominator. Average and 95th-percentile duration also use only finished Successful, Partial and Failed runs. A blocked access check, unmatched condition or still-running item therefore cannot distort action success or duration.

The rule name shown for a run comes from the stored snapshot for that run's exact rule version when available. For older evidence without a matching name snapshot, the current rule name is shown as a labelled fallback and may differ from the name used when the run occurred.

The operator view masks common credentials and contact details in errors and structured step results and marks a result when masking changed it. This is a bounded viewing safeguard, not a claim that every possible sensitive value can be recognised. The durable run record remains the source for authorised audit review. A diagnostic Log step is retained in step evidence; it is not proof that another school record changed or that an external provider completed work. Rapid filter changes keep only the newest response, so an older slow request cannot replace the selected view.

Arrange and version a rule safely

Moving or resizing canvas nodes is presentation-only. A layout-only save does not create a new executable version or invalidate an approval. The save compares the rule version and the exact arrangement the operator loaded; if another operator has moved the canvas, the current server arrangement is reloaded instead of being silently overwritten. If the rule definition saved first but its separate layout save conflicts, the definition remains saved and paused, and the screen explains that partial result before reloading the winning arrangement.

Version history compares authored executable fields with the current definition. Canvas arrangement and enabled or paused status are not restored from a snapshot. A legacy snapshot that predates verifiable schedule state remains available for comparison but is marked Restore unavailable with the server reason. Restoring an eligible snapshot creates a new paused version for review; it never silently reactivates the rule.

Reveal an inbound webhook credential deliberately

The credential is not fetched when the Automation page loads. An authorised operator must open Webhook credential; the URL remains masked until Reveal, while Copy is a separate explicit action. The dialog distinguishes loading, access error and server-not-configured states, and closing it clears the displayed credential state. Rotation revokes the previous URL immediately with no overlap. If another session rotated first, the dialog reloads the current generation and asks the operator to review before trying again.

Every sender must include a unique event ID. Reuse an ID only for an exact retry of the same JSON body; changed content under the same ID is rejected. Configuration and successful delivery by a real external sender are environment-specific and NOT VERIFIED by the product screen.

Starter workflows and library sync

The current library contains 40 starter workflows, all reviewed and all paused by default. They span role-targeted staff notices, business-keyed tasks, bounded diagnostic or audit records, an approved attendance-shortfall family message and transport compliance checks. A school must still review and explicitly activate the workflows it wants.

The earlier library had 34 definitions that could not run. They were resolved as 27 governed workflows plus seven retirements. Six retired entries were redundant or inert event chains, and one duplicated the Attendance module's consent-aware, one-per-student-per-day absence message. Library sync archives only an untouched school copy of those seven retired entries and preserves its history. A school-customised legacy copy is not overwritten or retired automatically; an administrator must inspect and repair or replace it, and any unavailable action remains blocked in the meantime.

Editing a current starter marks the school copy as customised, so a later library sync does not overwrite it. Custom rules can be retired with a reason while preserving versions, approvals, runs and steps. Current starter workflows cannot be manually archived. Version checks stop one editor silently overwriting another person's newer work.

Duplicate protection and message review

Supported staff notices and tasks use stable action identities so retrying the same step does not create another local record. A task may also carry a school-case key, which prevents separate runs from opening more than one active follow-up for the same case. Approved-template family messages keep a durable local delivery identity; replay returns the existing message instead of sending another provider request.

A third-party provider can still accept a message and then time out before acknowledging it. Provider-side exactly-once delivery is NOT VERIFIED. For that ambiguous state, automated provider retry is deliberately withheld: an authorised communication operator must inspect the delivery evidence and choose whether to retry. Use only school-approved templates and keep health, hardship and other sensitive family details out of message content.

Interrupted-run recovery

If a worker is interrupted, the same rule occurrence stays identifiable. Only one worker can reclaim a stale or abandoned run, already committed steps are retained, and processing resumes at the first missing step. The schedule worker also performs a bounded search for stale scheduled runs. Recovery stores only the scheduled time and, when needed, a sanitized internal access reason; it never stores or guesses the original student, guardian or event details. A disabled, retired or edited rule is stopped by the current rule-state check without repeating another school-record action.

Older running schedule records created before this recovery evidence existed may not contain enough deterministic evidence to reconstruct safely. They are reported as unverifiable and are deliberately not guessed or replayed. Automatic recovery of those pre-upgrade records is NOT VERIFIED. Review the recovered run and affected school record before treating the business outcome as complete.

Operating safeguards

• Preview fee recovery before each new term or policy change.
• Keep quiet mode on while imported records and communication settings are being checked.
• Activate only workflows your school has reviewed; every starter arrives paused.
• Keep maker and checker roles genuinely separate for high-impact automation.
• Treat simulation and rule-run records as operational evidence, not proof of provider delivery or collection.
• Review customised legacy rules after a library sync; they are preserved rather than silently rewritten.

FAQ

Q: What happens if a parent pays while a reminder is being processed?

A: The campaign rechecks and claims the live invoice immediately before dispatch, so paid and zero-due records are skipped. A message already accepted by a carrier cannot be recalled; use the invoice and delivery timelines to resolve that in-flight race.

Q: Can a school automation send a WhatsApp or SMS message now?

A: Yes, but only through the approved-template phone-message action, with the school's template/provider setup, consent, opt-out, quiet-mode and manual ambiguity-review controls. Unrestricted free-text messages, arbitrary email and model-generated operational chaining remain unavailable.

Q: Why do I still see an unavailable action in an older rule?

A: It remains visible so an administrator can understand and repair the old definition. It cannot be newly selected or executed. Replace it with a ready action or a supervised task in the owning module.

Q: Does a simulation prove the rule will work?

A: No. It safely follows the selected path and renders sample data without mutation. Live access, record validation, trigger production and provider behaviour are checked only by their actual paths; every normal business-event path is not claimed here as exhaustively verified.

Q: Does a completed run prove successful collection?

A: No. Confirm payment against the invoice and the relevant provider or bank evidence before reporting money as collected.

Review unresolved Automation evidence

Open Automation → Review for two evidence-backed decisions that the scheduler must not guess. Each queue figure is a filter, every row opens its source package and event history in a side drawer, and the page distinguishes unavailable evidence from a verified zero. Refreshing inventory is bounded and idempotent; it does not execute a rule.

A Scheduled recovery case means an older running clock occurrence lacks enough deterministic identity to reconstruct its original payload safely. The affected rule is paused and held from activation or runtime execution while that source run remains unresolved. An operator allowed to update Automation may record the only supported disposition: no replay. This sets the source run to Unverifiable, keeps the rule paused with no next run, records a required reason and never reconstructs a payload, executes an action, or claims success or failure. If a real worker reaches a persisted terminal outcome first, that outcome wins and the pending review is superseded. A heartbeat change does not alter the immutable package.

A Customized school starter case compares one exact school-owned rule version with the current starter-library version and package SHA-256. A school-authorized approver may confirm the intent to retain that exact definition. This is a school confirmation, not maker-checker action approval and not activation; the rule remains paused. An edit, rollback, package drift or library change invalidates the old package and requires a new current comparison.

Review decisions remain available when the Automation entitlement is paused because they reduce risk and do not run actions. CSV and JSON evidence downloads are available to operators allowed to export Automation evidence; exports are complete or refused with a request to narrow the filters, never silently truncated. Review responses are not cached, and the current source view omits the internal recovery note. If another operator or worker changes the source first, reload the case rather than treating the conflict as success.

In Operations, Unverifiable runs count as attention evidence but remain outside action success/error and duration denominators. Successful, Partial and Failed are still the only action outcomes used for those calculations. A no-replay disposition proves only that the unsafe historical replay was prevented; inspect the affected school record before deciding the business outcome.