An application process is the path someone follows to join, renew, reinstate, or change an affiliation. It controls the form they complete, the membership types and packages they can choose, who can use the process, whether staff approval is required, which emails send, and how Rhythm prices the order.
Use this article to create and edit application processes, design the form applicants see, and manage the status reasons staff can choose on an application. For details on how Rhythm prices an application's order, see "How an Application's Order Is Priced" in Related below. For group joining, see "Group Application Processes" in Related below.
Where to Find It
In the Membership & Committees Console, go to Setup, then:
- Applications › Processes to create or edit an application process.
- Applications › Forms to design the application form itself.
- Applications › Status Reasons to maintain the reasons staff can choose when they set an application's status.
- Applications › Custom Fields to create and manage the custom fields available on membership application forms.
Some older help content and screens call this area Membership › Application › Forms. If your console does not show that path, use Setup › Applications › Forms instead; some console labels have changed since that guidance was written.
Membership application forms control the custom fields applicants see. When you manually create or edit a membership record, those fields come from your account's membership page layout instead. If a field, such as a referral field, needs to appear in more than one application path, review the form assigned to each relevant process. Adding a field to one process's form does not add it to another process's form.
Create or Edit an Application Process
An application process must have a Type (Join, Renewal, Reinstatement, or Change Affiliation), a Customer Type (contact or organization), a name, and an Application Form:. The form picker shows only active application web forms, so create the form first if none is available. Set Customer Type: to match who is making the change: use contact when people manage their own membership-related affiliations, and use organization when someone acts on behalf of an organization's membership. The two customer types need separate processes rather than one process that serves both. Administrators sometimes use "application" to mean any member-facing form, but the process's Type: determines the actual path. A reused form or inherited form name can make it harder to tell which process you are viewing.
| Setting | Options | Default | Effect |
|---|---|---|---|
| Type: | Join, Renewal, Reinstatement, Change Affiliation | Last type chosen in this browser, else Join | Sets the kind of application this process creates and shows the related options below. |
| Customer Type: | contact, organization | Last chosen, else contact | Sets whether the process is for an individual or an organization. For an add-on's Change Affiliation process, contact lets an individual buy the add-on directly. organization makes the add-on belong to the organization and flow down to members, and only admin contacts can purchase it for the organization. When you set this to organization, the whole process is organization-only, so you do not also need to add Customer Type = Organization under Eligibility Criteria. |
| Show in Portal | On/off | On | Controls whether Portal applicants can see and use this process directly. A process with this off can still appear when an event registration form uses Embed Membership Application. Make the process inactive instead if you need to hide it there too. |
| Display in the portal as: | Text | — | The name applicants see in the Portal. This is required when Show in Portal is on. Choose a name that clearly tells the applicant which path to use. When more than one process is available, this label helps them choose the right one. When only one process is available, no selection list appears. Portal selection lists are ordered alphabetically by the process's console name, not by this portal label, so prefix the console name with a number if you need a specific order. |
| Application Form: | An active application web form | — | The form the applicant completes. The picker shows only forms built for Membership applications. A membership signup link does not carry its own field setup; applicants always see the fields on this assigned form, so a custom field appears only when you include it there. |
| This process is only applicable to certain types of organizations… | Checkbox, revealing an organization-type list | Off | Limits the process to organizations with the types you choose, and to contacts who belong to one of those organizations. This restriction does not filter out a contact with no organization. Configure it on each relevant process; changing one renewal or other process does not update any other process. |
| This process will only present certain membership types… / …certain membership packages… | Checkboxes, each revealing a list | Off | Limits which membership types and packages this process offers. |
| Do not send activation email until membership is paid | Checkbox | On | Holds the activation email until payment is complete. The submission confirmation email still sends when Rhythm receives the application. |
| Do not automatically select a package for renewing members; allow them to choose | Checkbox | Off | Lets a renewing member choose a package when no order-generation rule selects one for them. |
Each process uses one Application Form:. If one membership type or renewal path needs different required fields than another, clone the form for that path and create a separate process for it. For example, use a separate form and process when a field should be optional for one membership type but required for the rest.
For a separate Join process that works as a rejoin path for former members, add the intended package as a selectable package in that process's settings. Without it, a former member can reach the application but have no membership types to choose from.
Organization memberships depend on three settings working together: an application process with Customer Type: set to organization, an Application Form: built for organization applicants, and a membership package that matches the correct organization membership type. If organization join options are unavailable, check all three before assuming only the process is misconfigured. When staff approve an organization membership application, the contact selected on the application becomes the membership's contact on the resulting record.
To invoice for membership and have payment update the membership automatically, create a separate staff-only application process in the Console. Reuse your existing application form, turn off Show in Portal, and use Override Checkout Settings to allow invoicing or pay-later. When staff create a membership through this process, they can send the invoice, and payment then updates the membership automatically.
Turning Show in Portal off removes the process from the Portal, even if Display in the portal as: still has a value. You do not need to clear that field to keep the process hidden. Staff can still create and process applications through the process from the Console for every eligible contact or organization. Turning the process off in the Portal only stops applicants from starting it themselves there.
Membership Approval
| Setting | Options | Default | Effect |
|---|---|---|---|
| When membership applications are submitted, should they require approval? | Never, Always, Based on chapter, Custom | Never | Sets whether staff must approve applications submitted through this process. |
| Chapters: | Active chapters | — | Appears for Based on chapter. If any chapter on the application or order is in this list, the application requires approval. |
| Lambda function | An AWS Lambda function from your Rhythm account | — | Appears for Custom. An association-specific function decides whether approval is required. |
When a process requires approval, Rhythm still charges and processes the order normally. Staff approval happens afterward, when the membership is activated, so requiring approval does not stop or delay payment. Rhythm still creates an application entry on the Console Applications tab for you to review. That includes a Change Affiliation process, where processing the order creates the record the same way it does for other process types.
Approval is set on the process, not on a membership type. You cannot turn on approval for only certain membership types within one shared process. To require approval for some membership types and not others, create separate application processes for each group. Then use Eligibility Criteria and package or type restrictions to control who reaches each process and what it offers.
Warning
Some accounts have seen a Change Affiliation process create an application record when Membership Approval was set to Never, but not when it was set to Always or Based on Chapter. A later report described this as resolved. If a Change Affiliation process is not creating the application records you expect, check the Membership Approval setting and contact Support if the behavior does not match this article.
Tip
If applicants often submit more than one application while an earlier one is still pending approval, add a short message on the member homepage asking them not to submit again until they hear back.
Order Generation Rules
Order generation rules automatically assign a membership package, add-ons, or both when Rhythm prices an application. Turn on Order Generation Rules, then add a rule:
| Setting | Options | Default | Effect |
|---|---|---|---|
| Rule Name: | Text | — | Required. This is how the rule appears in the process's rule table. |
| Matching conditions: | Condition builder over the application, membership, contact, and organization | — | At least one condition is required. When every condition matches, the rule's actions apply. |
| Assign a membership package | Checkbox, revealing a package picker | Off | Assigns the chosen package, or leaves the package to the process's own package restriction when this is left blank. |
| Assign add on(s) | Checkbox, revealing add-on rows | Off | Adds one or more add-ons to the order, each with a fixed quantity. |
Rules run in the order they appear. If you delete a package, add-on, or chapter named in a rule or approval setting, Rhythm does not remove it from the rule.
Membership custom field values entered on an application are stored on the contact record after it is created or updated. Because those values live on the contact, you can query them later or use them as matching conditions here. You can also use them as eligibility criteria for other offerings, such as event registration packages.
Warning
Keep pre-processing logic and order-generation rules separate. Assigning a pre-processing function to the order-generation logic is a misconfiguration that can prevent membership package determination from working correctly during the application flow.
If order-generation rules cannot fully assign a membership type or package, a pre-process function can supply that logic before order generation runs. For example, use a pre-process function when the decision depends on data these rules cannot evaluate. A similar approach can help when a discount depends on information that is not available during the initial application: capture the information afterward through a Change Affiliation or other post-application process, then run billing so the correct price applies once the data exists on the record. Confirm this approach works for your own pricing rule, because it reflects an observed workaround rather than a guaranteed feature.
Turn On Order Generation Rules Only When You Have Added a Rule
Turning on Order Generation Rules without adding at least one rule is an incomplete configuration. If you save the process this way, Rhythm now automatically turns the switch back off on save, and reopening the process shows the feature disabled again. Add at least one rule before you turn the switch on, or expect it to reset.
Custom Logic, Eligibility, and Section Restrictions
Four switches let a function from your Rhythm account customize this process: Custom Application Generation Logic, Custom Application Pre-Processing Logic, Custom Membership Activation Logic, and Custom Membership Describe Sections Logic. You can use these functions to generate the initial application, pre-process it before order generation, run custom logic when the membership activates, and describe the applicant's sections. After you turn on any switch, you must choose the function it uses. Automatic section or division reassignment based on eligibility depends on connecting your own logic to the generate-the-initial-application function. Without that connection, the reassignment does not run in the Portal or renewal flow.
Eligibility Criteria limits who can start this process, using the same rule builder used elsewhere in Rhythm. The rule builder includes an Advanced Rules and Logic area where you can search for fields and apply operators such as is not blank to build more specific conditions. That rule builder cannot select or evaluate a person's past section membership. To check whether someone previously belonged to a section, write an expression under the process's eligibility criteria expressions instead of using the standard rule fields. A custom expression here can also test whether an application contains a specific add-on, using arrayIncludesPropertyValue(add_ons, 'add_on_id', 'ADD_ON_ID'). This is useful when you need to show fields or pages only after a particular add-on is selected.
When a process is named in eligibility criteria, Rhythm evaluates processes the applicant has already completed. It does not evaluate the process they are currently using, so keep that limitation in mind if you are trying to distinguish an applicant's progress within their current process.
Layering Eligibility Criteria on top of a built-in restriction, such as the organization-type limitation, can over-constrain a process so it never appears, even for applicants you expect to qualify. If a process is missing entirely, check whether the organization-type restriction alone already covers the eligibility you need before adding a separate criteria rule for the same condition. This matters most when a process's Eligibility Criteria is built for a combined Contacts & Organizations audience. A contact can pass process-level eligibility and still not see the membership type or package you expect if that type or package is restricted to organizations, because package-level restrictions are evaluated separately from process eligibility.
For organization rejoin processes that do not appear correctly, check the custom expression on that process's eligibility criteria. An expression that tests the applicant's contact type does not correctly track which organization types are eligible to rejoin, so replace it with an expression based on the organization type for each specific rejoin process.
Separately, relying only on the built-in organization-type restriction to control join or rejoin visibility for organizations can still prevent some users from seeing the intended process. In that case, add a custom expression based on a contact-type custom field to the relevant rejoin processes. Then create a separate join application process with criteria requiring the organization's termination date to be populated, so a contact can join for an organization only when that condition is met.
To create a rejoin path for former members who are no longer eligible for reinstatement, create a separate Join process for them. Use eligibility criteria such as membership status is not blank and termination date is not blank, so only former members can use it.
Section Restrictions sets the minimum and maximum number of sections a member can join through this process, either overall or per section type. Rhythm refuses two restrictions that name the same section type. Section restrictions are set per process, so a join process and a renewal process for the same membership do not have to enforce the same limit. To require the applicant to choose at least one section before continuing, set a minimum of 1 for All Section Types instead of relying only on a custom form error.
Warning
On a Change Affiliation process, the custom logic that matches available packages to an applicant's own field value also keeps their selection in sync with that field. If you turn this custom logic off, every package becomes selectable, including packages that do not match the applicant's field value, and choosing a package no longer updates that field for you. Only disable it if you are prepared to reconcile that field by hand.
The function you attach to activate the membership is called with the membership, the application, the order, the order line item, and the process as context. It is expected to return the membership object, including any changes your logic makes to it, so Rhythm can save it. Confirm this contract against your own implementation, because it reflects observed behavior rather than a documented guarantee.
Tip
Automatic section or division assignment during an application depends on Custom Application Generation Logic being turned on and wired to the function that performs the assignment. If members join or renew through the Portal and do not receive the automatic assignment you expect, confirm this switch is on for the process they used, and test each entry point (join, renewal) separately, since a function wired for one path is not automatically wired for another.
Warning
If you turn on Eligibility Criteria but do not add any actual criteria, this process can stop appearing in the Portal, even though nothing looks wrong on the process form. If a process you expect Portal applicants to see is missing, check whether Eligibility Criteria is on with no rules configured, and either add a rule or turn the switch back off.
Tip
If your account decides whether an application needs approval based on account-specific logic (the Custom option under Membership Approval), that decision is delegated to your own custom function rather than to a fixed rule. Keep that function's logic aligned with how your association actually wants approval decided, since Rhythm does not evaluate the decision itself.
Type-Specific Options
The options in this section depend on the process's Type:.
Renewal: a Renewal Window: in days before expiration, during which the "Renew" option appears in the Portal. This value is always a count of days, not any other unit. The option stays hidden until the membership's expiration date falls inside that window, so a member outside the window must wait, or you must widen the window, before Renew appears.
Renewal: a Renewal Window: in days before expiration, during which the "Renew" option appears in the Portal. Leaving this blank or set to 0 offers the renewal path at any time, with no window restriction. That can let a member submit more than one renewal application, while setting a specific number of days limits how long the option is visible.
Reinstatement: a Reinstatement Period:, and whether that period is measured from the membership's expiration date or termination date.
Change Affiliation: a required Change Fee: (see Change Fees), three checkboxes to prorate chapter, section, and add-on dues for the time remaining on the membership (all on by default), and which kinds of members (Principal, Flowdown, Assigned) can see the process.
Renewal: a Renewal Window: in days before expiration, during which the "Renew" option appears in the Portal.
Reinstatement: a Reinstatement Period:, and whether that period is measured from the membership's expiration date or termination date. A process can use its own reinstatement period here, or use the account-wide reinstatement setting in Membership settings instead. In either case, former members can rejoin through reinstatement only when that account-wide setting is turned on.
Change Affiliation: a required Change Fee: (see Change Fees), three checkboxes to prorate chapter, section, and add-on dues for the time remaining on the membership (all on by default), and which kinds of members (Principal, Flowdown, Assigned) can see the process. Add-ons selected during a Change Affiliation application appear on the order details page and in the order total, like any other order. This member-relationship setting also controls whether an add-on's own application process is available to more than principal members. If an add-on process shows no application options, check whether it allows Flowdown and Assigned members to see it, not just Principal.
Organization Options
These options appear when Customer Type: is organization. They control whether organization administrators can modify their members' chapters and sections, and which contact fields they see when they add a new contact during the application.
Contact and Organization Forms, Emails, and Checkout
Show Contact Form and Show Organization Form each show a Rolodex web form before the application itself. Turning on Show Contact Form requires the applicant to save their changes on that form before continuing with the membership application, so it acts as a required prerequisite step rather than an optional one. Fields such as gender or spouse name that appear on the membership application page usually come from this associated contact form, so remove or edit them there instead of in the application form or process settings. If pricing logic on this process depends on a contact field, such as a salary field read by an order-generation rule, include that field on this contact form so the applicant can supply or update it during the join or renewal flow. A pricing rule cannot use a value the applicant was never asked for.
You can also add an optional HTML header. For a member's own ability to edit their Portal profile, see the Platform and CRM articles on web forms and contact configuration. If a contact form used here includes privacy-page settings, the applicant sees an email confirmation step before the application is created. Choose a contact form without privacy-page settings if you need the contact and organization forms without that confirmation step. A validation error during the application can also come from the separate Application Organization Form configured under Contacts and Organizations, rather than from this application process. Check that form too if an enrollment error does not trace back to anything set here.
To use organization-level data in pricing or package eligibility, add the relevant custom field to an organization form and turn on Show Organization Form. This captures the value on the organization record itself, not only on the application, and lets you require the value there. In a Change Affiliation process, you can use the organization form the same way so the applicant updates the organization field that drives package eligibility. After that, the correct membership package can be presented. You can also add an optional HTML header. For a member's own ability to edit their Portal profile, see the Platform and CRM articles on web forms and contact configuration.
Two separate settings control which emails send for this process, so review them separately even though they relate to the same moment in the flow. The Submission Confirmation Email sends when Rhythm receives the application. It appears only when approval is required or the activation email is held until payment. The Membership Activation Confirmation Email sends when the membership activates. Do not send activation email until membership is paid decides which template is used at that point: with the option off, the process uses the Membership Activation Confirmation Email; with it on, the process holds activation until payment and uses the Submission Confirmation Email instead. Because the two settings are independent, leaving the submission email turned on can still send that message even when the activation email is configured correctly. If applicants report an extra or unexpected email, review the email options farther down the application process page, turn off the one you do not want, and save the process.
You can turn on the Membership Activation Confirmation Email on a join process to notify staff or members whenever a new membership is created, using content you write yourself. The submission confirmation wording is less clear for a Change Affiliation process: that email's text describes sending before membership activation, but a member changing affiliation is usually already active. Treat that description as approximate for this process type, and check the actual message applicants receive instead of relying only on the description. If an existing process stops sending its activation confirmation email even though the setting looks correct, try recreating the process with the same configuration. Doing this has restored the email on some accounts when the original process kept failing to send it.
Merge fields in these templates resolve only when real data exists. Fields such as {{membershipPackage.name}} and {{membershipPackage.notes}} populate only when the email is generated in the correct application-related context and the underlying application or package record has a value to merge. If the source record is empty, the merge field stays blank instead of showing an error. Chapter and section names are also available as iterable collections, so a template can loop over every chapter or section on the application instead of showing only one, for example:
{{#each membership.chapters}}{{name}}{{/each}}
{{#each membership.sections}}{{name}}{{/each}}Use Preview in either editor to send a test copy to any email address you enter, merged with a real member's data. Preview does not always match what a pending application receives. For example, a chapter that renders correctly in preview can still be blank in the email sent from a pending application, depending on the application's stage. Confirm important merge fields against a real submission instead of relying on preview alone.
The Submission Confirmation Email sends when Rhythm receives the application. It appears only when approval is required or the activation email is held until payment. The Membership Activation Confirmation Email always sends when the membership activates. Use Preview in either editor to send a test copy to any email address you enter, merged with a real member's data. To personalize with a membership type, use {{membershipType.name}}; iterate a membership's chapters with {{#each membership.chapters}} or {{#each application.chapters}} — membership.application.chapters is not a valid path and does not populate.
Tip
To check a field that only resolves from the application itself, choose a specific application record, along with its related contact or organization, when you preview. Preview does not send anything to that applicant; it only sends the test copy to the address you enter.
Tip
The demographic and other contact-profile fields an applicant sees on this part of the application come from the associated contact form, not from a setting on the application process itself. To add, remove, or reorder those fields, edit the contact form that Show Contact Form names instead of looking for the setting here. This also matters for pricing: if a custom field's value feeds a special price or eligibility rule, such as a salary field, that field needs to be on this contact form so the applicant can provide it before the application prices.
The Submission Confirmation Email sends when Rhythm receives the application. It appears only when approval is required or the activation email is held until payment. The Membership Activation Confirmation Email always sends when the membership activates. Use Preview in either editor to send a test copy, merged with a real member's data, to any email address you enter.
Tip
These two emails are switched on separately. If an applicant receives a submission email you did not expect them to get, check whether Submission Confirmation Email is still switched on for this process; turning it off and saving leaves only the activation email in place.
Override Checkout Settings replaces your Rhythm account's default checkout configuration for this process only.
Design the Application Form
You build application forms in the shared form designer under Setup › Applications › Forms, the same designer Platform uses for other web forms. See Web Forms and Configure Web Forms. Membership adds eight components you can drag onto the form alongside ordinary fields:
| Component | What it shows the applicant |
|---|---|
| Choose Membership Package | The available membership types and packages they can choose from |
| Select Organization Members | The individuals who should receive an organization's membership |
| Select Chapter | One or more chapters they can join |
| Select Chapter + Dues Product | A single chapter and dues product together, which then determine the type and package |
| Select Sections | The sections they can join |
| Choose Add Ons | The available add-ons |
| Review Membership-Specific Details | A summary of the applicant's membership selections |
| Directory opt-outs | Directory listing choices |
Most of these components are building blocks with no settings on the tile itself. Their behavior comes from the process's restrictions and order-generation rules, the membership type's section requirements, the package's included seats, and the settings in Chapters, Sections, and Add-Ons. A form with no package-picking component cannot be priced unless order-generation rules or the process itself provide a package. Add ordinary fields alongside these components for any extra profile or application questions you need. Membership does not require a special component for a custom question.
If applicants sometimes choose the wrong package and you cannot change the order shown in the picker, add instructional text near the package component to guide them. If a member's package should not change through self-service, remove the package-selection component from that form. For example, a renewal form can let members update their information without letting them switch packages; without the component, the applicant keeps their existing package.
A Change Affiliation form needs its Collect Order Details component on its own page, separate from the components that collect the new chapter or affiliation choice. Putting them on the same page has caused the affiliation change not to apply correctly.
Warning
Only put a submission control, such as Process Order, on the page that actually submits the application. Adding a second submit control to the form's completion or success page can trigger an error there, even though the membership was already processed from the earlier page.
Within a form, you can configure each ordinary field to display during the join process, the renewal process, or both. This lets the same form ask different questions depending on how someone reaches it. Custom fields created in the CRM app do not appear here directly. A field must be created as a Membership custom field under Setup › Applications › Custom Fields before you can place it on an application form. After the Membership custom field exists, edit the form and place the field inside a field group so it appears on the pages you want.
Select-field choices, such as the options for a custom dropdown, come from that field's own custom value list under Setup › Applications › Custom Fields. They do not come from records created elsewhere. For example, creating an organization record can make it appear in other organization-selection contexts, but it does not add an option to an application field's value list.
If you want a question to appear only for certain applicants, such as certain membership packages, configure conditional visibility on the field group or component that contains those fields. Do not configure it on the individual custom fields themselves.
If a supported custom field does not yet exist for data you need to carry over from an unsupported application field, you can copy the existing values into a contact or organization custom field instead. A mass update is usually the easiest way to do this for records that already have the value on the application field.
There is no dedicated referral component among the Membership form components above. To capture how someone heard about your organization during the application, add a custom field for it the same way. Plan to transfer that information to the application's referral contact by hand, and build custom logic only if manual transfer does not fit your volume.
A form's page sequence and components matter as much as any single setting. If you build a chapter or membership application form from scratch, base it on the full page and component structure of a working membership application form. Do not add only a first page or a final submit step. When an application flow ends right after checkout, configure the step after the order as the completion page, not another form page, so the submission finishes successfully.
Applicants' ability to save an in-progress application and finish it later is controlled per page. Review the form designer's Transitions tab for that page when you need to turn Save and Return Later on or off for a specific step.
When you set conditional visibility so a page or field group appears only for certain applicants, the rule is evaluated against the membership type the applicant has currently selected on the form. It is not evaluated against a general idea of their role as staff, contact, or member. Write and test the condition against the specific membership type value for every type the process offers, instead of assuming a looser "role" concept decides what appears.
Tip
To collect an extra question during renewal, create a membership custom field, add it to a field group, and place that group on the application form used by your renewal process. You can query the responses afterward the same way you query any other membership custom field.
After you clone the default membership form, you can open an individual question and mark it required, the same way you would on any other Rhythm form. Applicants must answer a required question before continuing.
Warning
The Update Order Details page an applicant sees during checkout is not fully configurable from the form editor. Elements such as Special Instructions and Collect Payment are hard-coded there and cannot be added or removed through the field-group configuration you use elsewhere on the form.
Tip
A single form and process applies the same required fields to everyone who uses them. If one membership type or renewal path needs a field to be required while others need it optional, clone the form, adjust which fields are required on the clone, and create a matching process for that specific type or path so it uses the clone instead of your general-purpose form.
Custom field values an applicant enters on the application are stored on their contact record once the application processes, the same as any other membership custom field. Because they live on the contact record, they can be queried afterward and used as eligibility criteria for other offerings, such as a membership package or an event registration package.
Maintain Application Status Reasons
Status reasons explain why an application has a particular status. Go to Setup › Applications › Status Reasons to create or edit one.
| Setting | Options | Default | Effect |
|---|---|---|---|
| Name: / ID: | Text / generated | — | Required. |
| To which status is this reason applicable? | Not Yet Submitted, Under Review, Approved, Rejected | — | Required. Each reason applies to exactly one status. |
| Status: | Active / Inactive | Active | An inactive reason cannot be selected going forward. |
You cannot create status reasons for Pending Approval or Cancelled because those two application statuses do not have a reasons list.
Dependencies and Precedence
- An active application form must exist before you can finish creating a process. For a change-affiliations process, an active change fee must also exist.
- Order-generation rules run before the process's own membership type and package restrictions control what the applicant sees. If you delete a package or add-on named in a rule, Rhythm does not remove it from the rule.
- You cannot delete a process, change fee, form, or function while another application process still refers to it.
Change Impact and How to Revert
- Turning Show in Portal off removes the process from the Portal immediately. It does not cancel applications already submitted through that process. If your account also offers this process through an embedded sign-up block on another form, such as an event registration, turning Show in Portal off may not keep it out of that embedded prompt. Setting the process Status to inactive is the more reliable way to remove it everywhere.
- Changing a process's restrictions, approval rule, or order-generation rules affects only applications started after the change.
- To restore a previous configuration, edit the process back to its earlier values. Rhythm does not keep a change history you can revert to automatically.
Permissions
Creating, editing, and deleting application processes, forms, and status reasons are Membership administrator actions in the Console. If you cannot access Setup › Applications, ask the person who manages security roles for your Rhythm account to update your access.
Validation and Errors
| What you see | Meaning and what to do |
|---|---|
| The save is refused, naming a missing field | A conditionally required setting is empty, such as a change fee, function, chapter list, mapping, or criteria. Fill in the missing setting. |
| The save is refused for duplicate section-type restrictions | Two restrictions name the same section type. Combine them into one row. |
| An applicant sees "Unable to load form" | The process has no form, or the named form does not exist. Choose a valid form. |
| An applicant sees "Error during order preparation" | The application form is missing required pages or components, often because it has only a first page. Compare it with a working membership application form, then add the missing pages and components. |
| A link on the application page returns a 404 | The link may point to an outdated external address stored in the form's text, rather than a Portal page-rendering problem. Check and update the link's target in the form. |
| You are not sure whether a fix from Support has taken effect | Submit a test application and confirm it reaches the status you expect before assuming normal processing has resumed. |
| Advanced logic using an organization membership field, such as Status, does not seem to save | In some cases, a save with this kind of rule does not report an error but also does not take effect. Reopen the process afterward to confirm the rule actually saved, and re-save it if it did not. |