A workshop organizer promotes the same design consultation through a newsletter and a community noticeboard. Both links lead to one request form. When the requests arrive, the organizer wants to distinguish the two placements without asking each person to remember where they found the offer.
This tutorial builds that workflow with Airtable and a miniExtensions Form. The campaign information travels in the form link and is stored alongside each submitted request. The result is a practical intake label for manual review, not a replacement for website analytics, verified referral attribution, or an advertising conversion platform.
Define the information you need
Use two separate labels: Campaign identifies the initiative, and Source identifies the placement. In this fictional example, the campaign is Autumn workshops. Its sources are Newsletter and Community board. Keeping those concepts separate lets you compare placements within one initiative without creating a new form for every link.
Decide what one row means before building. Here, one row means one submitted consultation request. It does not mean one unique person, one website visit, or one confirmed booking. Someone can submit twice, and someone can open a link without submitting. Those distinctions matter when you describe your results.
Prepare the Requests table
You need an Airtable base you can edit, a connected miniExtensions workspace, and permission to configure a Form against the base. Start with fictional test entries before sharing the form publicly. Create a table named Requests with these fields:
- Request — primary single-line text; a short description such as “Poster design consultation.”
- Name — single-line text; the requester’s name.
- Email — email; the address your team will use to respond.
- Details — long text; the requester’s question or brief.
- Campaign — single-line text; the campaign label carried by the link.
- Source — single-line text; the placement label carried by the link.
- Submitted at — created time; a reference for reviewing incoming rows.
- Review outcome — single select with New, Contacted, Suitable, and Not suitable; maintained by your team.
- Review notes — long text; internal context for the follow-up.
No linked tables or relationships are required for this small example. Using text for Campaign and Source keeps the initial setup straightforward. Maintain a written list of approved spellings so “Newsletter,” “newsletter,” and “Email newsletter” do not become three labels for the same placement. If the workflow grows, evaluate a controlled campaign catalog separately rather than adding relationships before you need them.
Create a focused request form
Before sharing with external users, confirm that the workspace has a suitable paid plan or an active free trial. The Free plan guide distinguishes builder-only testing from external sharing.
In the miniExtensions dashboard, select your workspace and Airtable base, then choose Create Extension. Select Form from the available extensions, choose Requests as its table, and name it Workshop Consultation. The extension creation guide covers this initial setup.
In the builder, include Request, Name, Email, and Details as the visible intake fields. Initially include Campaign and Source as well, so you can inspect the incoming labels during testing. Keep Review outcome and Review notes out of the visitor’s form. Those fields belong to the team’s review process, not the request itself.
Write a short introduction explaining what the consultation covers and what information to provide. For example: “Tell us which design problem you would like to discuss and any timing constraints.” Do not promise a response deadline unless the team can actually support it. Keep this workflow on deliberate user submission; it does not need automatic submission or an external email action.
Publish the Form before testing its shared URL. Configuration changes remain in Draft until you publish again, so repeat publication after hiding the labels below. See the sharing guide.
Build one link for each placement
Use Share → Copy URL in the Form Builder to obtain the form’s share URL. This toolbar path is documented in the form integration guide. Replace the placeholder below with that URL; do not distribute the placeholder itself.
The newsletter link would be:
https://web.miniextensions.com/YOUR_SHARE_ID?prefill_Campaign=Autumn%20workshops&prefill_Source=NewsletterThe community noticeboard link would be:
https://web.miniextensions.com/YOUR_SHARE_ID?prefill_Campaign=Autumn%20workshops&prefill_Source=Community%20boardUse one question mark before the first parameter and an ampersand between parameters. Repeat prefill_ for every field. Airtable field names must match exactly, including capitalization; form display titles are not substitutes. Encode spaces as %20 and encode other special characters correctly. The prefill guide explains the syntax and troubleshooting.
For this example, leave Campaign and Source out of Prefill New Records: configured new-record prefills take precedence over URL values. A fixed setting would undermine the placement-specific labels. URL prefills apply to forms, not form views inside a portal or interface.
Hide the labels after checking them
Open each link while Campaign and Source are still visible. Confirm that both carry Autumn workshops, but that the placement changes between Newsletter and Community board. Then omit Campaign and Source from the form’s field list and enable Allow prefilling hidden fields in the form’s Prefill section. The hidden-field guide recommends checking a field visibly before hiding it.
Hiding these labels makes the form less distracting. It does not make the URL trustworthy. A person can edit or share a campaign URL, and a forwarded newsletter link still carries Newsletter. Do not put secrets, permission decisions, prices, or a claim of verified identity in these parameters. Treat the stored values as the labels accompanying a submission, subject to review.
Run a small acceptance check
The following checks are a recommended test plan, not a claim that this example has been run in your workspace. Use fictional names and addresses, then inspect the resulting Airtable rows.
- Submit “Poster design consultation” through the newsletter link. Expect one new Requests row with Campaign = Autumn workshops and Source = Newsletter.
- Submit “Workshop flyer review” through the community link. Expect the same campaign and Source = Community board, with the new request details intact.
- Open the plain form URL without prefills and submit another fictional request. Check how missing labels appear. Keep these rows in an explicit “Unlabeled” review bucket rather than silently calling them direct traffic.
- Change the source parameter to Test source and submit. Confirm why the label must not be used as proof of referral or eligibility.
- After hiding the two fields, repeat the newsletter submission. Confirm that the labels still reach Airtable even though the visitor no longer sees the fields.
If a label is missing, compare its Airtable field name with the parameter, check encoding, and confirm hidden-field prefilling is enabled. Keep a simple launch checklist containing each placement, its exact destination URL, expected labels, and the date someone checked it. This is a team-maintained checklist, not an automatic link-monitoring feature.
Review requests without overstating the results
Have a teammate review new rows, set Review outcome, and record useful follow-up notes. Compare requests within the same campaign and time window. Ten submissions labeled Newsletter and three labeled Community board tell you about the requests received with those labels. They do not establish the number of readers, click-through rate, unique visitors, or conversion rate without additional measurements.
Keep raw labels available when correcting typos or classifying suspicious entries. A separate reviewed classification is often clearer than silently overwriting the original source. This is a suggested recordkeeping practice, not a built-in audit or attribution system.
Keep the link intact wherever you share it
For an embedded form, place the prefill parameters in the form URL inside the iframe’s src. Adding them only to the surrounding webpage URL does not pass them into the form. Follow the embedded-prefill instructions and test the actual published page.
Once the checks pass, use the newsletter URL in the newsletter and the community URL in the noticeboard placement. Keep one underlying request workflow and review the incoming labels alongside the actual requests. That gives the team useful campaign context without turning a simple intake form into an unsupported promise of complete marketing attribution.
