Submit Button Widget

A Submit button is the moment of commitment in a lesson. When a learner presses it, Berdee locks the answers in scope, grades them, and either flushes the results to the server as a checkpoint or finalizes the entire attempt.

A regular Button is for navigation and reveal-style actions. A Submit button is for graded answer submission.

What "Submits" controls

Every Submit button has a Submits setting in the Properties panel with two options:

• Current scene _(default)_ — grades only the scorable widgets on this scene, locks them so the learner can't change them, and saves a checkpoint to the server. The lesson continues. Use this for per-page commits in a multi-scene lesson.
• Lesson — finalizes the whole attempt on the spot, wherever it's pressed. Grades every scorable widget across every scene the learner visited, writes the final score to the gradebook, and locks their answers. There is no going back after this.

**Reaching the lesson's Closing Scene is what normally finishes a lesson now — a learner doesn't need to press anything to complete it. A Lesson-submit button still finalizes the attempt immediately if pressed anywhere else, but it drops the learner onto a plain results card instead of your own ending, so it's best kept as a safety net rather than the primary way a lesson ends. Berdee still blocks publishing a lesson with no Submit button set to "Lesson"** — that requirement is on its way out as the closing scene takes over, but until then every lesson needs one somewhere.

When to use "Current scene"

Current-scene submit acts like a checkpoint. It's optional — you don't have to put one on every scene — but it's useful when:

• You want to lock in answers and show feedback before the learner moves on. Some widgets reveal correct/incorrect styling only after submit.
• You want to move the student on only after they submit. Set the scene's Progression to a destination and its Evaluate on to Submit. New scenes start on Continuous, which moves the student on the moment their answers are right, without waiting for the Submit button. See Progression waits for Submit only when you ask it to.
• You want a checkpoint saved to the server mid-lesson. Without a scene submit, results for that scene only reach the server when the lesson is finalized (or in periodic background flushes). If a learner abandons the lesson partway, a scene submit increases the chance you have their work: the attempt page's Answers so far lists what reached the server, with a checked scene's answers locked in and the rest marked as still changeable. The gradebook still shows a score only once the attempt is finished.
• Your lesson already uses a random scene pick (Scene Progression) that replays scenes the learner got wrong. The picker knows a scene was "wrong" only after a scene submit fires.

You do _not_ need a scene submit just because a scene has scoring turned on. Reaching the Closing Scene grades everything the learner visited.

When to use "Lesson"

Most lessons don't need to reach for this anymore — flowing into the Closing Scene already ends the attempt and shows the ending you designed. Publishing still requires a Lesson-submit somewhere, so place one where it's least likely to be needed:

• On the scene right before the closing scene, as a deliberate "I'm done" moment for a learner who wants to submit early rather than keep working.
• On a scene that isn't meant to lead anywhere else — a dead end your flow shouldn't have, but that a Lesson-submit can still recover from until you fix the flow.

A lesson can have more than one Lesson-submit button. Whichever one the learner presses ends the attempt immediately, so keep it off scenes where a learner might press it before they meant to finish.

Settings

• Label — the text on the button face. Match the action: "Check My Answers", "Finish Lesson", "Submit Section". Avoid plain "Submit" when the consequence isn't obvious.
• Sizing and resizing work exactly like a regular Button: corners scale the label text, side handles set the width (the label wraps), the Width control switches Auto/Fixed, and with Fixed width you can set a taller Height for a bigger tap target. New Submit buttons show your chosen font and weight in the student view — existing ones keep their current look until you edit them.
• Confirm before submit — when on, the learner sees a confirmation dialog before submission. A Lesson submit asks "Are you sure you want to submit your final answers?"; a Current-scene submit asks "Are you sure you want to submit this section?". If the button's On Press only submits the lesson under a condition, it asks "Are you sure you want to submit your answers?", since that press may or may not finish the lesson. Useful for Lesson submits where there's no undo.
• Submits — Current scene or Lesson (see above). If the button has an On Press behavior, this setting no longer applies — the behavior's own Submit Answers step decides, and the panel says so under the setting.
• Progression and Evaluate on _(set on the scene, not the button)_ — where to send the student once the scene is correct (Stay, the next scene, a specific scene, or a router), and whether that check waits for Submit. See Scene Progression for the full guide.

A Submit button is never worth points itself — it is the control that grades, not a question.

How it interacts with scoring

When a Submit button fires:

1. Every scorable widget in scope is graded using its authored correct answer. The widget records points earned and locks so the learner can't change their answer. If the learner comes back to that scene later, they see the answer they gave, read-only: the same choices, typed text, matching lines and dropped items, not an empty question.
2. The scene is checked against its correctness rule — All correct by default, or Cumulative (the combined score reaches the scene's Passing %, which only this rule uses), or Specific (only the widgets you picked). See How "correct" is decided.
3. Results are saved to the server. A "Current scene" submit saves a checkpoint; the attempt stays open, and the gradebook shows nothing for it until the lesson is finished. A "Lesson" submit finishes the attempt and records the final score in the gradebook.
4. Navigation runs — if the scene is correct and its Evaluate on is Submit, the scene's Progression decides where to send the student. If the button has On Press behaviors, those run instead of the built-in submit.

Read Grading and the Score Widget for the full grading model, including grading groups and immediate-feedback alternatives.

Strong use cases

• Per-scene checkpoint — a longer lesson where each scene has a Check My Answers button so feedback comes scene-by-scene, and the lesson finishes on its closing scene as usual.
• Correct/retry branching — set the scene's Progression to navigate to "Next concept" on a correct result, and send a wrong result to a review scene. Submitted answers are locked, so a "Try Again" on the same scene can't clear them; for practice students can redo, see the pairing below.
• An early-finish option — a Lesson-submit on a scene before the closing scene, for a learner who wants to stop and turn in what they have rather than keep going.

Progression waits for Submit only when you ask it to

A scene's Progression moves the student on when the scene is correct. Evaluate on decides when that is checked, and it sits in the scene's Progression section once the scene has a destination and something to grade:

• Continuous _(the default for new scenes)_ — checked every time an answer changes. The student moves on the moment their answers are right, whether or not they press Submit. A Submit button on that scene still grades and locks answers, but it is not what moves the student.
• Submit — checked only when a Submit button is pressed. Choose this when the Submit button should be the moment the student moves on.

If you add a Submit button to a scene and expect it to control when the student advances, switch Evaluate on to Submit.

Common mistakes

• No Lesson-submit anywhere — Berdee will block the lesson from publishing, even though the closing scene handles completion on its own. Add a Submit button with Submits = Lesson somewhere in the lesson to satisfy the publish check.
• Two Submit buttons on one scene — Berdee blocks publishing with Duplicate Submit Buttons. Keep one per scene.
• Expecting Submit to control when the scene moves on — with Evaluate on set to Continuous (the default), the scene advances as soon as the answers are right. Set it to Submit instead.
• Scene submit on every scene "just to be safe" — you don't need it. Per-scene submit is for the cases listed above; otherwise reaching the closing scene captures everything.
• Adding a behavior that replaces the submit — a Submit button you never touch submits on its own; you don't have to wire anything. But the moment you add an on press behavior to it, that behavior _replaces_ the built-in submit, so it has to include a submit answers action of its own. The validator catches this and shows Submit Button Does Not Submit. Either add submit answers to the behavior or delete the behavior to get the built-in submit back. On a button set to Submits = Lesson, that submit answers step must also be set to Lesson — otherwise the attempt is never finished. The Behaviors section warns you when it isn't.

Great pairings with other widgets

• Pair Submit with scorable widgets (Multiple choice, Matching, Sorting list, etc.) — Submit is what turns "the learner picked an answer" into "the learner committed an answer."
• For practice students can redo, skip Submit on that scene: a Button labeled "Check my answers" shows a message based on whether each question Is correct, and a "Start over" button wired to reset answers clears them. Reset never clears a submitted answer, so pairing it with a Submit does nothing. Let students check their work and start over walks through it.
• See the Closing Scene for how a lesson normally finishes and shows its final score — a Lesson-submit is the exception path, not the destination.