The closing date was Friday. It is now Monday morning, the form is still taking answers, and eleven submissions arrived over the weekend. Some of them are from people who read the deadline and ignored it. At least one is from someone who never saw a deadline anywhere. Deciding what to do with those eleven is a bigger job than closing the form, which takes about four seconds.
Microsoft Forms gives two ways to stop responses and one way to explain the stop to whoever arrives late. It does not give a way to stop after a set number of answers, which is the thing people most often come looking for. What follows covers the controls that exist, the one that does not, and the part of the job that closing the form does not touch.
What closing changes, and what it leaves alone
Closing a form stops new submissions. Nothing else moves. The responses already collected stay in the Responses tab and in any workbook the form is feeding. The form is not deleted. The link still resolves, and someone who opens it lands on a message rather than on a blank page or an error.
That matters because several actions feel like closing and are not the same operation.
Deleting the form takes the responses with it. This is the one that cannot be undone by flipping something back, and it is the reason closing should always be the first choice when a form has served its purpose.
Removing the link from a page hides the form from new visitors while anyone holding the URL can still submit. Forms are not protected by obscurity, and a link circulated once is circulated permanently.
Unsharing the form changes who can open it, which stops responses from outside the new audience while leaving the form open to everyone still inside it. That is a useful control and a poor substitute for a deadline.
Closing is reversible. Turning responses back on reopens the same form at the same URL with the same submissions attached, which is why a deadline extension should never involve building a second form.
The switch, and the date window
Both controls live in the same place. Microsoft's documentation on deadlines and settings gives the path as signing in at the Forms site, opening the form or quiz, and choosing Settings from the action bar.
The manual control is the Accept responses checkbox. Clearing it stops submissions the moment it is cleared. This is the right control for a form whose end is a decision rather than a date, such as a sign-up list that closes when the room is full or a request form paused while a team catches up.
The scheduled controls are Start date and End date. Setting them defines the window in which submissions are permitted, which means nobody has to be awake or at a desk when the deadline lands. A start date also solves a smaller problem worth mentioning: a form that has to be built and shared in advance but must not accept anything before an announcement goes out.
The choice between the two is not really a choice. A form with a stated deadline should carry an end date, because a manual switch depends on a person remembering, and the eleven weekend submissions in the opening paragraph are what that dependency costs. The manual checkbox is for the cases a date cannot express.
One switch covers the whole form
Accepting responses is a property of the form, not of a section or a question. A form collecting three unrelated things closes all three at once. Where two of those things run on different deadlines, that is an argument for two forms rather than for clever section logic, and it is worth deciding at design time rather than the week before the first deadline.
The message people see when they arrive late
Microsoft's documentation notes that when submissions close, an empty text box appears where a customised message to recipients can be entered. That box is the only communication anyone gets, and leaving it at the default is a small, common and avoidable source of follow-up mail.
A closed form with no explanation produces one predictable outcome: the person emails someone to ask whether the form is broken. A message that answers the obvious next question prevents most of that traffic. Three things belong in it. That the deadline has passed, stated as a fact rather than an apology. What the person can do instead, whether that is an address to write to or a date when the form reopens. And where anyone already in the process stands, because a closed form is also read by people who submitted successfully and are now wondering whether it went through.
The text is worth writing before the form is shared, not on the morning it closes. A form that closes automatically on an end date will close whether or not anyone has drafted that message.
The control that does not exist
A large share of the searching around this topic is people looking for a way to close a form after a set number of responses. That setting is not in the deadline and settings documentation, which describes date based controls and the accepting responses checkbox and nothing that counts submissions.
The documented limits are far higher than anything a cap would be used for. Microsoft's limits page gives up to 5,000,000 responses per form and up to 200 questions, with up to 4,000 characters in a single question response and up to 200,000 characters in total per response. Those are ceilings for the product, not a place to stop an event sign-up at forty.
So a form that must stop at a fixed count has three options, and each costs something.
| Approach | What it costs |
|---|---|
| Watch the count and clear Accept responses by hand | Somebody has to be watching, including evenings and weekends |
| Set an End date well before the count could be reached | Turns away people who would have fitted |
| Automate it with a flow that watches responses and changes the setting | A piece of automation nobody on the team may maintain later |
| Accept over-subscription and decide afterwards | Requires a rule for who gets in, written before the submissions arrive |
The last row is the one most teams end up on, and the only one that gets easier rather than harder as the numbers grow. It also shifts the problem to where it actually lives, which is the handling of submissions rather than the state of the form.
Telling people before it closes, not after
Closing does not notify anyone. The people who were sent the link and have not answered get no message, and the first they hear of the deadline is the closed page. Every late submission and every complaint about a deadline has that fact somewhere in its history.
A reminder sent before the close does more for a response rate than any amount of form design afterwards, and it costs one message. Where a form went out to a known list, one reminder a few days out and one on the final day is the usual shape. Where the form was published rather than sent, the announcement page carrying the link should carry the deadline in text next to it, because the form's own description is read only by people who already clicked.
There is a second reason to announce the close rather than let it happen. A deadline that arrives without warning generates individual requests for exceptions, each of which has to be answered by a person, and answering them inconsistently is worse than either granting or refusing them across the board. A stated deadline with a stated reminder makes a refusal defensible. A silent one makes every refusal look arbitrary.
It is also worth checking, before the form closes, whether the deadline is written in more than one place. A date in the announcement, a different date in the form description and an End date set to something else again is common, and the form's behaviour will follow the End date regardless of what anyone was told. Reconciling the three takes a minute and prevents the argument.
The part closing does not solve
A closed form is a form with a finished intake and unfinished work. Whatever came in still has to be read, decided on, and answered, and closing does nothing for any of that.
This is where the weekend submissions become a real cost. Eleven late entries need a decision, that decision needs to be applied consistently, and every person involved needs to be told the outcome. None of that is visible in the form. The Responses tab shows what arrived. It does not show which ones have been read, which are approved, who is handling the awkward one, or which people have already been replied to.
So the state gets kept somewhere else. Usually a spreadsheet exported from the form, with a colour or a column somebody added, updated by hand, going stale from the moment two people start editing it. The reply goes out from a mailbox, unconnected to the row it belongs to. A week later, the question of whether a given person was answered can only be resolved by searching mail.
The fix is not a better close button. It is keeping the submission, its status and its reply in one place, so that closing the intake and finishing the work are separate facts about the same record. A form tool built that way gives each response an owner and a status and lets the reply go out from the same screen, which is also what makes a late submission easy to deal with: it can be marked and decided rather than remembered. Comparing how different intake types are structured is easier with worked examples, and the use cases page is organised that way.
Before closing, check the reply side
Two checks are worth doing on the day a form closes. Whether every submission has been read by a named person, rather than merely collected. And whether anyone is waiting on an answer that has not gone out, since a closed form removes the pressure that was keeping the queue visible. Forms that close quietly tend to leave a short tail of people who never heard anything, and that tail is what people remember about the process.
What to change first
If the form has a stated deadline, put that deadline in the End date field now and write the closed message before it is needed, because both of those failures cost the same follow-up mail. Then decide where the status of each submission is going to live once the intake is shut, and if the honest answer is a spreadsheet nobody trusts, the shorter path is a form tool that carries an owner and a status on the response itself, which the demo of Halict shows directly.
Q1. Can Microsoft Forms close automatically after a certain number of responses?
There is no setting for that. The documented controls are the Accept responses checkbox and a Start date and End date window, none of which counts submissions. Stopping at a fixed number means watching the count and clearing the checkbox by hand, automating the change with a flow, or accepting more than the target and deciding afterwards.
Q2. What do respondents see when a Microsoft Form is closed?
They see a message on the page rather than the questions, and Microsoft's settings documentation notes that a text box appears where a customised message can be entered when submissions close. Leaving that box empty is the main reason people write in asking whether the form is broken. The message should say the deadline has passed and what to do instead.
Q3. Does closing a form delete the responses?
No. Closing stops new submissions and leaves everything already collected in the Responses tab and in any linked workbook. Deleting the form is the action that removes responses, and it cannot be reversed by turning a setting back on.
Q4. Can a closed Microsoft Form be reopened?
Yes. Selecting Accept responses again, or extending the End date, reopens the same form at the same URL with the existing submissions still attached. Building a second form for an extended deadline splits the responses across two places for no benefit.
Q5. Can one section of a form be closed while the rest stays open?
No. Accepting responses is a property of the whole form, so clearing it stops every question at once. Where two parts of an intake run on different deadlines, two separate forms are the workable answer.