CORE CONCEPTS

Application forms

The application form is what applicants fill out. Awards Manager includes a visual form builder so you can add fields, rearrange them, and configure validation without writing code.

Field types

  • Short text. Names, titles, single-line answers.
  • Long text. Stories, explanations, multi-paragraph answers.
  • Email. Validated as an email address.
  • URL. Shown as a clickable link in reviewer view.
  • Number. For revenue, headcount, scores.
  • Dropdown. Pick one from a list you define.
  • Multi-select. Pick several from a list.
  • Date. Date picker.
  • File upload. Photos, PDFs, supporting documents.

Required vs optional

Mark a field as required if you cannot process the submission without it. Required fields prevent submission until they are filled in. Everything else stays optional.

Built-in contact info

Every application form automatically asks for the applicant's email, name, and business or organization before your custom questions. These fields power resume links, reminders, submission lists, exports, reviewer views, and committee packets.

Field keys after submissions exist

Each field has an internal field key that Awards Manager uses to store answers. Once a program has submissions, those keys are locked so older application data stays readable and exports stay consistent.

You can still edit the wording people see — labels, help text, placeholders, options, required status, and reviewer visibility. If you need a different data point, add a new field instead of renaming the existing key.

Per-category fields

Sometimes different categories need different questions. For example, “Volunteer of the Year” might ask about hours volunteered, while “Small Business of the Year” asks about revenue growth.

You can scope a whole section to specific categories, which is the cleanest way to manage awards programs with many category-specific questions. Fields inside that section inherit the section's audience. You can also scope an individual field more narrowly when you need an exception.

Use the builder's category view to narrow the editor to one category at a time. This shows the shared sections plus that category's specific sections, making large forms easier to review before you publish.

Eligibility questions

Above the form fields in the editor, you can add yes/no eligibility questions that gate the application — applicants see them as a short interstitial step before the form opens.

  • Common uses: “Are you a chamber member in good standing?”, “Has your business been operating for at least 2 years?”, “Do you live in our service area?”
  • Each question can apply to all categories (the default) or only to specific ones — useful when one category has stricter requirements than another.
  • Applicants who answer “no” to any question are routed to a polite “not a fit” page. They can change their answers and try again.
  • Leave the section empty if you don't want a pre-check — applicants go straight to the form.

Conditional questions (skip logic)

Any field in the form builder can be set to only appear when an earlier field has a specific answer. Useful when one form covers multiple paths — different audiences, different categories, different documents required.

Open the “More” panel on a field and look for Show only when…. Pick a trigger field above this one, an operator (is / is not), and a value. The field disappears from the applicant's view until they pick the matching answer.

  • Equality:“is” / “is not” — exact match. Works on every field type.
  • Numbers and dates:“is greater than,” “is at least,” “is less than,” “is at most” for numeric fields; “is before,” “is on or before,” “is after,” “is on or after” for date fields.
  • Multi-select:“is” / “is not” read as contains / doesn't contain.

Common patterns:

  • “If applicant type isgraduate, show GRE score.”
  • “If requested amount is greater than$50,000, show budget justification.”
  • “If year founded is at least2020, show first-year survival narrative.”

How conditional fields behave:

  • Fields hidden by a condition are skippedfrom the required-field counter and from the missing-fields check on submit. Applicants can't fail to submit because of a field they can't see.
  • If an applicant fills in an answer that later gets hidden by a rule change, the value is preserved in the draft (so toggling back restores it), but excluded from the final submission.
  • When you delete a trigger field, any rules that referenced it are stripped automatically and you'll see a warning at the top of the form editor.

v1 supports a single rule per field. AND/OR groups, empty-state checks (“is blank” / “is not blank”), and partial-text matching are coming in a future release.

Blind review

Toggle “Hide from reviewers” on any field to keep it confidential from judges. Common uses:

  • Applicant contact information, so reviewers cannot be biased by name recognition
  • Internal-only fields like tax IDs

The field still gets collected and stored. Admins see it in the submission detail page. Reviewers see a small note saying some fields are hidden for blind review.

Tips that make better forms

  • Keep it short. Long forms get abandoned. Most great applications use five to ten questions, not thirty.
  • Use long-text fields sparingly. One or two open-ended questions is usually plenty.
  • Order matters. Put the most interesting question first so applicants get invested.
  • Test it yourself. Open your public URL in a private browser tab and try filling it out before launching.
Still stuck? Customers with an account can reach support from the user menu in the app. Or contact us here.