📌 Note: Two different places are called Settings. This article covers the Settings group inside one application. Defaults you define once and reuse across every application, such as deposits, discount codes, and the Rules referenced below, live in Global Application Settings.
Overview
Every setting that applies to one specific application lives in the Settings group of that application's left-hand menu. Open the application from Applications > Applications > All Applications, then look under Settings below the Steps and Content groups.
There are eight items:
General: identity and version settings, including the application name and SnapApp.
Availability: whether the application is accepting submissions, and when.
Identity Verification: whether applicants must verify their identity, and which Rules apply.
Applicant Experience: what applicants see and can do inside the application.
Fee & Deposit: how applicants pay to apply, and the deposit collected after admission.
Submission Prevention Rules: condition-based rules that block submission.
Autoresponder Messages: the messages sent to applicants, customized for this application.
PDF Output: options for generated PDF documents.
Where Did the Setting I Saw at Creation Go?
The New Application dialog presents most settings in a single General card. Once the application exists, those same settings are grouped by purpose across the Settings menu, so a setting you configured at creation may not be under General when you come back for it.
Setting in the New Application dialog | Where it lives afterward |
Application name · Description · Enable SnapApp · Default Application · Icon | General |
Alert When Required Fields Are Complete · Should Applicant Be Able To Withdraw Application · Show Application Status · Show Documents Section · Submitted Status Sidebar Text | Applicant Experience |
Allow New Registrations · Registration Rate Limit · Will International Students Apply Using this App | Availability, on the Status card |
Hide blank responses · Hide unused conditional fields | PDF Output |
The whole Payment card, plus any deposit you attached | Fee & Deposit |
📌 Note: Default Application only appears once Enable SnapApp is on, since it chooses which version opens first.
General
Identity and version settings for this application.
Application name: visible to students when they choose which application to submit, so make it descriptive.
Description: optional, and for internal use only. Use it to give your staff context.
Enable SnapApp: SnapApp is a shorter version of the application containing only the required fields. With it on, applicants get a toggle to switch between the full application and SnapApp.
Turning SnapApp on also reveals Default Application, which chooses the version that opens when applicants first enter.
Icon: choose the icon shown next to the application name on the Application Site. Use the search box to filter the icon set.
Availability
The single source of truth for when this application accepts submissions.
Availability holds a Status card, which controls whether the application is on at all, and a Schedule card, where you add a window for each intake with open and close dates, optional annual recurrence, and Late Submission Rules for groups that may submit after a window closes.
It also drives the application's computed status: Inactive, Scheduled, Active, or Closed. That status is read-only, on both the application header and the All Applications page.
Identity Verification
Whether applicants must verify their identity before or after submitting.
Set the default identity verification state for this application, then add the Identity Verification Rules that should apply to it. If you add more than one Rule, drag them into order: the system evaluates them in order and presents the first matching Rule to the applicant.
Rules themselves are created once at the module level and reused. See Identity Verification Rules for that, and Identity Verification for how the feature works.
Applicant Experience
What applicants see and can do inside the application.
Alert When Required Fields Are Complete: lets applicants choose to submit or keep going once they have filled in every required field. Useful when you want to capture a complete-enough application rather than lose someone who stalls on optional questions.
Should Applicant Be Able To Withdraw Application: lets applicants withdraw their own application from their dashboard.
Show Application Status: lets applicants see that their application is in progress, until a decision is released.
Show Documents Section: shows the documents section in the applicant's sidebar.
Submitted Status Sidebar Text: the message applicants see in the sidebar after they submit. Use it for next steps, for example asking them to complete their checklist items so review can begin.
Fee & Deposit
Configure how applicants pay to apply and the deposit collected.
Payment
Active: turns application fee collection on.
Discounts: allows discount codes on this payment. Note that discount codes do not work with the User Defined payment type. Codes are created and managed in settings.
Personal Check: lets applicants choose to mail a check instead of paying by card. Turning it on asks you who the check is made out to and where it should be mailed.
Payment Description: a brief description of what the payment is for.
Credit Card Provider: pick one if your institution has more than one provider configured.
Account: an account number or name, for your own internal tracking.
Payment Type: Fixed, Conditional, Calculated, or User Defined. The fields below it change with your choice. Choose Conditional if you want to use Payment Rules. See Payment Types.
Amount: the fee, for a Fixed payment type.
Required to submit: whether applicants must pay, or enter a waiver, before they can submit.
Payment Dialog Title: the help text shown in the payment dialog. It is a rich text field, so you can add links, which makes it a good place for your payment and refund policy.
Deposit
Deposit: select an existing deposit, or click Add Deposit to create one. Edit Deposit opens the selected one for changes.
Deposit Unique to Registration: requires a separate deposit for each submission to this application. With it off, one deposit payment applies across multiple submissions.
Deposits themselves are defined once at the module level. See Deposits.
Submission Prevention Rules
Condition-based rules that stop an application from being submitted.
Add the Rules you want to apply to this application. The Rules themselves, and the condition types available to them, are created at the module level.
📌 Note: Submission Prevention Rules block a submission. If instead you want a specific group to be allowed to submit after an intake has closed, use a Late Submission Rule on that scheduling window under Availability.
Autoresponder Messages
The messages sent to applicants, customized for this application.
Eight autoresponder types can be customized per application. If you customize one here, it is used instead of the module-level default, and the title picks up an edited tag so you can tell at a glance.
🚨 Important: Autoresponders require activation at two levels. The autoresponder must be enabled in module-level Application Settings and set to Active within this application in order to send.
PDF Output
Options for generated PDF documents.
Hide blank responses: hides fields with no submitted value in generated PDFs.
Section labels still appear, so you keep a record of what was asked even where the applicant left it empty.
Hide unused conditional fields: hides fields that were never shown to the applicant because of conditional logic, along with hidden fields.
📌 Note: hidden fields can still hold data, for example a pre-populated country code or a value set through the API to drive conditional logic. Turn these on only when you want a more condensed PDF.