Some sign-ups do not need screening at all. An open house, a fundraiser, a park cleanup, a one-off community event. You want people to turn up, you are happy with anyone who does, and making them apply, wait for approval, then come back and reserve a spot is three steps more than the job needs.
Vome can collapse the whole thing into one form and one link. The form asks your questions and carries a live shift calendar, so somebody arrives, answers, picks the shift they want, submits, and is confirmed. This article is for administrators building that kind of sign-up, and for administrators who want the same shape with a checkpoint or two added back in.

One form doing two jobs.
A normal form collects answers. A form carrying a Shift calendar section also displays the live shifts from the opportunities you point it at, and lets the person reserve one as part of the same submission. They arrive, answer, book, and they are done, in a single sitting on a single page.
The part that makes this possible is worth stating plainly. Everywhere else in Vome, people see shifts only inside opportunities they are already approved for. On a form, access comes from the form itself, so the calendar works whatever the person's approval status is, including for somebody who has never heard of you until today.
Opportunities and shifts first. The form last.
The calendar on the form does not create anything. It displays what already exists, so until the schedule is built there is nothing for it to show and nothing for you to select. Build in this order:
Build the form first and you will reach the calendar step with an empty list and nothing to choose from, and you will have to come back to it anyway.
It is a field you switch on, then populate.
One thing to know about which shifts appear. Every upcoming shift in a selected opportunity is shown, with one exception: a shift carrying an advanced reservation restriction stays visible only to the people who are eligible for it. That is deliberate, and it is how a restricted job stays restricted even on a public form.
In that same popup, on each opportunity you selected.
Once an opportunity is in the selected list, it carries two switches:
There is also a Master Switch Control at the top of the selected list, which sets either switch across every opportunity you have added at once. Use it when you are building a straightforward event sign-up and want the same behaviour everywhere, and set them per opportunity when they should differ.
You can also reach the same auto-approve setting from the opportunity itself. On an opportunity that has a recruitment workflow it is labelled Auto-approve via linked form, and on one without a workflow it is labelled Auto-approve opportunity. It is the same setting under both labels.
They are two checkpoints in a row, and they gate different things.
Auto-approve is the opportunity-level checkpoint. Approval for an opportunity is what makes a booking mean anything. Without auto-approve, submitting the form leaves the person waiting on you before their chosen shift counts for anything.
Instant Book is the shift-level checkpoint. With it on, the reservation is confirmed the moment it is made and the shift's remaining count drops straight away. With it off, reserving sends a request to the shift's coordinator, and the spot is held as pending in the meantime so it cannot be taken from under them.
With both on, somebody goes from stranger to confirmed on a shift without an administrator touching anything. That is the all-in-one sign-up, and for an open event it is usually exactly right.
Turn one or both of them off. That is what they are for, and the two switches give you four honest positions.
The one thing not to do is leave both off out of general caution. Every reservation then becomes a task on somebody's desk, and for an event with two hundred sign-ups that is a job you have given yourself for no benefit.
A form with a calendar on it.
They reach the form either from your organization page or from a direct link you share. They answer your questions, and in the shift section they see the available shifts with their dates, times and remaining spots, and pick the ones they want. Submitting the form submits their answers and their shift choices together.
What happens next depends on the two switches. With both on they are confirmed immediately and the shift appears on their own schedule. With either one off, they are told their request has been received, and they are notified when you approve or decline it.
The submission, with the booking attached to it.
Submissions land in the form's submission list like any other. A submission made through the calendar carries two extra pieces of information, Requested opportunities (Shift calendar) and Requested shifts (Shift calendar), so you can see what somebody asked for without leaving the submission.
Where a checkpoint is still in play, that is where you clear it. Anything already confirmed simply shows up on your schedule alongside every other reservation, with attendance tracked the same way.
One setting: auto-add to the database.
By default, an administrator decides whether somebody who submits a form joins your database. With no screening in the way, everyone who signs up belongs on your list, so turning on Auto-add to database in the form's settings saves you clearing a queue that was never really a decision. If you do have a screening process or an onboarding sequence, leave it off, because that queue is the screening.
One link.
The form link is the whole of your public presence for this event. Put it on your website, in an email, on a poster behind a QR code. There is no landing page to maintain, no marketplace to curate and no approval queue to watch, because the settings above took you out of the loop on purpose.
None of this locks you in. Add a screening question later, turn auto-approve off for one opportunity, or build a full recruitment workflow when you outgrow the single form. The structure underneath is the same one every larger setup uses.