> For the complete documentation index, see [llms.txt](https://docs.openreview.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openreview.net/how-to-guides/workflow/how-to-make-submissions-available-before-the-submission-deadline.md).
# How to Make Submissions Available Before the Submission Deadline
Submissions are released to your committee by the **Create Submission Change Before Bidding** step in your [Workflow Timeline](/getting-started/hosting-a-venue-on-openreview/navigating-your-venue-pages.md#workflow-timeline). By default this step runs automatically 30 minutes after the submission deadline, and it gives all Senior Area Chairs, Area Chairs and Reviewers access to all submissions, with author identities and PDFs hidden. To release submissions earlier, move the step's activation date forward.
1. Open the Workflow Timeline for your venue and expand the **Create Submission Change Before Bidding** step.
2. Click **Edit** next to **Readers** to choose who can see the submissions. The options are **Program Chairs**, **All Senior Area Chairs**, **All Area Chairs**, **All Reviewers**, **Submission Authors** and **Public** (the Senior Area Chair and Area Chair options only appear if your venue has those roles).
* To make submissions public, select **Public** on its own. It can't be combined with other options.
* Otherwise, **Program Chairs** and **Submission Authors** must both be selected.
3. Click **Edit** next to **Restrict Field Visibility** if you want to change which submission fields stay hidden. For more on this, see [How to Hide Submission Fields from Reviewers](/how-to-guides/workflow/how-to-hide-and-unhide-submission-fields-from-reviewers.md).
4. Click **Edit** next to **Dates** and set the **Activation Date** to the time you want submissions released. Click **Submit**.
The Readers editor of Create Submission Change Before Bidding, as Program Chairs see it.
When the activation date arrives, the step updates every active submission with the readers you chose. If you selected **Public**, each submission also gets a publication date and a BibTeX entry.
{% hint style="info" %}
The step only updates submissions that exist when it runs. Submissions posted afterwards are not released until the step runs again. While submissions are open, authors can still edit them. Each edit sets the submission's readers back to the Program Chairs and its authors, so the committee loses access to it until the step runs again. To include new submissions and restore access to edited ones, set the **Activation Date** again to a time after the submission deadline, so the step runs once more when all submissions are in.
{% endhint %}
{% hint style="warning" %}
If you later change the dates of the **Submission** step (or the **Full Submission** step, if your venue has two deadlines), a **Create Submission Change Before Bidding** activation date that is earlier than the end of the new submission period (the deadline plus the 30-minute grace period) is moved to that time.
{% endhint %}
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.openreview.net/how-to-guides/workflow/how-to-make-submissions-available-before-the-submission-deadline.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
