> For the complete documentation index, see [llms.txt](https://synap.ac/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://synap.ac/docs/platform/exams/scheduling-and-communication.md).
# Scheduling and communication
The **Schedule** page sets the overall dates for the exam and can also give each student their own window. The **Communication** page controls the emails and visibility that tell students the exam is available.
The schedule shown on the Exam is not necessarily the final date for every candidate. Relative deadlines, access arrangements, resits and attempt-specific adjustments can produce different windows. Use the candidate attempt record when answering “when can this person take the exam?”
The Schedule page combines the overall exam window with the rule used to calculate each student’s deadline.
### Global schedule
| Schedule | Open | Close | Useful when |
| ---------------- | -------- | -------- | ------------------------------------------------- |
| Fixed date range | Required | Required | Everyone must finish by a shared closing date |
| Indefinite | Required | None | Ongoing enrolment with no shared final close date |
Times are entered in the timezone shown in your portal. Students see them converted to their local timezone. Include the timezone in any separately written emails when students are in different regions.
### Candidate deadline
| Deadline | Candidate open | Candidate close |
| -------------------------------------- | --------------------------- | ---------------------------------------------------------------------------- |
| Same as fixed date range | Global open | Global close |
| Relative within a fixed range | Registration/enrolment time | Registration plus the relative duration, or global close—whichever is sooner |
| Relative within an indefinite schedule | Registration/enrolment time | Registration plus the relative duration |
#### What a relative deadline means
A relative deadline gives each student a window based on when they are registered. This means the act of registering a student also starts their schedule.
Example: global schedule 1–30 September, relative deadline 7 days.
| Candidate registered | Opens | Calculated close | Actual close |
| -------------------- | ------------------- | ------------------ | ---------------------------- |
| 2 September, 09:00 | 2 September, 09:00 | 9 September, 09:00 | 9 September, 09:00 |
| 27 September, 15:00 | 27 September, 15:00 | 4 October, 15:00 | 30 September at global close |
The second candidate receives less than seven days because the fixed exam close is a hard ceiling. Resits also cannot extend beyond that ceiling.
{% hint style="warning" %}
Bulk-registering candidates early starts their relative windows early. If candidates should receive equal time from a launch event, coordinate registration timing or use a fixed shared window.
{% endhint %}
### Submission due date
The submission due date is advisory. It is shown to candidates and submissions after it are categorised as late, but it does not itself deactivate the attempt. Use the close date to enforce access; use the due date to express an expected deadline within that access window.
### Attempt-specific windows
Attempt management can adjust a candidate's open date, close date and extra-time multiplier. Bulk edits warn when selected attempts currently differ. Expired attempts may require special handling.
An attempt-specific date can be earlier or later than the standard value. Use this for an individual extension or access arrangement, and check the local date and time shown on that student’s attempt.
### Automated registration emails
When enabled, an exam information email is sent when the exam is scheduled or when a candidate is added to the exam group. It can also send resit notifications when candidates fail and have another attempt.
Disable automation when an external proctoring platform must deliver the secure exam link. In that workflow, export candidate links and import them into the external system instead of emailing direct access from Synap.
### Results emails
Disabling result emails stops the system notification when results become visible. It does not hide the result page. Use the Results page to control what is released and the Communication page to control the email.
### Candidate visibility
**Hidden** removes the exam from the candidate's exam table. Use this when candidates enter through externally supplied links. A hidden exam is not an access control: anyone with a valid authorised link still follows the attempt's access rules.
### Check what the student receives
Before live registration, verify:
* sender identity and reply path;
* exam name, local date/time and timezone wording;
* device, browser, proctoring and installation requirements;
* passcode or invigilator instructions without premature disclosure;
* support contact and incident process;
* resit wording and close-date limits;
* test delivery to common mail providers and organisation filters.
Keep dates in system configuration and human-written copy consistent. If an email contains a manually typed deadline, it will not update automatically when an administrator later changes the schedule. Prefer supported variables where available and still proof the rendered message for a real test candidate.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://synap.ac/docs/platform/exams/scheduling-and-communication.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.