Accepting responses

Whether a form is open is a single switch in the builder. This page covers how to flip it and exactly what respondents are told in each state.

The top bar carries a state pill reading Accepting responses or Not accepting responses. Click it to switch intake on or off. The change saves immediately, with no separate Save.

A form must be published before it can be switched on. Respondents are only ever served a published version, so switching intake on beforehand would put an unfinished draft in front of them. If you try, the builder refuses and tells you to publish first. This is rarely something you meet in practice, because publishing a form for the first time switches it on for you.

What a respondent sees

Form state	What a respondent sees
Accepting responses	The form
Not accepting responses, and it has been published	Form closed: This form is not accepting responses right now
Never published	Form not available, as though the form does not exist

The last row is deliberate. Saying “closed” about a form that was never published would confirm, to anyone guessing URLs, that the form exists. An unpublished form stays invisible instead.

A closed form says so consistently: a respondent who had the page open before you closed it, and submits afterwards, is told the form is closed rather than that it does not exist.

A closed form, or one that has hit its response cap, also refuses file uploads, so a respondent cannot leave files behind for a submission that will not be accepted.

Scheduled windows and response caps

An Open from and Close at window and a Close after this many responses cap both close a form on their own, and produce their own notices: This form is not open yet, This form is no longer accepting responses, and This form has reached its response limit. Both are set under Availability in Form settings.

Forms at or near their cap, and forms closing within seven days, are listed in the dashboard’s Needs attention panel.

When a form reaches its response limit, everyone on the notify list gets one email. Notification and confirmation emails are sent in the background, so they arrive shortly after the response rather than instantly.

Responses that share a link id

A form link can carry an id for the respondent, as the sliickCid value in an emailed link. If two responses to the same form arrive under the same id:

• With the same answers, such as a double click or a retry, the response is recorded once.
• With different answers, the second is kept and marked Suspected duplicate. It counts toward the response limit. Processing skips it and its webhook is held until someone marks it genuine. The notify list gets one Suspected duplicate summary per delivery instead of a New submission email per response, and the respondent’s own confirmation email is still sent.

The same id on two different forms is never a duplicate. The placeholder the email snippet ships with, REPLACE_WITH_RECIPIENT_ID, counts as no id at all. See The responses console for what to do with a flagged response.

Use a random id for each recipient, never an email address. If one id is shared by everyone, such as an unresolved merge tag in the email, identical answers are dropped silently as repeats of the first, and different ones are all flagged.

A new install shows the flag on the Form Submission page layout. An upgrade does not change an existing layout, so on an upgraded org, Sliick Responses is where the flag is shown.

Where the state is shown

The dashboard shows this state as a read-only Accepting or Paused badge. The builder is where you change it.

For public forms on Experience Cloud: a closed form only reads as closed if the site’s guest sharing rule still shares it. That rule needs both criteria. See Guest access for public forms.