Access and Submission Conditions
  • 17 Jul 2024
  • 2 minute read
  • Dark
    Light
  • PDF

Access and Submission Conditions

  • Dark
    Light
  • PDF

Article summary

When creating a form, event, or interview, you can restrict who is eligible to open the form or submit a response.

In each of these cases, we want to display a message to the respondent explaining why their action was rejected.

Accessing form access and submission conditions

To edit submission conditions, select Edit Conditions at the right side of the Edit Form page.

The edit conditions interface is split into two sections:

Access Conditions

Only available if the respondent will be known prior to the form loading.

For example, if the form is application-scoped, or is person-scoped and flagged to require login.

Submission Conditions

Available for all scopes except Application Page.

Configuring form access and submission conditions

Each of these sections has two configuration options, an “Access Denied” message and filters.

Access Denied message

Lets you customize the message displayed when the action is denied.

  • Merge fields are not currently supported within the messaging.

  • For both access and submit conditions, the message is written for people that CANNOT access/submit the form, while the filters are written to define those that CAN; i.e., the message is shown when the registrant does NOT meet the filter criteria.

Filters

Identifies the population permitted to perform said action by using filters.

  • The filters available for use are contextually aware of the form's scope; i.e., no application-scoped filters in a person-scoped form.

  • Application and person-scoped filters used in Submission Conditions are evaluated inclusive of the data on the form. If the data entered via the form will update a system field in such a way that the filter criteria is met, then submission will be permitted.

Examples

Prevent access/submission unless application has been submitted

In the case where an application-scoped form should only be accessible if the associated application has been submitted, the configuration might look like something like this:

Screen_Shot_2020-12-15_at_2.11.39_PM.png

In the event of the application not being submitted, attempting to access the form will result in the following error message:

You have not submitted your application. This form is only available for those who have 
submitted their application. Please submit your application and try again.

Prevent creation of more than one application

In the case where an application-creation-scoped form should not be accessible after the application has been submitted, the configuration might look like something like this:

This filter logic uses two subquery filters:

  • GUIDs are not the same uses a Comparison aggregate to check the inequality of two exports, All Applications GUID and Application GUID (the GUID of the .

  • Rounds are the same uses another Comparison aggregate to check the equality of two exports, All Applications Round and Application Round.

The combined effect of these two subquery filters is that, if an applicant tries to submit the application creation form with an existing application in the smae round, they will not be allowed to submit the form.

💼 Try a Slate example

You can import this filter logic, along with the application-creation form that goes with it, using the following Suitcase ID:

f1de28ec-b440-4416-8185-94f32fd79e8a:slate-examples

In the event of the application having already been submitted, attempting to access the form will result in the following error message:

You have already submitted this application.


Was this article helpful?