How a Form Behaves for the Person Filling It In

On This Page

• Quick Reference
• Buttons and Moving Between Pages
• Conditional Pages
• Conditional Components
• Custom Error Rules and the Error Summary
• Field Groups
• Text Blocks and Headings
• Web Components and Hooks
• Tables of Custom Object Rows
• Drafts, Review, and Completion
• Why This Happens: Later Sections Appear Only After an Earlier Answer

Everything someone sees on a web form comes from the form design: pages, buttons, components, and rules. Use this reference to connect what a member saw to the designer setting behind it, or to adjust what they see next time. The same behavior applies in every Console and portal. To change a setting, see Web Forms.

Quick Reference

What the person sees	Why	Setting that produces it
A page they expected is skipped	A conditional Next rule on the previous page sent them somewhere else, or the skipped page is inactive	Transitions › Next › Enable conditional page transition rules; the page's Status:
A question or section is missing	The component's condition has not been met	The component's Conditional Visibility tab
Next is disabled	Something on this page is invalid: a required question is empty, an answer is not valid, a table has too few rows or an open row dialog, or a web component reported a problem	The field's Required:; the table's Minimum # of Rows
Submit (Save Changes) is disabled	At least one answer anywhere in the form is invalid, or a custom error rule is broken	The fields; the Custom Errors tab
A custom error's message never appears	The page does not have an error summary, and only pages with an enabled Submit get one automatically	Add Form Errors to the page
A button they need is missing	That button is not enabled for the page	The page's Transitions tab
Save & Return Later is missing	Drafts are not allowed where the form is used, or that button is not enabled for the page	The hosting application; the Transitions tab
The form ends on a success message	The form moved to a completion page	A page with Step Type: completion
A form change does not seem to have taken effect	Changes save immediately, but a form that is already open in a browser can take a moment to pick up the new configuration	Reload or reopen the form before assuming the change failed

Buttons and Moving Between Pages

• A page shows only the buttons enabled for it: Back, Next, Cancel, Save & Return Later, and Submit, which reads Save Changes unless renamed. If no buttons are enabled for a page, the page shows no buttons.
• Renaming a button changes only its label. If you rename Submit to something like I agree, the form still will not advance by itself; the page needs its Next or Submit transition enabled, and every answer on the page must be valid before the form moves on.
• A one-page form never shows Back or Next. Forms with two or more pages show a step indicator that cannot be clicked, and the indicator is hidden on narrow screens. You cannot configure these step labels to become clickable links to a specific page.
• Back returns the person to the page they actually came from and keeps their answers.
• Pressing Enter in a question does not submit the form or move to another page. Each page change scrolls to the top.
• When the person selects Cancel, they see a confirmation prompt. The message says any drafts will be erased, but an existing draft is kept.
• If the person leaves the page, they do not see a warning, and answers that were not saved as a draft are lost.
• A completion page shows Continue instead of the usual page buttons. That button is part of the completion experience itself, through the Success Message component. It is not managed from the page's Transitions tab or from any completion text you set, and there is no supported way to turn it into a link.
• Enable Submit on the page before a completion page, not on the completion page itself. Submit activates Continue wherever it sits, so if you enable Submit on the completion page and also route there with a Next transition, the person can see the success message before the record is actually saved as submitted.

Conditional Pages

You can attach rules to a page's Next so the person's answers choose the next page, such as sending students to a student page and skipping the employer page. When the person selects Next, the first matching rule wins. If no rule matches, they go to the next active page. A rule whose expression cannot be evaluated does not match.

• If a rule points to a page that was removed or is inactive, the person stays on the page and sees no message.
• Inactive pages after the current page can cause the same symptom. If Next has no rule to route around them, delete the inactive pages or add a conditional rule that sends people to a specific active page instead.
• Answers already entered on a page that a later choice skips are still submitted with the form.
• The dynamic step type does not make a page conditional; it behaves like a fixed page. Pages become conditional only through rules on Next.
• A condition based on the Add-Ons component's form data can fail silently in the browser and keep the person on the page, even after they choose an add-on. If a Next rule built on Add-Ons behaves unpredictably, check the browser's console for an error and consider basing the rule on a different field instead.

Conditional Components

A field group, text block, success or review block, web component, or error summary can show only while a condition based on answers is true. Tables cannot have a condition. To review or change this behavior, open the component's edit dialog and use its Conditional Visibility tab.

• Conditions can check only fields on the record the form collects, listed as Form Data. They cannot check who the person is. Because of this, conditional visibility cannot filter by the person's state or location, their membership type, or a role such as team member or team chair on an accreditation visit, because none of those are fields on the form's own record. There is also no custom expression that adds them. For the same reason, you cannot require portal sign-in for a form while keeping the submission anonymous; the record is always tied to whoever is signed in.

• Conditional visibility works for a whole component, such as a field group, not for one field inside it. You cannot show or hide a single field within a field group based on another field's value. To get that effect, split the questions into separate field groups.

• The form checks the condition again each time an answer changes. If a condition fails to evaluate, the component stays shown.

• While a component is hidden, its questions are switched off. A required hidden question does not hold the page, and an answer given before it was hidden comes back if it shows again. On contact forms, the email address and job title questions stay active even inside a hidden component.

• A condition that checks a dropdown or multi-select field's choices can stop working if you later edit or remove the choices it checks for. Multiple selections do not break the condition by themselves; the condition simply can no longer match a choice that is no longer there. If a component that used to show or hide correctly stops responding, check whether the field's own choices changed after the condition was written.

• If a hidden field group still produces a required-field error, check whether its Conditional Visibility rule matches the value you expect. A rule that checks the wrong condition can leave the group hidden from view but still counted as required. A correctly configured rule lets required fields and conditional visibility coexist without errors.

• A field that looks greyed out rather than missing is usually still controlled by conditional visibility on a related component. Check that component's condition and the current value of the field that drives it.

• Avoid adding the same field to a form more than once. If one instance sits inside a conditionally visible component and another is always visible, the always-visible copy can appear greyed out whenever the other instance's condition is not met.

• When a component's visibility depends on more than one does not contain condition on a multi-select field, grouped with Any are true, it can stay visible after you pick a single disallowed value. It may hide only once every condition is individually satisfied, instead of hiding as soon as any one of them matches. If that happens, simplify to a single condition or test the combination carefully before relying on it.

• Rhythm does not support driving a field group's conditional visibility from that same field group's own multi-select answer. Setting it up that way can clear the multi-select's selected values when the group is edited again, so store the value the condition depends on in a separate field instead.

• A portal condition based on the signed-in contact's role is really checking the form's own Form Data, not the person's existing role on the record. If a field group is meant to show only for an admin, and that same field group is where the person sets their role, the condition can create a circular dependency. The group will not show until the role is already set, and the role cannot be set until the group shows. Base the condition on a different field, set earlier in the form, instead.

• A custom-built component that shows one of two fields based on an earlier answer, such as an hours field that depends on employment type, needs to keep its own required setting in sync with the field currently visible. Unlike a standard field group, it may not automatically switch off a hidden alternate field's requirement. A validator on the hidden field can still block submission unless it is toggled along with the visible field.

• An older form that has accumulated many changes over time can behave inconsistently with conditional visibility, even when the settings look correct. If you cannot find the cause, try recreating the affected part on a new form. The same conditions have been seen to work correctly once rebuilt from scratch.

• You cannot make a follow-up question appear conditionally inside the same field group box as the question that triggers it. When several questions share one field group, a separately conditioned explanation field appears below the whole group rather than directly under its related question. To put an explanation directly under its question, give the question and its explanation their own field group: create one custom field for the question and another for the explanation, then set the explanation field group's Conditional Visibility to show when the question equals Yes. If you need a free-text answer without building a second field group, a Picklist custom field that allows custom values, paired with prompt or help text that explains how to use it, is a workaround for a same-box follow-up. When a conditional field appears only after someone picks Other, give it its own prompt, such as Licensure Jurisdiction (Other), so it reads as the companion field rather than a repeat of the original question.

• When the condition you need is not directly available on the form's record, such as a membership type stored elsewhere, capture it in a custom field on the form and base the condition on that field instead. The same idea, combined with each field group's own allowed values, can stand in for dependent multi-select choices when there is no direct parent-child picklist setup: show a separate field group of child values for each parent choice.

• For a repeating set of sections, such as Guest 1 through Guest 4, add a separate field asking how many guests there are. Then give each guest's field group a condition such as is greater than or equal to its own number, so Guest 2's fields also show when 3 or 4 guests are chosen, and so on.

• The review block still lists a hidden component, with blank values.

Tip

Because the form checks conditions when answers change, a component with a false condition may still show until the person changes an answer for the first time. An untouched question is not the same as one explicitly answered No. When you troubleshoot unexpected visibility, check whether the controlling field was actually set or just left blank. For a yes/no question, write the condition for the answer that should show the component, for example equals Yes, rather than relying on an untouched question to count as No.

Custom Error Rules and the Error Summary

A custom error rule checks one or more answers, such as "graduation year is before birth year." Rules belong to the whole form, and the form checks them shortly after it opens and again after the person pauses typing.

• While any rule is broken, Submit is disabled. Next, Back, Cancel, and Save & Return Later still work, so the person can move on or save a draft. Because of this, a custom error message alone cannot stop someone from advancing past a disallowed answer. If you need to prevent progress, combine the error rule with a conditional Next rule that sends that answer back to the same page, along with a Form Errors component so the person sees why.
• Getting the outcome you expect from a page transition condition can depend on more than the condition itself. In some cases, a transition rule only produced the right result once it was combined with a Form Errors component and an extra business rule, rather than relying on the transition condition alone.
• The rule's message appears as plain text in a bulleted list where the page's Form Errors component sits, and it also appears in the review block.
• Every page with an enabled Submit gets an error summary automatically unless it already has one or has a review block. On any other page, add Form Errors yourself or the message is not shown. On a registration form, for example, you can surface eligibility feedback earlier by placing a Form Errors component directly below the membership selector and writing a custom error rule for the eligibility condition, instead of waiting for the summary at Submit.
• The summary lists each invalid field as You have not entered a valid value for <label>, followed by each broken rule's message. It stays hidden when there are no errors. Without a custom heading, it reads We need you to take care of this before we can continue....
• A validation message can show a field name with an extra trailing "C", for example when a custom field's shortened identifier ends in __c. The field being referenced is still correct; only its display name was not fully cleaned up for that shortened form. Use the surrounding context to confirm which field to fix.
• If a public form occasionally shows an unclear error with no obvious cause, turning on CAPTCHA for that workflow can help distinguish real visitors from automated traffic and tends to reduce these rare failures.

Field Groups

A field group shows fields and custom fields for the record type, in one or two columns, with an optional heading and introduction. Each field gets an input that matches its type. For this form only, you can change a field's prompt, whether it is required, and which of its allowed values are offered. Click the field to open Edit Field, where the Field Display Label/Prompt: you type replaces the field's default label on this form. Use the same dialog to set both Required: and the field's prompt.

• A required custom field set to Make optional in the console is optional when staff fill the form in the Console. That setting affects Console entry only; the same field can still be required when someone fills in the form through the portal.
• A custom field's advanced rules for when it is required do not affect a form; use the form's own Required: setting. There is no separate setting to make a field required only when another field has a certain value. The closest equivalent is to show or hide the whole field group conditionally, since a hidden question is never required.
• Turning on Constrain Acceptable Values for a field that has a default value locks the field to that default, so the person cannot pick another option. Leave it off if you want the default preselected but still changeable.
• When you restrict which of a field's allowed values are offered, prefer that over changing or removing the field's own underlying values, especially if those values might be used later as reference values elsewhere. Restricting what this form offers narrows the options without disturbing the option set itself.
• The review block labels each answer with the custom field's name, not the prompt set on the form. If reviewers or judges need to see the exact question wording rather than the field's name, plan for that separately, such as with a text block that repeats the prompt near the review. The review block itself always shows the field name.
• Because a form's custom label can differ from the field's own name, a relabeled field can be hard to identify later. A contact form, for example, might label Preferred Address Type as something like Address that appears in the search. Check the underlying field, not just the label, when you need to confirm what is actually being edited.
• A field made required elsewhere in your configuration, such as on the record itself, can still block submission even when this form did not intend to require it, and even when the field is not shown on this particular page. If a submission is blocked by a field you did not expect, check whether it is required somewhere other than this form's own Required: setting.
• If a portal-created record is missing a value that the current form marks required, check which version of the form was in use when the record was created. Required settings can change between versions, so an older record may reflect an earlier configuration rather than the one you are looking at now.
• Only the checkbox control itself responds to a click; clicking the blank space beside it does not change the answer.
• A picklist's option list can open in an unexpected place when there is not room to drop down, especially near the bottom of a scrollable page. It may appear at the top of the page instead of next to the field. The choices are still there even though the list looks misplaced.

Some built-in components bundle several fields together and behave a little differently from a plain field group:

• The Social Lookup component's cell phone field cannot currently be set as required.
• Its Name field can be required only as a whole. You cannot require the individual parts, since Rhythm parses what the person types into prefix, first, middle, last, and related subfields after entry. Example text shown in individual name fields, such as common prefixes, is illustrative only, not a controlled list. People can enter something else, and you currently cannot clear, remove, or customize that example text.
• Its built-in prompt text for the contact role field, such as the multi-select helper text, is fixed and cannot be edited.
• When social contact fields group a photo, email address, name, and mobile phone into one component, you cannot add separate help text under an individual part such as mobile phone.
• The Organization Social Lookup component has a Disable Social Lookup option, under Organizational Social Lookup Options in its editor, that turns off lookup-driven updates to the organization record.
• Organization matching and organization auto-creation are also set per component, on the Contact Social Lookup component. If one form behaves differently from another that uses the same kind of lookup, check that specific form's component settings rather than assuming they match.
• An older instance of a component can lack a newer setting that a freshly added instance of the same component has. If a setting you expect is not there, try adding a new instance of the component, moving over what you need, and replacing the old one.

Address fields use Google Maps to validate and help complete what the person types. Keep these behaviors in mind:

• Address validation for a partial address behaves the same way in Console and portal, since both use the same underlying address handling.
• Selecting a suggested address from the autocomplete list can sometimes leave a part such as state or country blank, which then makes the address invalid. This has been seen in both Console and portal entry. If an address is rejected right after autocomplete fills it in, check that every part came through, and re-enter anything missing.
• An address inside a field-group component has, in some cases, been saved without an error even though it was incomplete or invalid. Do not assume every address already on a record was fully validated when it was entered.
• State and province dropdowns driven by address lookups show the District of Columbia as Washington, DC.
• Collecting only a country, without a full street address, is sometimes intentional, such as for privacy or sanctions-screening purposes. A partial address is not always incomplete data entry.
• There is no direct setting to turn off address changes in the portal. To prevent portal users from updating an address there, use or edit the form used in the portal so it does not include the address field or component.
• A bundled work-information component's overall required setting may not enforce entry of an organization's work address during organization creation. Replace that section with a Field Group, use a two-column layout, and mark the individual address fields required instead.

Text Blocks and Headings

A text block shows a heading and formatted text, such as instructions or terms, without asking questions. Field groups, tables, and error summaries show their own Header & Text heading and text above them. Web components do not show it.

• On a portal organization or contact form, the page header uses the text you enter in its header field once you set one. Leave that field blank and the default heading text shows instead.
• Some components already have their own Instructions block for this kind of contextual help. Check there before adding a separate text block for the same guidance.
• If you want people to enter a logo by URL rather than uploading a file directly, add instructional text to the organization form telling them to paste an image URL. There is no separate setting for this, so the instruction itself is the workaround.

Web Components and Hooks

A web component is a custom element your organization supplies, such as a calculator or vendor widget, placed by its tag name. If the tag is wrong or its script is not registered, nothing appears and no warning is shown. A web component can report itself invalid, which holds Next or Submit. Changing a field's validation alone does not always make a required-field indicator, such as a red asterisk, appear on a custom element. Some custom elements need their own required parameter set explicitly, and others may need a required styling class added before the indicator shows.

Visual styling and branding can look different between Rhythm accounts, or between a form and something you have seen elsewhere. That comes from your account's own form CSS, headings, and any custom components you have added, not from a shared template. Do not assume a look you saw somewhere else is available on your form without configuring it yourself.

Hooks run in the person's browser when a page opens or before a button action happens. They can fill in answers or choose the next page. If a web call fails, the form ignores it, continues without the result, and no one is notified. See Form Hooks and Expressions.

Tables of Custom Object Rows

A table lets the person add several rows of a custom object, such as each degree with its school and year. The person enters each row in a dialog.

• Below the minimum, the person sees One entry is required before you may continue. or <n> entries are required before you may continue., and Next and Submit are held.
• At the maximum, the add button is disabled.
• Closing a row dialog with × or Escape holds the page until the person opens a row again and saves or cancels it.
• Rows are saved with the record when the form is submitted, not on their own. Leaving the form loses them.
• Table cells show nothing for a value of 0 or false.
• A section built from a table tied to a custom object is not configured the same way as a field group. Required-field behavior for the fields inside those rows may not be something you control from the form editor itself. Check the custom object's page layout instead.
• There is no built-in setting to disable or hide a table's edit and delete actions, whether generally or by row type.
• The add/edit dialog for a row can include HTML instructions to guide whoever is entering that row's information.

Drafts, Review, and Completion

• Save & Return Later saves a draft even when answers are invalid. When the person reopens the form, they see A Draft of this Form Has Been Found; a resumed draft starts on the first page.
• The review block shows read-only cards of earlier answers. To change an answer, the person uses Back.
• After a successful submit, the form shows its completion page if it has one; otherwise the application decides what comes next.
• Rhythm does not send an automatic internal notification when a member takes a self-service action in the portal, such as updating profile or membership details, adding a representative, making a payment, or choosing Unsubscribe from all. If your team needs to know about those actions, plan another way to monitor them.

Why This Happens: Later Sections Appear Only After an Earlier Answer

When later questions or pages appear only after an earlier field is filled, one of three settings usually explains it: a condition on the later component, a conditional rule on Next, or a required question that keeps Next disabled until it is answered. Check those settings in that order in the designer.

A change you make to a form's design normally takes effect immediately, with no separate publish step. If a change does not seem to be working right after you save it, reload or reopen the form before assuming it failed. A session that was already open in someone's browser can occasionally take a short time to pick up the new configuration.