A web form is a design you create once for one kind of record. Rhythm shows that design to the person completing the record, whether they are a portal member or a staff member in the Console.
Why Forms Exist
Every association collects different information for different processes. Membership applications, event registrations, abstract submissions, and sponsorship applications each need their own questions, order, and instructions. Web forms let you choose those questions and arrange them without asking Rhythm to change the product. You use the same design tools for every application that collects information through forms.
A Form Belongs to One Record Type
Every form is created for one record type, such as membership applications or sponsorship applications. You choose the record type when you create the form, and you cannot change it later. If you need a form for another record type, create a new form.
Rhythm does not have one general forms menu. Each application that uses forms keeps its own list in its setup area, and that list shows only forms for that application's record type:
| Application | Where the forms list is |
|---|---|
| Sponsorship | Go to Setup › Applications › Forms. The setup overview also includes the Configure application forms link. |
| Membership | In the Membership & Committees Setup menu, go to Applications › Forms, Membership › Page Layouts, or Chapters › Page Layouts. |
| Submissions | In the Setup menu, go to Submissions › Forms or Submissions › Page Layouts. |
You need permission to manage forms for that application before you can open its forms list. The forms list is available only in the Console, so portal members cannot open it.
You cannot copy or move a form from one application to another. A form stays with the application and record type you created it for.
Built-In Forms and Forms You Design
When you select Create <object name> (for example, Create Application Form), Rhythm asks what to use as the starting point. You can choose:
Start from an empty form: a blank form with one page,Page1, and the Next and Cancel buttons already switched on.- A form under
Built-in Forms: a starting design supplied by the application. This group appears only when the application supplies one; Sponsorship and Submissions do not. - A form under
Custom Forms: any active or inactive form your Rhythm account already has for this record type. Rhythm names the copyCopy of <source name>.
Some applications also add default forms to your Rhythm account when they are switched on. Those defaults are ordinary forms: they appear in the forms list and under Custom Forms, and you can open, edit, copy, or delete them like any form you built. The form itself does not show which application supplied it. If a form is locked, the list hides its edit and delete icons and shows This record is locked and cannot be edited or deleted.
Forms also show a status indicator, but it does not work like the active or inactive controls elsewhere in the Console. Do not use it to take a form out of service; use the application's own process configuration instead.
Pages, Components, and Transitions
A form is made of pages. Each page contains components, such as field groups of questions, text blocks, row tables, error summaries, answer reviews, or a success message. Each page also sets its transitions, which are the buttons that move the person through the form: Back, Next, Cancel, Save & Return Later, and Submit. The Submit button label is Save Changes unless you rename it. Save & Return Later appears only when you have added that transition to the page, so if a form seems to have no way to save a draft, check whether that transition is switched on before assuming drafts are not supported for that record type.
Warning
A text block can hold HTML, but <iframe> elements are not supported there. If you paste an iframe into an HTML display area, it will not render for the person filling in the form. This security limit helps avoid exposing portal users to content from another site.
Each page also has a step type: Fixed, Dynamic, or Completion. Most pages should stay Fixed because a fixed page appears for everyone, and its components can still use conditional visibility. You rarely need Dynamic just to hide or show something. A Dynamic page decides whether the whole page applies, based on criteria you set as an expression in the form's properties. A Completion page is meant for the last step, where you tell the person they finished successfully.
Rhythm shows a one-page form as a single page. When a form has two or more pages, Rhythm shows it as a step-by-step wizard with a step indicator. You can show components only when answers meet a condition, and Next can jump to another page based on the answers. If you need to make a field required only when another field has a particular value, you can put the dependent fields in their own field group and build two versions of that group: one with those fields required and one without. Then show the version the condition calls for. Conditional visibility is not the right answer for every situation; where it does not fit what you are trying to ask, use registration questions instead. To offer a fixed set of amounts when a free-entry amount is not appropriate, such as for a sponsorship application, use a radio button or dropdown field. The option the person picks can drive the pricing that follows. Forms can also run hooks, which are small pieces of logic that call a web address or evaluate an expression while the form runs. See Form Hooks and Expressions.
Forms and Page Layouts
A page layout arranges a record's fields on its create and edit screens. Rhythm stores each page layout alongside the forms for that record type, and you design it with the same designer. That is why some applications list page layouts next to forms. A page layout is always a single page. When a record screen uses a page layout, it shows the fields without page buttons, drafts, hooks, or conditional visibility. See Page Layouts Explained.
Forms and Processes
A form does nothing on its own until an application uses it. Each application chooses the form it shows for a specific purpose, such as a membership application process. Each application's articles explain how to attach a form. Configuration usually follows the same path across applications: an application-specific setting names a process, the process names the form it uses, and the form names its fields. If you are looking for where a value is controlled, work backward through that chain.
For contact and profile forms, use Manage Contact Forms and its Configure Defaults option to attach a new form to the portal's edit-profile page. The form a contact sees during portal account signup comes from that same configured default contact form, not from an organization form.
Add a note or comments field directly to a process's form, such as a join process, so the person filling it in can complete it up front. That way, the value exists from the start instead of being added later by editing the record.
When the person presses Submit, the form sends the answers to that application. The application checks the answers before it saves the record. Required questions, conditions, and custom errors in the form help the person complete it, but the application still checks what it receives.
Not every kind of purchase or request fits a standard store's ordering logic. When it does not, a web form is a useful fallback because it can capture the request details, and staff can review the submission and create an invoice manually afterward. This works because of a distinction that runs through the whole product: an order triggers an operational outcome, such as creating or updating a membership, creating a gift, or registering an attendee, while an invoice or payment only records money owed or paid. A web form does not create any of that on its own; it just collects the request for staff to act on.
flowchart LR
A[You design and save the form] --> B[An application names the form]
B --> C[A member or staff member opens it]
C -->|Save & Return Later| D[Draft kept for the contact]
D -->|Continue Working on Draft| C
C -->|Submit| E[The application checks and saves the record]
The Same Form Everywhere
Rhythm uses the same form display in every Console and portal, so a form behaves the same wherever it appears. This is also true for a portal record such as a custom-object add or edit screen. It uses the standard web-form renderer, not a separate portal-only component, so everything in this article applies there too. One difference depends on where the form appears: when a required custom field is set to Make optional in the console, staff do not have to answer it in the Console, but it stays required in a portal. Built-in fields do not have that setting; they are required wherever the record type or the form requires them.
If staff and members need different questions or different required fields, build separate forms. Each form has its own Required: setting for each field it contains, so a registration form and a profile form can ask for the same field with different rules. If a submission goes through without a value you expected, check whether that field is marked required on the form that was used. A field that is optional on the form lets someone submit without it, even if the same field is required elsewhere. A form can offer only fields from its own record type. For example, a contact form can show built-in contact fields and custom contact fields, but it cannot show membership fields, even as a read-only value.
A composite section that asks for a contact and creates or links an organization at the same time needs extra care. Showing a field as required visually does not guarantee Rhythm keeps the organization value if the person moves on without filling it in. Set the actual required validation on the underlying field, not just its visible marker, or a person can advance past the page and lose the organization they were creating.
Choosing What a Form Exposes
Adding a field to a form does more than ask a question. It can also let the person filling in the form take an action you did not intend. A few examples:
- Parent Organization. If an organization form shown in the portal includes the Parent Organization field, a portal user can link their organization to a parent organization. Leave the field off a portal-visible form if you do not want portal users making that change themselves.
- Contact roles. A portal contact form that includes a contact role field lets the portal user choose a role for themselves. Rhythm does not assign a role automatically just because the field exists. To keep role selection staff-only, hide contact roles on the portal-facing form. From Contacts & Organizations setup for forms, open the portal profile or update form and hide contact roles inside the Work Information component. You can leave the field available on the equivalent staff-facing form in the Console.
- Organization Type. This built-in field can be added to a Console or portal form, but as observed, it currently behaves like a plain text box instead of a restricted picklist. That risks inconsistent values, so it is best left off organization forms in both the Console and the portal until it works as a picklist.
- Notes. Contact and membership records each have a built-in Notes section that is not shown by default. Add
Notesto the relevant edit form's field group to expose it. - Organization, on an application or a contact form. Whether an Organization field on a form lets someone create a brand-new organization, instead of only choosing an existing one, depends on the specific component used to show that field, not on the field itself. Do not assume every Organization field behaves the same way. If an applicant finds the field confusing, you can remove it from the application form as a workaround. The application keeps its linked organization even when the field is not shown. Conversely, when an organization administrator in the portal is already working inside a specific organization's context, adding a new contact there does not need an editable Organization field at all, because the organization is already implied by where they are working.
- A contact-record field used to drive conditional visibility. If you place a field on a contact form specifically so you can use its answer to control conditional visibility elsewhere, remember that the response is written back to the contact record like any other answer on that form. It is not held only for the condition.
Changes Go Live When You Save
Forms do not have a draft or publish step. When you save a change, the next person who opens the form gets it in every Console and portal. Anyone already part-way through keeps the copy their browser already loaded. There is no version history, so keep a copy of a form before you make a large change.
To try a form before members see it, use Test this form in the forms list. Test mode affects only your browser: forms of that record type show the test form instead of the configured form, with a banner. Test mode uses a snapshot, so switch it off and on again after you change the form. Rhythm handles a test submission like any other submission, so testing a form that takes payment in your live account can create a real order.
Save and Return Later: Where Drafts Go
If the application that hosts the form allows drafts, a page can offer Save & Return Later. When the person presses it, Rhythm saves the answers entered so far as a draft, even if some answers are not valid yet, and shows Draft Saved Successfully.
- A draft belongs to a contact and a record type, and sometimes to a context such as one event. It is not tied to a particular form design.
- Each contact can have only one draft for each record type and context. Saving again replaces the existing draft.
- When the person opens the form again, a card titled
A Draft of this Form Has Been FoundoffersContinue Working on Draft,Delete Draft & Start Over, and, where the application allows it,Start Over, but Keep Draft. A resumed draft opens on the first page. - Drafts do not expire. A draft ends when someone deletes it or when the form is submitted.
- Drafts cannot include file attachments.
- There is no staff screen for drafts in progress, so you cannot see or query who started a form and saved it for later.
Warning
When the person presses Submit, Rhythm removes the draft before the application saves the record. If the application then refuses the submission, the answers stay on screen, but the draft is gone.
If a registration form occasionally fails to load or initialize for a member, and you cannot reproduce it yourself, it can happen alongside a saved draft record for that registration going missing on the back end. Treat this as a useful clue for support, not a confirmed cause on its own. If you see it happen more than once, note the person, the form, and when it happened, and pass those specifics to Support so they can check the logs for that occurrence.
What Happens Automatically
- Rhythm adds default forms when an application that supplies them is switched on.
- A saved form change reaches the next person who opens the form.
- Rhythm refuses to save an out-of-date copy, so you do not overwrite a colleague's change.
- A form that another record relies on cannot be deleted; the list shows
Unable to delete <object name>. - Drafts stay until someone deletes them or the form is submitted.
Where to Go Next
- To build or change a form: Web Forms.
- To understand what the person filling it in experiences: How a Form Behaves for the Person Filling It In.
- To add the fields a form collects: Custom Fields Explained.