A website brief and a print brief share some questions, but they rarely need exactly the same answers. Asking every requester about both can produce a long form filled with irrelevant questions and “not applicable” responses.

This tutorial builds a small project-intake form with a common opening page, a page for the selected work type, and a shared final page. The example uses one Airtable table and one miniExtensions Form. Page selection follows the requester’s answer; a team member still reviews and assigns the work afterward.

Define the brief before building the form

Our fictional studio, Cedar Creative, accepts two request types: Website and Print. Every request needs a name, contact email, title, business goal, and desired delivery date. Website requests need a page estimate and reference URL. Print requests need a format and quantity.

The reader outcome is a clear intake path, rather than a complete project-management system. For assignments, approvals, and work orders after intake, use the broader project request and work order guide. Here, keep those later decisions out of the requester’s questionnaire.

You need permission to create fields in the example Airtable base and configure a Form in its connected miniExtensions workspace. Use fictional data while testing. External sharing requires a suitable paid plan or an active trial; the Free Plan documentation explains the internal-testing restriction.

Create one table for complete project briefs

Create a table named Project Briefs. These names and choices are a suggested example schema, not a built-in template. No linked-record relationship is needed for this version: one submitted brief is one record.

  • Brief Title: primary field, single line text.
  • Requester Name: single line text.
  • Contact Email: email.
  • Work Type: single select, with Website and Print choices.
  • Business Goal: long text.
  • Website Page Estimate: number, integer precision.
  • Reference Website: URL.
  • Print Format: single select, with Flyer, Poster, and Brochure choices.
  • Print Quantity: number, integer precision.
  • Desired Delivery Date: date.
  • Additional Context: long text.

Prepare two sample briefs on paper before configuring conditions. “Autumn workshop landing page” is a Website request with a page estimate of 3. “Community open-house flyers” is a Print request for 250 flyers. Both should reach the same final scheduling questions. Neither example requires an actual customer, live order, or payment.

Keep Work Type as a single select. A brief that includes both deliverables needs a deliberate design decision: collect two briefs or extend the schema and conditions later. Do not quietly treat an ambiguous “Both” option as Website.

Arrange the questions into pages

Create a miniExtensions Form for Project Briefs and add the listed fields. Use this order:

  • Request overview: Brief Title, Requester Name, Contact Email, Work Type, Business Goal.
  • Website details: Website Page Estimate, Reference Website.
  • Print details: Print Format, Print Quantity.
  • Timing and context: Desired Delivery Date, Additional Context.

In the builder, use + Add and select Page, then choose the first field for each new page. Start Website details at Website Page Estimate, Print details at Print Format, and Timing and context at Desired Delivery Date. Name the sections for the reader, using the labels above.

To check the layout mode, open Form settings, then Styling & Customization, and enable Multi-page mode for section headers. The multi-page setup documentation explains that section headers define pages and their titles appear in navigation. New forms default to this mode, but an existing form may differ.

Show only the relevant detail page

Configure the Website branch on its first field, Website Page Estimate. Open that field’s Section Header settings and enable Hide this entire section if this field is hidden. Then open Conditional Field and add a condition that matches Work Type to Website.

Repeat on Print Format, the first field of the Print page, using Work Type matched to Print. Keep the opening and final pages unconditional. The conditional-section documentation confirms that this section setting also controls pages in multi-page mode.

Put the branch condition on the correct first field. Hiding only Reference Website would leave the rest of the Website page in place. Likewise, moving a different field ahead of Website Page Estimate later deserves another test of the page boundary and condition.

Keep Work Type visible on the opening page. The field-condition rules explain that conditions use record values, including values in conditionally hidden fields. If one field should appear only while another is visible, repeat the relevant visibility conditions. Keep the branch selector visible so requesters can review and change their choice.

Require useful answers on the visible path

Open each field’s settings and enable Required for Brief Title, Requester Name, Contact Email, Work Type, Business Goal, Website Page Estimate, Print Format, Print Quantity, and Desired Delivery Date. Leave Reference Website and Additional Context optional so a requester without a reference site can still submit.

A required field that is conditionally hidden does not block submission, according to the required-field documentation. A Website requester therefore needs the page estimate, while a Print requester needs the format and quantity.

In a multi-page form, required-field and validation checks apply as the requester proceeds through each page. A missing answer on the final page should not prevent leaving the opening page. The progress indicator also reflects conditional sections, so the inactive branch should be absent from the visible path.

Do not confuse requiredness with a complete review policy. A filled quantity or requested date still needs business review. Cedar Creative’s staff decide whether the quantity is practical and the date achievable; this example does not automatically accept a job or promise delivery.

Test both branches before sharing

Use the following acceptance checks with fictional submissions. They are a test plan for your implementation, not a claim that these scenarios have been run for you.

  • Website path: choose Website. Confirm Website details appears, Print details disappears, and the final page remains reachable. Leave the page estimate blank to check its requirement, then enter 3 and complete the brief.
  • Print path: start a new brief, choose Print, and enter Flyer with quantity 250. Verify the opposite page behavior and inspect the resulting Airtable record.
  • Change of mind: enter Website details, return to the opening page, and change Work Type to Print. Complete only the active branch and inspect which fields reach Airtable.
  • Missing selector: leave Work Type empty. Confirm the requester cannot move past its required check and that the common page is still visible.
  • Final page: leave the desired date blank. Confirm the relevant check occurs there, then supply a date and finish.

The hidden-field saving documentation says fields hidden at submission are omitted from Airtable additions or updates. Do not rely on a hidden branch to preserve newly entered answers, or assume hiding a field clears an existing stored value. Inspect the record after a branch change.

Publish the tested version and keep the scope clear

Use the builder’s publication controls when your configuration is ready. Changes stay in Draft until published. Open the published form through Share or Open Form and repeat the short Website and Print paths on desktop and mobile. The end-user preview guide explains how to distinguish the public experience from editor-only controls.

Pagination organizes questions; this tutorial has not configured saved progress, automatic assignment, email notifications, or approval routing. Add those only as separate, reviewed requirements. Start with the two tested paths, watch for unclear questions, and refine the brief before introducing more branches.