When someone opens the menu to start an application, Rhythm shows only the paths that match that person or organization at that moment. It uses the same approach on the person’s own record, in the Portal, and from a contact’s or organization’s 360 in the Console.
Why This Exists
Most associations use different application processes for different situations. You might have one join process for people with no membership history, a renewal process for active members, a reinstatement process for recently lapsed members, and change-of-affiliation processes for members moving between chapters, packages, or add-ons.
If Rhythm showed every process all the time, an active member could try to join as new, or someone with no membership could try to renew a membership that does not exist. To prevent that, Rhythm checks the record’s current membership each time someone opens the list, then shows only the paths that fit.
What Decides the List
Rhythm first checks whether the record has a current membership. Then it uses that membership’s status to narrow the active application processes in your Rhythm account:
No membership record at all. Rhythm offers only join processes, and only when at least one active join process matches the record type, person or organization. The join process’s customer type also controls which membership types appear inside that process. For example, a process configured for organizations only offers organization membership types, so an individual membership type needs a join process built for individuals.
If the record has any membership record, even one that lapsed long ago, Rhythm does not treat the record as new. It uses the rules below instead. An inactive membership still counts as an existing membership for this purpose. An organization with an inactive membership is not treated as having no membership, so it does not simply start over with a brand-new application. Deleting that inactive membership removes its member contacts from the organization, so keep that in mind before you delete one just to clear the way.
A join process can also be limited to specific membership types or packages, so new applicants see only the ones your account wants to offer. A member who already holds an excluded type can still renew it, because renewal follows the rules below instead of the join process’s own restriction.
If a person changes organizations, a membership tied to the old organization can still block access to the new organization’s application processes after they move. Ending the old membership with a termination date, a billing-run drop, or deletion clears the way.
Active, with an expiration date, and the membership is a principal one (not one assigned or flowed down from an organization). Rhythm offers a renewal path only when the expiration date falls inside the renewal process’s configured renewal window. Outside that window, Rhythm does not offer an application path for that membership. If the record appears as a non-member for any reason, such as after an identity change, the Portal offers a join option instead of renewal, even when you would expect the person to renew.
Active, with no expiration date (a membership that never expires). Rhythm offers only change-of-affiliation paths. It never offers join or renewal paths for this membership, even for an upgrade.
Active without benefits. Rhythm offers join and change-of-affiliation paths, but not renewal or reinstatement. Join is available only for a principal membership. A membership assigned to someone, or flowed down from an organization, sees only the change paths its origin allows.
Inactive (lapsed) or terminated. Rhythm offers a reinstatement path while the membership is inside that process’s reinstatement period. After that period passes, Rhythm removes the reinstatement path and offers a join path instead.
Reinstatement and join are not interchangeable. Reinstatement reactivates the same membership and advances it from its prior expiration date, the way a renewal would. Join starts the record down the same path as a new member’s application and updates the expiration the way a new membership does. That is why join, not reinstatement, is the right path when a former member has been lapsed a long time and needs dates to advance correctly instead of picking up from an old expiration date.
If former members should return with a fresh membership instead of reactivating the old one, use a join process for them and configure its eligibility to include inactive members. Using join for a former member does not create a new profile. Their existing record stays in use, and the join flow updates that same membership after they choose a package. When staff need to treat a returning person or organization as a new join rather than a renewal, it can help to run billing first, identify the prior membership by its expiration date, complete the drop, and then create the membership as a new join.
An inactive membership with no termination date may not show a join process configured for inactive members, or it may stop the person from continuing a rejoin process already in progress. Adding a termination date can be the missing prerequisite that makes the process appear or lets the rejoin continue. A member without a termination date continues along the renewal path instead of a rejoin path. If a rejoin package also happens to be available through that renewal process, criteria or customization meant only for rejoins may not trigger because the member is following the renewal path.
Your Rhythm account’s Membership settings can also hide join paths during the reinstatement period, so a lapsed member is directed to reinstate instead of rejoining as new. That setting never hides join from someone who was never a member or who is active without benefits. This join-hiding setting, the reinstatement period, and the process’s own eligibility criteria are three separate layers that all affect what appears. Passing one layer does not guarantee the others are satisfied, so a join or rejoin process can still be missing even when its own eligibility criteria are met.
If reinstatement is enabled with no reinstatement period defined, Rhythm treats the period as unlimited. Combined with the join-hiding setting, that can leave a lapsed member with no application option at all until you set a period. Your account’s global reinstatement period setting can also take precedence over a shorter period on an individual reinstatement process. That means a lapsed member can be outside the reinstatement window even though the process itself was configured more generously. If reinstatement seems to run shorter or longer than the process suggests, check the global setting too.
Defining the global reinstatement period alone is not enough. A membership application process tied to reinstatement must also exist, or no reinstatement path appears, no matter how the global setting is configured. Turning reinstatement off in your account’s settings does not let a lapsed member keep renewing indefinitely. They can still renew until they lapse, and once lapsed, a join process is their only way back when reinstatement is not enabled.
When only one process is available to someone, the Portal can take them directly into that application instead of showing a choice screen first.
Suspended. Rhythm does not offer any application path, including join.
Waiting on a payment. Rhythm does not offer any application path while the membership’s dates are waiting on a payment that has not posted, unless the membership already has a termination date.
Rhythm runs these rules against the membership’s current status every time someone opens the list. Starting an application does not lock in eligibility. Rhythm does not repeat the eligibility calculation after an application is underway, but it calculates eligibility fresh the next time anyone opens the menu. Passing a process’s own eligibility test does not guarantee the process will appear to that applicant, because the status rules above and any account settings that affect reinstatement and join visibility still apply.
A membership’s origin decides what else it can do. A principal membership is the person’s or organization’s own membership. Only a principal membership can be joined again individually, renewed, or reinstated. A membership assigned to someone, or flowed down to them from an organization, is judged only by the change-of-affiliation paths that origin allows.
This can keep individual join and renewal options from appearing even after the assigned or flowed-down membership has expired or been terminated. To clear it, delete the old membership record or change its origin to Principal. With an assigned origin, every application process can be hidden from a person in both the Console and the Portal until that change is made. Members cannot make that change themselves, so an administrator must update it in the Console.
Origin can also decide which renewal option someone sees. An origin of Flowdown is treated as an organization’s membership, so only organization-style renewal appears, even on what looks like an individual’s own record. Changing the person’s membership origin to Principal brings back the individual renewal option. Flowdown origin can also keep every individual membership type from appearing when you start a brand-new application for that person. Change the origin to Principal first to make those types selectable.
A membership that was previously tied to an organization’s package can also stay governed by that package’s own eligibility criteria after it goes inactive. That can block the person from self-serving into an individual join. A separate process may be needed for members transitioning out of an organization-linked package. An organization’s own flowdown membership, a corporate membership it inherits from another organization, renews through the organization that holds the principal membership rather than on its own.
A contact who is currently receiving an active flowed-down membership from a related organization is not offered a join path either. Rhythm treats them as already covered, so a become-a-member application will not appear until that flowdown coverage ends.
Tip
A contact’s own status can stay Active even when they are not a current member, because contact status and membership status are different fields. If you or an integration need to check whether someone is a current member, use the membership’s status, not the contact’s status. Reading contact status alone can misclassify a non-member as active.
flowchart TD
A[No membership record] --> J[Join only]
B[Active, expiring, principal] --> C{Inside renewal window?}
C -->|Yes| R[Renewal]
C -->|No| N1[No path offered]
D[Active, never expires] --> CH[Change affiliations only]
E[Active without benefits] --> JC[Join + change affiliations]
F[Inactive / lapsed] --> G{Inside reinstatement period?}
G -->|Yes| RE[Reinstatement]
G -->|No| J2[Join]
H[Suspended] --> N2[No path offered]
P[Awaiting payment, no termination date] --> N3[No path offered]
Applying for an Organization
A contact who belongs to an organization can sometimes start an application for that organization, in addition to starting one for themselves. Either of these can allow it:
- An administrative contact role. If one of the contact’s roles on the organization is administrative, they can see the organization’s eligible paths as well as their own, as long as at least one active organization-level process exists.
- A contact-role permission your account has configured. Even without an administrative role, a contact can see organization paths when your Rhythm account’s Membership settings give that specific role permission to do so. This permission does not apply to change-of-affiliation processes, which are granted only through an administrative role.
No matter how the contact qualifies, Rhythm decides which organization paths to show from the organization’s own membership status, using the same rules above. Rhythm does not use the contact’s personal membership status. An organization’s own active or inactive record status is separate from its membership status. A non-member organization can still be an active organization record, and it needs to be active so these application workflows can find and use it.
If an application process is configured as an organization-type application, the applying user’s own record may need to be associated with an organization before the process is reachable. A user with no organization link may need the process changed to a contact-type application, or their record linked to an organization first, before they can proceed.
After someone starts a membership application for an organization, the contacts available to select are the ones already affiliated with that organization. If the organization has no contacts linked to it yet, the selection list is empty rather than broken. Applicants going through Portal onboarding can run into a related gap. If they can only search for an existing organization and cannot create a new one, they may see only individual or associate membership options. Associating to an organization, or being able to add one, can be a prerequisite for organization-based options to appear.
Reinstating an organization’s membership must be started from the organization’s own record, the Organization Membership 360, not from an individual contact. A contact who does not personally hold a membership sees only their own individual join options from their contact Membership 360. They cannot reinstate the organization’s membership from there.
Organization renewals need their own organization-level renewal process configured. If only contact-level renewal processes exist, no renewal option appears for the organization, even when everything else about its membership looks eligible.
An organization application process can be set up in either of two ways: with eligibility criteria the applicant must meet to reach a package, or with specific packages mapped directly into the process. When several reinstatement or rejoin processes exist for different categories of organization, update and test the one that actually matches the organization’s type. Editing the wrong process, or leaving its criteria pointed at the wrong organization type, can show the wrong process, or none at all, to an eligible organization.
For the same reason, eligibility criteria for an organization rejoin process need to evaluate the organization’s own type, not the type of its billing contact. Criteria that check the billing contact’s type instead can keep an otherwise eligible organization from seeing its rejoin process.
Using the embedded membership component from an individual certifications context does not narrow which organization membership processes appear. If the contact has permission to purchase organization membership, those processes still show, regardless of the certification-related scenario they are working in.
Eligibility criteria cannot directly check the membership status of other contacts on an organization’s roster. There is no way to build a rule that looks at whether someone else tied to the same organization is or is not a current member. After you choose a corporate membership renewal process for an organization, the next step can still show more than one organization membership type, including types other than the one you started with. That step works from the full set of organization membership types, not only the one first selected.
If one transaction needs to cover both an organization’s membership and one or more individual memberships on the same invoice, treat them as separate application paths because each one goes through its own process. Entering both through the wrong single path can produce dues allocation you did not intend.
An organization process is built to run against an organization’s membership, so a contact with no associated organization record cannot use it, even if they otherwise seem eligible. If your account needs a similar path for people who are not tied to any organization, offer it through a separate contact process instead of expecting an organization process to work for them.
This same calculation runs wherever the sign-up block appears, including when your account embeds it inside another form, such as an event registration. It looks only at the person’s or organization’s own membership, role, and permissions. It has no way to know what the surrounding form is about. If a contact is entitled to see their organization’s paths, those paths appear in the embedded block too, even inside a form that is otherwise about the individual signing up.
Eligibility Criteria and Errors
An administrator can add eligibility criteria to a process, so Rhythm hides that path from an applicant who does not meet the criteria. Advanced rule logic can be used for this, which makes it possible to block one specific person from completing a particular join or rejoin process. If Rhythm cannot check the criteria, for example because of a data problem, it does not hide the path by default. Instead, Rhythm replaces that one path in the list with an error message and continues to show every other eligible path normally.
Eligibility criteria are not limited to the process itself. A membership package can also carry its own eligibility criteria in both the Console and the Portal, so a missing join option or package can come from failing either the process’s criteria or the package’s criteria. A package’s eligibility can also depend on the member’s current status. For example, a renewal package that requires an Active status will not be selectable while the member is lapsed, even if the membership type itself is otherwise right for them.
A process configured to be available only to non-members does not automatically become available to inactive members just because they are no longer current members of a prior organization. If inactive members should also see it, expand its eligibility to include them explicitly.
The same “membership is blank” style of criteria, used on a join package or its process to keep new applicants separate from returning ones, can unintentionally hide the join process from a former member who has prior membership history but should still be able to join fresh. Review that criteria if former members report a missing join option.
You can also build the reverse pattern deliberately. Set up a rejoin path as a join process whose eligibility looks for membership status not blank and termination date not blank, so it catches previously enrolled people who are outside the reinstatement window without treating them as first-time joiners.
Criteria that reference a picklist value, such as a professional-status field, must match the actual field value exactly. A typo or stale value in the configured criteria, even one misspelled word, can make an otherwise matching member appear ineligible. An eligibility setting that is turned on with no criteria configured underneath it can also block a process from appearing in the Portal. If a process is unexpectedly missing, check whether its eligibility switch is on with nothing set below it, then either add criteria or turn the switch off.
For an organization’s own eligibility criteria, Advanced Rules & Logic evaluates the organization’s own fields, not the fields of the contact applying on its behalf. A custom field that exists only on the contact form will not be found when Rhythm checks the organization’s eligibility, and that mismatch can make packages disappear entirely with no eligible options shown.
A checkbox on a rule, labeled to apply the rule to the organization a contact belongs to, lets a contact-level eligibility rule evaluate against the contact’s related organization instead of the contact directly. Turn this on when a contact’s eligibility for organization membership should follow their organization’s own status rather than anything on the contact record.
Several settings besides eligibility criteria control whether a process or package displays in the Portal. The process itself needs Show in Portal turned on. If an organization membership option seems to be missing there, check that the process is configured for the organization entity type and that Show in Portal is enabled for it, because either one being wrong can hide it. If every package on a process also has its own “hide this package from portal” option turned on, portal users have nothing left to select, and the process shows as unavailable even though it is technically active.
A change-of-affiliation process follows the same rule. It does not appear in the Portal unless it is configured to show there, whether the contact receives it directly or through an organization’s flowdown. Show-in-Portal configuration is separate from eligibility. If a process’s underlying eligibility test passes but the process still does not appear, check its own Portal visibility setting next. This includes a process reached indirectly, such as through a Join/Renew entry point instead of a dedicated menu item. A process with Portal display turned off is not reachable from any Portal entry point.
A rejoin process that mixes packages meant for mutually exclusive audiences, such as non-member packages alongside inactive-member renewal packages, can fail to display in the Portal. This can happen even when a user would pass a narrower eligibility test or matches one of the package groups, because those audiences do not combine cleanly within a single process.
Reinstatement can also be configured for only certain membership packages or types. If the organization’s or member’s current package or type is not one of them, no reinstatement or alternate application option appears, even though the member is lapsed. A criterion written around termination date will not catch every lapsed record, because some lapsed records have only a lapse date populated and no termination date. Check which date field a criterion uses if lapsed records are not matching as expected.
A process can also depend on a related record’s fields, not just the applicant’s fields. A related organization missing a termination date can keep a contact from qualifying for a join process until that organization is given one. An organization’s own type can gate a rejoin package. If the organization record does not have the required type selected, the rejoin process does not show, and updating the organization’s type fixes it.
More broadly, a renewal or application process’s availability can depend on the type assigned to a related organization, and removing or correcting that requirement changes who can see the process. An organization missing its correct organization type can also produce a misleading result on the expected renewal. Instead of a helpful error, the person may simply be told the membership is not up for renewal, even when a supplier or organization-specific renewal path was expected. Assigning the right type on the organization record resolves it.
A process built for organizations only, with its Customer Type set to Organizations, may also fail eligibility for an individual Portal user acting on behalf of that organization, even though the organization itself is eligible. Changing the process’s Customer Type to include contacts as well as organizations lets those users see it. A newly created portal organization can run into the same kind of gap before its organization type is set. If applications are restricted to certain organization types, an organization with no type assigned may not see any matching application until that field is filled in.
Membership application processes and application group processes are independent of each other. Setting up a group process does not control which standalone membership processes a person sees. If certain people should not see a particular membership process, that process still needs its own eligibility criteria, separate from anything configured for groups.
When an application option seems to be missing, check both layers: the applicant’s or organization’s membership status, and any eligibility criteria configured on the process. Confirming the record looks eligible is not enough by itself if the process carries additional criteria of its own.
Eligibility criteria are useful, but they only filter paths out. They do not resolve every selection scenario by themselves. If someone still qualifies for more than one process after criteria are applied, criteria alone will not narrow the list to one required choice. You may need a different approach if exactly one process must show without asking the applicant to choose.
Tip
Testing a process’s eligibility criteria confirms whether a specific contact or organization passes or fails that one rule. A pass there does not guarantee the process will actually appear to that person, because the membership-status rules described above and any relevant account settings still apply on top of it.
Eligibility criteria are usually checked against fields on the record the process belongs to: a contact process checks the contact, and an organization process checks the organization. If an organization process's criteria reference a custom field, make sure that field is actually set on the organization record rather than only on the contact form the applicant fills out. A value that exists only on the contact's own profile will not satisfy a criterion written against the organization, which can make an eligible-looking organization see no packages at all.
Tip
A path can also disappear because the criteria reference a picklist value that no longer matches exactly, for example after a picklist option was renamed or corrected. If a path you expect to see is missing and the applicant's membership status looks right, check that any picklist values named in that process's eligibility criteria still match the field's current wording.
What This Explains
If you do not see a renew or reinstate option for a membership, check the membership’s current status. It may be outside the renewal window, past the reinstatement period, or in a status that does not allow that path, such as suspended, active without benefits, or awaiting payment.
If a join option is missing for someone with no membership history, confirm that at least one active join process exists for their record type. If someone can start an application for their organization but not for themselves, or the reverse, the difference usually comes down to whether they have an administrative role or a granted contact-role permission on that organization. If your Rhythm account has a custom message configured for when no application processes are available, Rhythm shows that message to any Portal user with no eligible processes, regardless of which reason above caused it.
For the day-to-day work of starting and managing applications from the Console, see Create and Manage Applications in the Console. For how a member sees and starts these same paths on the Portal, see the Portal's own application-start article. For how to configure processes, eligibility criteria, and Portal visibility, see Application Processes, Forms, and Status Reasons; for the reinstatement and renewal settings themselves, see Membership Terms and Renewal Rules.