Skip to main content

​
Forms

Under App Blueprint → Forms, GenieForge stores structured intake: a fixed set of fields (and optional show/hide rules) people fill in portal, chat, or guest flows. You describe who submits what and what happens next; GenieForge maps that into forms and related logic.

​
Where it lives

App Blueprint → Forms. Forms are part of the blueprint. Submissions write into the selected project. Open the form, then use Public intake to publish it to a project. You get a shareable link and QR. Brand defaults to App Settings; override per project under Project Settings → Branding. The form follows the guest’s light or dark color scheme (same as the portal and landings). If your logo is drawn for a light background, ask Building chat to add a logo for dark backgrounds so the header mark stays readable at night. Optional: turn on Built and hosted by GenieForge on that Public intake panel so guests see a small GenieForge line at the bottom of the form. It is off unless you turn it on, then Update & publish (it follows Publish like the other guest chrome). Turn off Show app name in the header when the guest page is already branded (your landing, your domain) and the app name bar would be extra. Turn on Fill the page so the form uses the full intake area instead of sitting in a padded card. Leave Intro title blank to hide that heading; guests will not see a fallback Welcome. After a successful submit, After submit, go to can send guests to another https page (or a path on the same host). Failed submits stay on the form. The thank-you copy still shows if the browser does not follow the link. Turning public intake on or off, and the guest page chrome (title, intro, success copy, path alias, Guest page first, Continue label, header, fill the page, after-submit link, Built and hosted by GenieForge), follow Publish. The share link and QR stay the same until you rotate them. A draft-only enable does not open the guest form until you Publish. Turning intake off in draft does not close existing guest links until you Publish; rotate or delete the link if you need to stop it immediately. When the project has an active Portal or Project landing custom domain (or a public project subdomain), new share links and minted invites use that host instead of the GenieForge site. Portal wins when both exist. Optional Public path alias (for example rsvp) shortens tenant links to /rsvp/…; leave it blank to keep the default GenieForge path. Opening the link starts a short-lived form session (claim, then fill and submit once). Optional Guest page first on Public intake opens the project site (or a thinner guest page) before the form. Guests continue when they are ready; browsing that page does not start the form session yet. The same landing can list published posts. Publish again after you pick a guest page: until then the share link keeps opening the form directly. Leave Guest page first blank for today’s form-first share link. Guests who go back, or who bookmark the form after it opens, may see Form has expired. They should open the original link or scan the QR again. If that same person later registers or accepts an invite, Usage can connect this visit to their signed-in activity. HIPAA-enabled apps do not offer public intake. If App Settings → Appearance → Languages has more than one language, the same public form can show labels in each language. You do not publish a second form. See Languages. Build can create personalized intake links for a guest (for example a wedding RSVP invite). Each link is a short opaque invite URL; guest copy and field prefills stay with that invite, not stuffed into a long address. Personalized links expire after 30 days unless Building chat sets a shorter or longer time (up to one year). Put guest-facing names in the form intro or success copy with placeholders such as {{guest_name}}. Internal record ids stay off the form. Links can also prefill form fields (including a fixed guest list in a repeater) so guests see their names as labels and only fill answers. You can cap how many times an invite can be submitted successfully, and choose what happens when someone reopens it afterward: thank-you copy, an already-submitted message without showing previous answers, or a simple unavailable state. Reopening a used invite never shows or edits prior answers from the public link alone. If a household setting or guest list changes after you already sent the invite, ask Building chat to refresh that existing personalized link. The public address stays the same.

​
How to verify

  1. Open App Blueprint → Forms and walk the fields (required, formats, conditionals).
  2. Submit once as the intended role with Preview as. If a dropdown has a label per language, open the list and confirm the choices are readable.
  3. Confirm the row or result in the project, and any notification or automation in Executions.
  4. For public intake: open the published link in a private window, submit once, and confirm the project received it.

​
Limits and notes

  • Multi-step forms return to the first question when someone taps Next or Back. You do not need a setting for this.
  • Field types such as email, phone, URL, date, datetime, and UUID are checked for format before submit. When a form submits straight to a tool, GenieForge can infer required flags and formats from that tool’s parameters.
  • When someone submits a chat form that writes through a tool, the assistant keeps going afterward so it can finish anything still in progress (for example adding a dentist, then booking the appointment). Forms on pages and public intake links still save and stop.
  • Markdown fields are a write-and-preview editor for long text that guests will read as an article (for example a journal body). The stored value is still plain text. Preview matches how the public site renders markdown.
  • Display fields show a label and value without an editable textbox (useful for names on a personalized invite). Repeaters can hide Add/Remove so the guest list length stays fixed. A repeating group can also sit inside another repeating group (for example a list of exercises, each with its own list of metrics). Radio choices in each repeating row stay independent. A group or section wraps related fields in a labeled card or heading without changing the submitted answers. Use that when a plus-one, emergency contact, or extra traveler should appear inside the same person row only after a yes/no question. Hidden groups skip those extra required fields.
  • Signature fields store a drawing like an image upload. File and image uploads are not available on public intake links; signatures on public intake are supported.
  • Captcha is an optional form setting. When it is on, people complete a challenge before submit (portal, chat, and public intake). Captcha cannot be turned on for HIPAA-enabled apps. If a form has captcha on and the app is HIPAA-enabled, the form will not open.
  • Public intake is not available on HIPAA-enabled apps. The form must submit through a dedicated action that owns safe ingestion (not a direct create into a table). Dropdowns that load from tables, and background jobs, are not supported on public intake.
  • Full-app public share links are not currently offered. For guest data collection, use public intake (or the portal / Preview for signed-in people).
  • For signed-in first login, waiver, or onboarding forms, use Required steps instead of a public intake link.
  • Export/import restores public intake presentation and re-publishes on the new Default project with a fresh link and QR (old links are not copied).