# Quiz Attempts
### How to enable attempts tracking
The **Quiz** Component has the capability to allow a user to take multiple attempts at a quiz. This is enabled by changing the **Retry Behaviour** setting under *Properties* when the **Quiz** is selected.
The following options are available:
* **Disabled** turns off retries completely and if failed, the learner cannot retry.
* **Reset Failed** will clear responses for any questions the learner got wrong when *Retry* is clicked.
* **Reset All** will completely clear the quiz when *Retry* is clicked.
{% hint style="info" %}
**Tip:** Retry behaviour is useful for allowing learners to re-complete self-checks again until they get the answer correct, but can also be useful for assessments.
{% endhint %}
### How to show past attempts
If you want to allow a learner to see their past attempts, the above setting can be used in conjunction with the **Attempts Table** component which can be dragged into any existing **Quiz** component.
No additional setup is required to use the **Attempts Table** – it will automatically synchronise the quiz with the attempt selected in the table. When a past attempt is selected, the quiz will become disabled and the question inputs will show the response selected at that point in time.
### Use with an assessor flow
Enabling *Attempts Tracking* in conjunction with an *Assessor Workflow* presents an interesting use-case because it provides a way for a manager, observer or assesor to mark and leave feedback against a learner’s submission and then provide visibility to that learner over their feedback.
When using with an *Assessor Workflow*, we recommend the following guidelines are followed:
* Configure the **Completion Condition** for the page to "None / Module Roll-Up" since the activity's completion should be managed by the assessor instead of the learner's initial quiz submission.
\
Then create a workflow that will **Assign a Task** to an assessor with a trigger to **Mark Completed** when the assessor approves the page.
* Create an “Assessor” *variation* with the audience of **Target User exists** so that you can change content for the approver.
\
It's now possible to use the variation to provide the power to either the learner or the assessor to control who kicks off a *retry:*
* Set *Retry Behaviour* to "disabled" by default and enable it for the *Assessor* variation to provide the assessor with the ability to retry and re-mark an assessment.
* Or, set *Retry Behaviour* to "reset..." by default and then disable it for the *Assessor* variation to force the learner to re-submit the quiz with new responses.
* Use the *Assessor* variation described above to hide and show questions for either the *Learner* or the *Assessor*. Using variations, you're able to design a quiz where an initial set of questions are shown to a *learner* and then the *assessor* will see "grading-specific" questions for marking correctness and providing feedback.
* Use the **Logic component** to hide or show questions based on whether a *Learner* is viewing past attempts. This is important if you only want to show assessor responses when a learner navigates to an old attempt via the **Attempts Table**.\
Logic supports the following conditions for **Attempts Tables**:
* **is Active Attempt Selected** is triggered when the user selects an unsubmitted attempt.
* **is Old Attempt Selected** is triggered when the user selects an attempt that has already been submitted.
* **is Attempt with Assessor Submission** is triggered when a user selects an attempt that an assessor has also reviewed and submitted their feedback against.
* **is Attempt without Assessor Submission** is triggered when a user select selects an attempt that hasn't received feedback from an assessor yet.
{% hint style="info" %}
Note that **responses** and **attempts** are synchronised between both *learner* and *assessor* automatically. Anything the learner responds to will be propagated to the assessor and vice versa to ensure everyone is working from the same state.
{% endhint %}
