Forms - Myra Docs

Myra Forms are powerful data-collection engines designed to convert anonymous website visitors into qualified leads. By combining a drag-and-drop builder with sophisticated logic and deep CRM integration, you can build everything from a simple "Contact Us" box to a 50-field "Project Scoping Questionnaire."

The Form Builder Interface

The builder is organized into four distinct workflows to help you move from concept to publication.

1. Build: Adding Your Fields

Drag fields from the sidebar onto the canvas. Every field you add should serve a purpose.

Standard Fields: Name, Email, Phone, and Address. These are automatically mapped to the core Myra contact record.
Custom Fields: Select any custom field you've created in your settings. For example, if you have a custom field for "Favorite Color," you can add a dropdown to your form that updates that specific field in the CRM.
Question Preview: Open a single question preview directly from the builder without stepping through the full form.
Specialty Fields:
- File Upload: Allow leads to upload PDFs, images, or documents (up to 50MB).
- Signature: Collect a quick digital signature directly on the form.
- Hidden Fields: Pass data from your URL (like utm_source or referral_id) into the CRM without the user seeing the field.
- Consent / Privacy policy (optional): A single tick-box question such as "I accept the Privacy Policy". You choose the checkbox wording, which words become a link (e.g. "Privacy Policy") and the URL they open in a new tab. Turn on Required if the form shouldn't be submittable without it.

2. Design: Making it Your Own

A form that looks like your brand converts better.

Layouts: Choose between a single-column list or a more compact two-column grid.
Styling: Control every pixel-from the "Border Radius" of your buttons to the "Font Weight" of your labels.
Brand Kits: If you've already defined your brand colors, you can apply them to your form with one click.
CSS Overrides: For developers, you can inject custom CSS to achieve highly specific designs that match your website perfectly.

3. Logic: Conditional Branching

Logic allows you to create "Smart Forms" that adapt to the user's input.

Show/Hide Rules: "If 'Are you a current customer?' is checked, show the 'Account Number' field."
Branching: "If industry is 'Healthcare,' skip to Page 4 (HIPAA compliance); otherwise, go to Page 2."
Success Logic: Choose what happens after submission. You can show a custom "Thank You" message, redirect to a specific URL, or open your Booking Page to secure a meeting immediately.
Pipeline Routing: Choose the pipeline and starting stage for new leads, with clear labels shown in the builder and form settings.
Rule checks: The builder only offers operators that a field type can actually answer - a Calendar / Booking question, for example, offers just "is filled" / "is empty", and those two never ask for a value. Changing the question in a condition keeps your operator (or swaps it for a valid one) instead of clearing it. A rule that could never match - no question, no operator, or a blank required value - is flagged in red and can't be saved, and any older rule already in that state is highlighted for you to fix rather than changed automatically.
Complete-path checks: Before publishing, Myra checks Version A and Version B separately to make sure every page can reach a real ending. Self-links, closed loops, and genuine dead ends are blocked with the affected page and version named. If no branch matches, the form follows its normal next-page route (or the first ending after the final page), so an omitted All other cases go to rule is not treated as an error when that normal route still completes. The Logic tab shows which endings each page can reach. Unused endings and deleted conditional destinations are warnings only and do not prevent publishing. Existing live path issues remain warnings until that route is changed; newly introduced issues block publishing.

4. Analytics: Performance Tracking

Don't just guess which forms are working.

Conversion Rate: See exactly what percentage of people who viewed the form actually submitted it.
Field Drop-off: Identify "friction points." If 80% of users stop at the "Phone Number" field, you might want to make it optional or remove it.
Submission Trends: Track how your lead volume changes over days, weeks, or months.

Multi-Step "Quiz" Style Forms

Long forms can be intimidating. Myra allows you to split your form into multiple steps.

Progress Bars: Show users how far they are (e.g., "Step 2 of 5").
Step Gates: Prevent a user from moving to the next page until all required fields are filled correctly.
Qualification: Use logic to "disqualify" leads mid-form. If a lead answers that their budget is too low, you can show them a polite "Not a fit" message instead of letting them finish the form.

Publishing and Embedding

Once your form is ready, you have three ways to get it live:

Hosted Link: Every form gets a beautiful, standalone page (e.g., forms.myra-app.ai/your-brand/quote). Perfect for sharing in social media bios or email signatures.
Inline Embed: Paste a single line of code into your website (WordPress, Webflow, Shopify, etc.) to make the form look like a native part of your page.
Popup/Overlay: Trigger the form to appear when a user clicks a specific button or when they are about to leave your site (Exit Intent).

The editor toolbar keeps save, preview, share, publish, and accessibility actions visible as your screen size changes.

When someone books through a built-in calendar question, the appointment and completed form are joined to one contact. The contact keeps its booked stage and appointment while the form answers and response record are added before any post-booking redirect runs. Direct booking links and forms without a booking continue to create contacts normally.

Security & Spam Protection

We protect your database from junk submissions.

Invisible reCAPTCHA: We use Google's latest invisible protection to stop bots without bothering your real users.
Honeypot Fields: Secret fields that only bots can see. If they are filled, the submission is silently discarded.
Rate Limiting: Prevents "Brute Force" submissions from a single IP address.

FAQs

Can I send the form data to my email? Yes. In the "Settings" tab, you can add multiple email addresses to receive a full copy of every submission instantly.

What happens if someone submits the same email twice? Myra will automatically identify them as an existing contact and update their record with the new information, rather than creating a duplicate.

Template conditional logic

Templates in the library ship with their branching already wired, so irrelevant questions are skipped automatically - for example a Solar Panel Quote finishes early for non-homeowners, a Dental Appointment Request skips slot preference for emergencies, and an Event RSVP skips guest count for declines. You can edit or remove any of these rules in the Logic tab after creating the form.

Time-of-day availability (question scheduling)

Any question page can be set to only appear inside a time window — for example an "Can we call you right now?" question that only shows during opening hours.

Open the question in the builder and turn on Only show at certain times.
Pick a From and Until time, and optionally which days of the week.
A window can cross midnight (e.g. 17:00 → 09:00). The days you pick are the days the window starts, so a Friday 17:00–09:00 window stays open into Saturday morning.
Set the Form timezone in Settings. Times are always checked in that timezone on our servers, never on the visitor's device, so nobody can skip or unlock a question by changing their phone's clock.
Outside the window the question is skipped entirely — the visitor never sees it, and any branching that pointed at it falls through to the next question.
The availability is decided once when someone starts the form and stays fixed for their whole session, so the form never changes shape mid-way through.
If every question is outside its window, the visitor sees a short "not available right now" message with the next opening time.

When two versions are switched on, the question editor stacks Version A above Version B, each fully editable with every normal question option. Turning versions off keeps version A exactly as it is and saves version B and any timing you set — nothing is deleted. The collapsed row tells you the work is still there, and switching back on restores it exactly. While it is off, respondents simply see version A, as if nothing were configured. Switching between modes is also non-destructive. Use Delete version B if you deliberately want it gone.

Branching per version

When a question has two versions, each branching rule has an Applies to setting: Both versions (the default), Version A only, or Version B only. A rule scoped to one version only fires for people who actually saw that version, and it lets you branch on that version's own fields — handy when version B asks something completely different. Rules left on "Both versions" keep working exactly as before, and each version can have its own "all other cases go to" destination.

You can edit this straight from the question: when versions are on, each version's editor has its own Branching button, showing how many rules apply to it. Inside, you only edit that version's rules, and any rule shared with both versions is listed underneath as "Also applies to this version" with a "Make version-specific" action to give that version its own copy. Version-specific rules are checked before rules that apply to both. A question with no versions keeps the single Branching button exactly as before.

A/B variants on a question

Any question can carry a second version (arm B) without becoming a second question. Turn on A/B variants on the question in the builder.

Arm A is the question as you already wrote it. Arm B starts as an exact copy and is a fully editable question: field type, labels, choices, calendar settings — everything the normal editor offers.
If you only change wording, both arms still collect the same answer, so responses, exports, reporting and branching rules see exactly one question. The builder confirms this with "Both versions collect the same answer — results can be compared."
If you change the field type or the fields themselves, the arms collect different answers. The builder says so, and results are reported per version instead of as a test. Any logic rule that references a field which exists in only one version is flagged as applying to that version only.
Split test (randomised) shows B to a percentage of visitors you choose. The choice is made once per visitor and applies to the whole form, so nobody ever sees a mix of arms.
Time-based (personalisation) shows arm A inside a time window and arm B outside it, in the form's timezone. This is not a controlled experiment — people filling a form at 9pm are a different group from people filling it at 2pm, so a difference between arms cannot be put down to the wording alone.
Preview as B in the builder lets you see arm B without waiting for the clock.

Reading A/B results

The Analytics tab gains a Variants panel as soon as a question has a second version.

Each arm is scored on its own audience: that arm's completions divided by the sessions that arm was actually shown. One arm's results are never divided by everyone.
Anyone who never saw a question because of its availability window is left out of that question's numbers. It is not a drop-off if the question was never asked.
Split test (randomised) shows a lead once both arms have at least 100 completions, always alongside the sample sizes. Below that it says "not enough data yet" rather than crowning a winner on a handful of responses.
Versions that collect different answers are also shown side by side with no winner and no lift — there is nothing to compare.
Time-based (personalisation) shows both arms side by side as plain numbers, with no winner and no lift — the arms ran at different times of day, so any difference is as likely to be the audience as the wording.

Individual responses show which version the respondent saw and only list the questions that version actually asked, and the CSV export gains a Variant column when the form has variants.

Booking calendar prefill

Form settings → Booking calendar prefill lets you pick exactly which questions feed the name, email and phone fields on a booking calendar (built-in booking pages, in-form "Schedule a time" questions, and Calendly). Leave any of them on Auto-detect and the form picks the closest matching question from its contact-field mapping, question type, then label.

Incomplete submissions

Most people who start a form never finish it. Form settings → Incomplete submissions decides what happens to their answers:

Don't save — nothing is captured if they don't finish.
Save as a contact, don't contact them (default on new forms) — the contact is created with the name, number and answers so far and tagged Incomplete. No automations, no calls, no texts, no ad conversion events. Manual follow-up only.
Save and treat as a normal lead — the contact behaves exactly like a completed submission, including automations and live transfer.

Start saving once we have: sets how much contact detail is needed before anything is created — phone number (default), email address, or a name plus either. Nothing is saved before that, so people who bounce off the first page never become contacts.

Choosing the capture point per question

Any question in the Build tab has a Save contact at this point option, so you can decide exactly when the contact is created — for example as soon as someone says they own their home, or picks a policy type. Two modes:

Any answer — capture as soon as the question is answered.
Specific answers — capture only for the values you pick.

A contact is useless if you can't reach them, so capture always happens at the marked question or once a phone number or email address exists, whichever comes later. If you place a marker before any phone/email question, the builder warns you and tells you which page saving will actually start on.

With several markers, the first one whose condition is met wins. With no marker at all, the Start saving once we have dropdown above is used, and existing forms behave exactly as they do today. The Pages list shows a Capture badge on the page where saving will happen, and it moves when you reorder pages.

Captured contacts are updated (never duplicated) as more answers arrive. If the respondent later finishes, that same contact is completed: the Incomplete tag is removed and the normal automations run once, at that point.

Incomplete contacts are excluded from conversion rates in Sales Analytics until they complete.

Existing forms are unaffected — they stay on Don't save until you change them.

Height, width and logo (Design tab)

Vertical spacing shrinks or grows the empty space above and below the question, so a form can be made much shorter without changing font sizes.
Content width sets how wide the question column can grow.
Show logo can be turned off to remove the logo (and its placeholder) from the top of the form.

The Design tab preview now fills its frame and scrolls once, instead of being cut off with several scrollbars.

Tags added on submit

Form settings → Routing & tracking → Tags added on submit lets you pick tags (or type new ones) that are applied to the contact as soon as the form is submitted. Because the tags land on the contact, any automation using the "Tag added" trigger fires straight after the submission.

Per-ending tags

Each ending has its own Tags added on this ending picker (next to Pipeline routing, shown when the ending creates a contact). Use it to tag by outcome — for example Qualified on your booking ending and Not a fit on a disqualifying one. Ending tags are applied on top of the form-level tags, with duplicates removed.

Answer format checks

Name, email and phone questions are now checked for a valid format before a visitor can continue. A single character like "x" is rejected with an inline message ("Enter a valid email address"), and Continue stays disabled until the answer looks real. Optional questions left blank are still fine — the check only applies once something is typed. Other question types (short text, long text, etc.) are never format-checked. The same rules are enforced on the public lead API, so a bot posting directly can't skip them.

Routing after an inline booking

If the last question on a page is a booking calendar, you can route people to a specific thank-you screen with a rule like "IF Book a time is filled → Ending · Thank you (Booking)". The "Then go to" list groups pages and endings separately, and every branch must end on a page or a thank-you screen - there is no "submit with no end screen" option any more. If your form has no thank-you screen yet, the builder offers to create one. If no rule matches, the form's first ending is used, so every response is recorded against an ending. Older rules saved before this change are highlighted so you can point them somewhere deliberate; they still work in the meantime.

Operators are corrected automatically

If a branching rule uses a comparison that cannot apply to its question - for example "contains" on a multiple-choice question - the builder switches it to the nearest working equivalent ("is") and shows a short note in the rule. The change only takes effect when you save, so you can review it first. If the saved answer is no longer one of the question's options it is cleared and you are asked to pick one.

Duplicate submissions

If someone submits the same form twice in the same browser session (they hit back, refresh the thank-you page, or press Submit again), we update their existing response and contact instead of creating a second one. You get one contact, one notification and one call attempt, with their latest answers saved. Someone returning later in a new session, or a colleague on the same office network, still comes through as a brand new enquiry.

A/B testing an ending screen

An ending can run two versions, just like a question page. Open the ending in Build, turn on A/B versions, and set up Version B. Version B only stores what you change, so switching the test off leaves Version A exactly as it was.

Each version can have its own heading, message, redirect URL, post-booking redirect and Meta event — useful when the whole point of the test is sending people somewhere different. Both versions are the same ending as far as your branching rules are concerned, so existing rules keep working and the version a respondent saw is recorded on their submission for reporting.

Every form needs an ending

A form can't be published, pushed live or shared until every path lands on a real ending screen. New forms are created with a "Thank you" ending automatically. If an older form is missing one, or a rule points at nothing, the builder shows a warning naming the rule so you can fix it. This guarantees respondents see a thank-you screen and their answers show correctly in Responses.