Why decisions are committed only later
In fepli, a family does not learn of a decision in the admin panel immediately. In between lies a step of its own: committing. Whoever understands it corrects without haste and does not forget to send results.
Deciding and announcing are two steps
The automatic allocation distributes hundreds of places in a few minutes. After that, the team checks the result and corrects it. It moves individual participants, cancels an offer below the minimum or keeps a family together.
If each of these changes triggered an email immediately, a family would receive several messages about one result. The example shows both for a family with two children.
That is why decisions are provisional at first and end up in a batch. In the admin panel the new status is visible, the family continues to see “Waiting for allocation”. No email goes out, and no payment obligation arises.
Only committing makes the decisions valid. Then the payment obligation arises for places with a fee. On request, every family receives a single email with the results of all its participants. One bundled message is easier for families to understand than many individual ones.
When something ends up in the batch
Everything that is not explicitly committed goes into the batch:
- the results of the automatic allocation
- changes in the allocation view in the mode Collect first
- changes for which Commit registration status is turned off
- Effect
- Change ends up in the batch
- For
- reworking a lottery, many corrections
- Effect
- Change applies immediately, with an email
- For
- single late registrations, when the family is to know right away
Warning
While a lottery is being reworked, Notify right away sends every interim decision as an email.
What else committing triggers
Committing happens on the page Commit registrations. Beyond the emails, the step affects the phases of the season.
| Committed | Not committed | |
|---|---|---|
| Family | sees the result, on request by email | sees “Waiting for allocation” |
| Payment obligation | arises for places with a fee | is missing |
| Allocation phase | ends; a following first come, first served phase can start | runs until the planned end |
| Waiting list | moves up automatically if no registration phase is still to come | allocation of the remaining places starts only at the planned end of the allocation |
Interpreting queries
In everyday work, missing commits show up as queries.
A batch is always committed as a whole
If a part is to wait, it belongs in a batch of its own beforehand. This applies, for example, to an offer that has not been decided yet. This way, the other decisions can be sent without taking the open ones along.
As long as decisions on an offer are in the batch, its waiting list does not move up automatically. The allocation of places for the offer then counts as not finished, and moving up automatically would pre-empt it.