The booking widget is the form your website visitors fill out to book with your practice. You design it once in the screen designer, connect what happens after a submission through a workflow, and paste one line of code onto your site. This guide covers the designer itself: how the canvas is laid out, what each part does, and how publishing works so your changes actually reach visitors.
The screen designer has three areas. The canvas in the middle shows the form as a visitor will see it. The left rail holds the blocks you can drag onto the canvas, grouped by what they do. The right rail configures whichever block you have selected, split into a Basic tab for content and behavior and a Style tab for how it looks.
Along the top are the controls that manage the whole screen: the Issues pill that flags anything blocking publish, the Theme dialog for site-wide colors and fonts, and Preview and Publish. A booking form is built from one or more pages, so a visitor can move through steps rather than facing one long form.
Blocks are the pieces a visitor interacts with: text inputs, dropdowns, buttons, headings, and layout pieces that group them. You add a block by dragging it from the left rail onto the canvas, and you reorder blocks by dragging them within a page.
Each block has its own fields in the right rail. A text input has a label and a placeholder and whether it is required. A dropdown has its list of options. A button has its text and, on a multi-page form, which page it advances to. Selecting a block shows exactly what you can change about it, so you rarely need to guess.
The Style tab on each block controls that one block's appearance: spacing, alignment, widths, and colors. The Theme dialog controls the whole form at once: your brand colors, fonts, and the overall look, so every block inherits a consistent style instead of being set one at a time.
Preview opens the form exactly as a visitor will experience it, including moving between pages and filling in fields. Use it before every publish. What looks right in the editor can behave differently when it is interactive, and Preview is where you catch that.
Your work stays in a draft until you publish. Publishing is what copies the current design to the live version that visitors see, so nothing you do in the designer reaches your website until you click Publish.
The Issues pill tells you whether you are ready. It flags problems that would break the form for a visitor, and it blocks publishing until they are resolved. A common one is a form that has no way to submit, so make sure a submit button exists on the last page before you expect Publish to succeed.
The designer decides what a visitor sees and fills out. What happens after they submit, the confirmation emails, the follow-ups, where their browser goes next, is described separately in the booking workflow. The two work together: the form collects the information, and the workflow acts on it.
The Email step does one of two jobs, and you pick which at the top of the step: Send, which is what a new step starts on, or Read. Send writes an email from one of your connected inboxes, and can either send it or save it as a draft for you to review. Read looks through a connected inbox for the emails you describe, such as "referral emails from Alma that arrived this week", and passes what it finds to the steps that follow, so a later step can decide what to do, write a reply, or update a record. You pick the emails by who they are from and who they were sent to, each in its own box. Both boxes are optional, an entry can be a single address or a whole company such as alma.com, and several entries in one box mean any of them, so two senders finds mail from either. Every Read also has a time window: a number of minutes or hours, counted back from the moment the step runs, up to 24 hours and three hours unless you change it. This is what stops a task on a schedule from reading the same emails again on every run, and it is how a task that runs every three hours reads just the last three hours of mail. These boxes are applied exactly as you set them, so the same entries always find the same emails, and the step brings back up to the 25 newest that match. To narrow further, the box called "Look for specific items in the email" takes a description such as an email titled "Welcome to the practice". When you save the task, Luna turns that description into a fixed search and shows it to you under the box, and from then on every run looks for exactly the same thing. A description that depends on understanding the email, such as its tone, cannot become a search, so the step tells you and Luna reads the emails on each run to check instead. Reading never marks an email as read or changes anything in your inbox, attachments are listed by name only, and finding nothing counts as a result, so a decision step can take a different path when there is nothing new.
When it sends, an email step can write to one person or to many. The To field decides: list several addresses, or describe the recipients in words, such as "every client from the previous step who has an email", and the step works out who that is from what the earlier steps found. For many people, write the subject and message once; placeholders such as $first_name are filled in for each person. The step sends or saves drafts exactly as a single email would, one message per person, a few at a time so your inbox is never flooded, and tells you how many went out and who was skipped.
Below the message there is an Additional information box for standing guidance that shapes how every email from this step is written: the tone, who the reader is, what to always mention, what never to say. It takes formatting and links, so you can paste a booking link, a fees page or a map link there and keep it readable. The guidance itself is never copied into an email, but a link, address, phone number, name or price you give there is used exactly as written whenever the email calls for it.
Tasks that start from an email or run on a schedule also have a Schedule for later step. The task waits there, and every step after it runs a number of days later, between 1 and 30, counted from the moment the step runs. Nothing is lost during the wait: the later steps see everything the earlier steps found, including the emails they read, so a follow-up written three days later can still name the people and details from day one. Use it to check back on something, for example read the new match emails, wait three days, then draft a follow-up to each client. While a task is waiting its run shows as paused, with the date it will carry on. The Today section of your dashboard notes how many tasks are scheduled for later, and opening it shows the Upcoming tab of Task runs, where each waiting task is listed with its date, soonest first. If you do not want to wait, press Start now on a task there: its remaining steps run right away and it will not run again on the scheduled date. If the follow-up is no longer needed, press Cancel run instead: the remaining steps never run, and what the task already did stays as it is. Neither can be undone, and once a task has started its remaining steps it can no longer be cancelled. In an organization, only admins can start a task early or cancel it. Retrying a run does not make it wait a second time. This step is not available inside a subtask or in the booking workflow.
If your practice has connected a Google account under Tools, the workflow also offers a Google Sheets step and a Google Docs step. Each one takes a single instruction in your own words and works out the rest. The Sheets step is pinned to one spreadsheet and tab, and can read rows, add rows, or update a cell on a row that is already there. The Docs step works in one document you pick, or creates a new document on every run, and can read it, add paragraphs at the end or under a heading you name, or fill in placeholders such as {{client_name}} in a template. Whatever a step reads is passed to the steps after it, so a decision or an email can act on what the sheet or the document says. Neither step deletes anything, and every change it makes is listed on the integration's page. The Docs step appears only once the connected Google account has allowed access to Google Docs, which an admin does with one more sign-in from the Google Docs page under Tools.
If your practice has connected Stripe under Tools, the workflow also offers a Stripe step. You tell it in your own words what to look up, such as the client's last payments or whether they have an unpaid invoice, and it reads your Stripe account and passes the answer to the next step, so a decision or an email can act on it. The Stripe step only looks: it cannot charge a card, refund, or change anything in Stripe.
Once your form is published and your workflow is set, embed the widget on your site with the snippet from the widgets area and send a real test booking through. Watching one submission flow from your website through to the workflow is the fastest way to confirm everything is wired correctly.