Configure attempt limits
Set module-level passed and failed attempt limits on academic rulesets, understand resit and reassessment concepts, and see how rulesets override exam types and defaults.
Academic rulesets control module-level attempt limits — how many times a student can pass or fail a module across all its examination requirements. These limits determine how many attempt tabs appear on exams and which students are eligible for each attempt.
In examination regulations, attempt limits are the backbone of resit and retake policy: they define the attempt economy before a module is permanently failed, and they interact with whether later sittings are automatic or require a reassessment decision.
For the full lifecycle (eligibility → grading → counters → permanent failure), worked examples, and how German regulation concepts such as Wiederholungsprüfung or endgültig nicht bestanden map onto these settings, see How exam attempts work.
Why it matters
Universities almost never allow unlimited examinations. Typical frameworks:
- Cap how many times a student may fail before the module is closed (permanent failure)
- Cap how many times a student may pass (relevant when passed students can still appear on later attempts under some workflows — including grade improvement)
- Distinguish a first sitting from a resit (repeat after failure) and, in some statutes, a broader retake or reassessment period
If limits are wrong or inconsistently applied, examiners see the wrong attempt tabs, students are incorrectly marked permanently failed, and institutional statistics miscount outcomes. Configuring limits on the ruleset version — and understanding the override hierarchy — keeps Exam Center behavior aligned with published regulations.
How it fits
Limits are set on a ruleset version, resolved per student via assignment priority, then combined with the exam type attempt workflow. The Exam Center surfaces the result as attempt tabs and attempt-usage indicators.
Key concepts
| Term | Meaning |
|---|---|
| Maximum passed attempts | How many times a student can successfully complete the module |
| Maximum failed attempts | How many failed module attempts are allowed before permanent failure |
| Module-level limit | Caps apply across the module’s examination requirements, not as a separate counter per exam file |
| Auto reattempt | Exam-type workflow: eligible students can appear on later attempts while under ruleset limits |
| Reassessment period | Exam-type workflow: maximum of two attempts; attempt 2 requires reassessment approval; no attempt 3+ |
| Permanent failure | Student has exceeded failed attempts for the module |
| Resit / retake (domain) | Later sitting after failure or broader re-assessment — operationalized here as subsequent attempts under limits + workflow |
Configure limits on a ruleset version
Open Settings → OrgHub → Academic Rulesets, select a ruleset, and open a version. Under Grading configuration, set:
| Field | Meaning |
|---|---|
| Maximum passed attempts | How many times a student can successfully complete the module (default: 3) |
| Maximum failed attempts | How many failed module attempts are allowed before permanent failure (default: 3) |
Values must be between 0 and 10. When left empty, Fuxam resets to the default of 3.
Override hierarchy
When Fuxam calculates a student’s max attempts for an exam, it resolves settings in this order (highest priority first):
- Academic ruleset (user → cohort → study program assignment)
- Exam type attempt workflow (auto reattempt vs reassessment period)
- Global default (3 passed / 3 failed when nothing else applies)
Academic ruleset (highest)
The student’s effective ruleset — resolved by assignment priority — supplies the maximum passed attempts and maximum failed attempts from grading configuration. These cap module attempts regardless of exam-type defaults.
Exam type attempt workflow
Each exam type defines an attempt workflow:
| Workflow | Behavior |
|---|---|
| Auto reattempt | Students who passed can appear on later attempts while under ruleset limits; failed students can retry until limits are reached |
| Reassessment period | Maximum of two attempts; attempt 2 requires reassessment approval; no attempt 3+ |
The exam type workflow controls eligibility rules on attempt tabs but does not replace ruleset numeric limits.
Global default (lowest)
When no ruleset is assigned and no explicit values exist, Fuxam uses 3 for both passed and failed attempt limits.
Decision table — map regulation text to settings
| Regulation idea | Typical Fuxam mapping |
|---|---|
| Two failures then final fail | Maximum failed attempts = 2; confirm workflow allows attempt 2 |
| Three ordinary attempts including first sitting | Often Maximum failed attempts = 3 under Auto reattempt (confirm with your statute wording) |
| Second chance only after board / reassessment approval | Exam type Reassessment period (max two attempts; approval on attempt 2) |
| Grade improvement after a pass | Raise attention to Maximum passed attempts + Auto reattempt — see Grade improvement |
| Extra attempt after hardship or disability board decision | Usually a user-level ruleset with a higher failed ceiling — see Disability compensation and hardship |
Worked examples
Example A — Fail, fail, pass under auto reattempt
Ruleset: max failed = 3, max passed = 3. Workflow: Auto reattempt.
- Attempt 1 fails → failed counter 1/3; student eligible for attempt 2.
- Attempt 2 fails → failed counter 2/3; student eligible for attempt 3.
- Attempt 3 passes (all required exams pass in the same term at attempt 3) → module complete.
If attempt 3 failed, the student would be permanently failed. Full narrative: How exam attempts work.
Example B — High numeric cap, reassessment workflow
Ruleset: max failed = 3. Workflow: Reassessment period.
Even though the ruleset would allow three failures in the abstract, this exam type offers at most two attempts, and attempt 2 requires reassessment approval. Raising the ruleset number alone does not create attempt 3+ on that exam type.
Example C — Same-term completion edge case
A module requires two exams. The student passes Exam A in Winter on attempt 1 and Exam B in Summer on attempt 2. Under the documented completion rule, the module is not complete until all required exams pass at the same term and attempt number.
Example D — Passed ceiling for grade improvement
Ruleset: max passed = 2. Workflow: Auto reattempt. A student who already passed on attempt 1 may still appear on a later attempt while under the passed ceiling — the usual Fuxam levers for Notenverbesserung-style policy. Details: Grade improvement.
How limits appear in the Exam Center
- Attempt tabs (Attempt 1, Attempt 2, …) on an exam are generated from the resolved max attempts for enrolled students.
- The My Exams table shows attempt usage (for example, “2/3 attempts used”) based on the student’s effective limits.
- Students who exceed failed attempts are marked as permanently failed for the module.
Day-to-day grading on those tabs is covered in Grade and manage an exam.
How to configure attempt limits
Open the ruleset version that should govern your program or cohort.
Set Maximum passed attempts and Maximum failed attempts under Grading configuration.
Assign the ruleset to the relevant study programs, cohorts, or users.
Confirm linked exam types use the intended attempt workflow for your assessment policy.
Verify attempt tabs and eligibility on a sample exam in My Exams.
Best practices
- Set failed and passed deliberately — do not leave both empty unless you truly want the default of 3 / 3.
- Pair limits with workflow — a high numeric cap with Reassessment period still caps operational attempts at two with approval on attempt 2.
- Test with sample students at program, cohort, and user assignment levels so priority surprises appear before exam week.
- Communicate permanent failure as a regulatory outcome, not only a UI label — exam offices usually need a defined process after the failed limit is reached.
- Prefer new ruleset versions when attempt numbers change for a new regulation year, so historical cohorts keep their original caps.
- Read the lifecycle chapter before training examiners — How exam attempts work covers withdrawal, no-show, and final-failure context.
Common pitfalls
| Pitfall | What goes wrong | Fix |
|---|---|---|
| Expecting per-exam counters | Staff think each exam has its own three attempts | Remember limits are module-level |
| Ignoring exam-type workflow | Ruleset allows 3 failed but reassessment workflow blocks attempt 3+ | Align exam type workflow with regulations |
| Cohort still on old limits | Program ruleset updated but cohort assignment points elsewhere | Check assignment priority |
| Empty fields | System resets to default 3 | Enter explicit values from the regulation text |
| Split-term module passes | Student passed every exam but module stays open | Require same term and same attempt number for all required exams |
| Treating misconduct failures as invisible | Cheating outcomes still consume failed budget | See Academic misconduct |
FAQ
Are attempt limits per exam or per module?
Per module. A module is complete when all required exams pass at the same term and attempt number. Limits govern how many times that module attempt economy can succeed or fail.
What values are allowed?
Between 0 and 10. Empty values reset to the default of 3 for both passed and failed attempts.
Does LMS course grading consume these attempts?
No. These limits govern formal CMS Exam Center module attempts. LMS grading is course-level and does not replace ruleset attempt accounting.
What is the difference between auto reattempt and reassessment period?
Auto reattempt lets eligible students continue onto later attempts while under ruleset limits. Reassessment period allows at most two attempts, requires reassessment approval for attempt 2, and does not offer attempt 3+. Numeric ruleset caps still apply as the outer ceiling. See also How exam attempts work.
Related pages
- How exam attempts work — lifecycle, examples, and regulation context
- Assignment priority — which ruleset applies to each student
- Grade improvement — passed limits and improvement sittings
- Edit an exam type — attempt workflow on templates
- Create an exam — how max attempts surface on exam instances
- Grade and manage an exam — working with attempt tabs when grading