A form is how information gets into Vome. Someone fills one in, and what they answered can update their profile, enrol them in a sequence, approve them for an opportunity, tag them, notify the right person, and set the status your team will work the submission from.
That is the thing worth understanding early. A form is not only a questionnaire. It is the front door to your process, and most of what happens after someone applies is decided by how you set the form up.
Three routes:
Four kinds of content:
Core profile fields. First and last name are always collected, whether or not you display them. Email and phone number can be shown or hidden, and are collected either way. All of them map to the database automatically.
Optional profile fields. Date of birth, age, gender, address, occupation (with school or company), skills, languages and bio. These also map to the database automatically.
Your own fields. Questions in a range of answer types, attachment fields, and general information blocks for sharing text, documents, images or video mid-form. Question and attachment fields can be mapped to a database field, which is what turns an answer into profile data rather than something you read once and retype.
Structured sections. Medical information, emergency contact, general availability (days of the week and times of day), and digital consent, where the person ticks an acknowledgement and draws a signature on the form, with an optional document attached for them to read.
On top of that you can add section headers, drag fields into any order, and use conditional logic so a field only appears based on the answer to an earlier one.
This is the part most people underuse. Any single-select, multi-select or powered-select question can carry its own automations, opened from the Automations pill on that question in the builder.
Each rule is a condition on the answer plus one or more actions. The condition can be:
And the actions it can run:
One rule can hold several actions, and one action can be tied to several answer options at once. So "Which programme are you interested in?" can put each answer into a different sequence, tag the profile, and tell a different coordinator, all from one question.
Turnkey automations. When a question's choices are drawn from your own sites or opportunities, you also get toggles instead of rules, because the answer already names the target:
One toggle, and "Which location works for you?" assigns the person to the site they picked and tells that site's administrators about it.
Question automations depend on what someone answered. The form's own settings apply to everyone who submits it. Under Settings and automations you will find:
One recommendation on Auto-add to database. If you run an onboarding sequence, leave this off on the form and turn it on at the end of the sequence instead. Adding people here means everyone who ever filled the form in is in your database, screened or not. Adding them at the end of the sequence means your database is the list of people who actually completed your process. See How do Sequences work on Vome?
The Automations summary in the form's settings lists the form-level settings and every question-level rule together, and clicking one takes you to the question it belongs to. Check it before you publish a form.
Every submission carries a status, and it exists for your team, not for the person who submitted. Users never see a submission status, whichever one you set, so you can name and use them however suits your process without worrying about how they read.
Six statuses are built in: New, In Review, Reviewed, On Hold, Accepted and Rejected. Everything arrives as New.
From Manage submission statuses, reachable from the form's settings, the Forms module sidebar and a form's submissions view, you can go further:
What is global and what is per form. The order of the statuses and the built-ins you have hidden are organization-wide, so changing either changes every form. A custom status is the one thing you can scope: when you create it, choose whether it is available on all forms or only on the specific forms you pick. That is how a status that only makes sense on your coach application stays off your event sign-up form.
Statuses do not have to be set by hand. Use the Set submission status action on a question automation and your queue sorts itself as submissions arrive. For more on working the queue, read How do Form statuses work?
A success screen, and it is built to move them onward rather than leave them at a dead end. Where it sends them depends on what the form just did.
If the form enrolled them in a sequence, the leading action is Go to sequence and it takes them straight into it. This is worth setting up deliberately: they land in their onboarding at the moment they are most engaged, instead of waiting to notice an email.
If they reserved shifts on the form, they are offered their schedule. Otherwise they are offered their homepage.
Closing the screen with the X, with Escape, or by clicking outside it does the same thing as the leading action, so no one gets dropped back onto the form they just submitted.
The custom follow-up message. Turning on Add a custom notification message in the form's settings lets you write your own subject and body, which is sent to the person as their confirmation email right after they submit. Use it to say what actually happens next and by when. "Thanks for applying, our coordinator will call you within three business days" is the message most applicants never get, and it is the difference between someone waiting patiently and someone assuming they were ignored.
Yes. Every form has an assigned coordinator who gets an email and an in-app notification for each new submission, and form watchers get the same. Turn on Include the submission in admin emails if you want the answers in the email rather than a link to go and read them. Question automations can notify other people on top of that, including a specific site's administrators or an opportunity's coordinators.