A group application process sets the rules for each application group created under it. It controls the contact form administrators use to register each person, the membership types and packages the group is intended for, who can manage the group, the instructions and confirmation email the group administrator receives, and how checkout works.
This article explains how to create and manage group application processes. Group membership applications must also be turned on for your account; see Membership Terms and Renewal Rules. For the steps a group administrator follows to register applicants and check out, see Search, Start, and Manage Application Groups.
Use a group application when one administrator needs to register and pay for several people at the same time, and each person should receive their own individually owned membership. This is different from an organization membership. A group-purchased membership belongs to the person it covers, and it stays with that person if their organization changes later. An organization membership belongs to the organization, and its benefits flow down to the people connected to that organization. Choose a group application process when several separate memberships should be purchased together in one order. Choose flowdown through an organization membership when the organization itself should hold the membership.
What This Controls
- The Rolodex contact form a group administrator completes for each person they register. A group administrator can create applications only for individuals; group application processes do not register organizations.
- Whether the process is limited to specific membership types, packages, or contact roles.
- Whether an administrator can register people outside their own organization.
- Whether the process appears in the Portal, and which name members see there.
- The instructions shown to group administrators, and the confirmation email sent after checkout.
- The checkout settings for orders created by groups using this process.
Where to Find It
Go to Membership & Committees › Setup › Applications › Group Processes to see the list. Select Create Group Application Process to create a process, or open an existing process to edit it.
Tip
Group Processes appears on the Setup menu only when group membership applications are turned on for your account. If you do not see it, go to Setup › Other Settings and turn on Enable group membership applications first.
When you set up group applications for the first time, complete these steps in order: turn on Enable group membership applications under Setup › Other Settings › Other Options, create at least one Group Process using the steps below, and, if you want group applications in the Portal, install the Application Groups portal feature there. After all three are in place, an Application Groups area appears in the Membership sidebar, and the Portal experience works much like event group registration.
Create or Edit a Group Application Process
Prerequisites
- Group membership applications turned on for your account.
- A Rolodex contact web form to use when registering each applicant.
- Go to Membership & Committees › Setup › Applications › Group Processes and select Create Group Application Process, or open an existing process.
- Enter a Name:. For a new process, the identifier fills in automatically.
- Under Options, choose the Contact Form: administrators complete for each person they register. If you need to require profile data before someone can be registered, such as a region, add that field to the Portal's contact or update-profile form and mark it required there. When that contact form is selected here, applicants must save the contact form, including the required field, before they can continue.
- Optionally check Restrict the membership types that can be applied to in this process and choose the types. You can also check Restrict the membership packages that can be applied to in this process and choose the packages.
- Optionally check Allow group administrators to submit applications for people not linked to their organizations and choose an Account Delegation Process:. This appears only when that Rolodex feature is on for your account. Some administrators have seen this option error on a new process before the Account Delegation Process field appears. If that happens, confirm that the account delegation feature is on for your account, then try again.
- Optionally check Restrict the contact roles that can engage in this process and choose at least one contact role. If you check this box and leave the list empty, no administrator is offered the process, so always choose roles when you turn it on.
- Decide whether Include the group administrator on all membership confirmation emails should stay checked. This uses the same control as the confirmation-email switch below. Turning it off is meant only to control whether the group administrator also receives each member's confirmation. Some accounts have also seen it affect whether individual members received their own welcome emails, so confirm that members still receive theirs after you change this setting.
- Under Show in Portal, decide whether members can use the process. If they can, set Display in the portal as: to a friendly name. This setting is separate from hiding a membership package from the Portal, and separate from the "Add membership package to Registration" component; each one controls a different part of the Portal experience.
- Under Group Administrator Instructions, turn the switch on and write instructions if you want administrators to see more detail before they start.
- Under Group Administrator Confirmation Email, keep the switch on and write a subject and body, or turn it off. You cannot save a new process with the switch on and no email content. Application merge fields in this email resolve only inside a Handlebars
{{#each}}block that iterates over the group's applications, so use that pattern to list each application's details instead of referencing an application field by itself. - Optionally turn on Override Checkout Settings to give groups in this process their own checkout configuration instead of the account default. The merchant account and bank account choices are limited to accounts that belong to the business unit you select. If the account you expect is missing, check that it belongs to that business unit.
- Select Save Changes.
Result
The process is saved and appears on the Group Processes list. Group administrators who meet its restrictions can start a group under it in the Console. If Show in Portal is on, they can also start a group in the Portal after the Group Applications portal feature is installed there.
Avoid the Built-In Referral Contact Field for Now
Do not use the built-in Referral Contact field on your contact form right now; it has an open security issue. Use a plain text field to collect referral information instead. Even when the built-in field has been used, some accounts have found that entered values do not return in query results as expected. A text field paired with manual review is the more reliable way to capture and later use this data.
If the contact form registers applicants one at a time and only some questions should appear conditionally, remember that visibility rules apply to a whole page or field group, not to a single question by itself. Move questions that need their own visibility rule into a dedicated field group first, then apply the condition to that group.
If you need to change an existing eligibility rule from a single-value comparison to one that checks a list of values, saving the changed criterion in place can fail to keep the list. Delete the existing criterion and its logic, save the process, then add a new criterion using the list-based operator and save again.
The Settings
| Setting | Options | Default | Effect |
|---|---|---|---|
| Contact Form: | A Rolodex contact web form | None selected | The form used to register each applicant. Required |
| Restrict the membership types / packages that can be applied to in this process | On, off; then a multiple-choice list | Off | Saves the membership types or packages the group is intended to use. These choices do not limit registration when a group is created, so treat them as information rather than an enforced limit |
| Allow group administrators to submit applications for people not linked to their organizations | On, off; then an account delegation process | Off | Lets an administrator register someone outside their own organization. Appears only when the account delegation feature is on |
| Restrict the contact roles that can engage in this process | On, off; then a multiple-choice list of contact roles | Off | This is the restriction Rhythm checks. Only contacts with one of the chosen roles are offered this process in the Portal's process list. If you turn this on and choose no roles, nobody is offered the process |
| Include the group administrator on all membership confirmation emails | On, off | On | Uses the same value as the Group Administrator Confirmation Email switch; checking one checks the other. Rhythm may combine the order confirmation for a group into one email instead of sending one per member, so verify what your members receive after you change this setting |
| Show in Portal | On, off | On | Controls whether the process can be offered in the Portal at all. This is separate from hiding a membership package, and from the "Add membership package to Registration" component; each one hides a different part of the Portal |
| Display in the portal as: | Text | Empty | The friendly name shown when more than one process is available |
| Group Administrator Instructions | On, off; then rich text | Off | Detailed instructions shown to the administrator before they start a group |
| Group Administrator Confirmation Email | On, off; then subject and body | On | Controls whether an email is sent to the group administrator after checkout completes. If you need to tell group members about a specific add-on, the process-level confirmation email is one way to include that content, but it goes to everyone in the group whether or not they chose the add-on |
| Eligibility Criteria | On, off; then a rule builder | Off | Rules are saved, but they do not decide which processes a contact can use. When a package's own eligibility criterion checks "Application Process (Membership) equals," it evaluates the member's last application process on record, not the group process currently being used |
| Override Checkout Settings | On, off; then checkout settings | Off | Uses this process's checkout configuration instead of the account default, including its own payment options separate from your Rhythm account's global checkout settings. Membership's global processing-fee setting is a separate layer: whether a fee is actually charged on an order from this process depends on this process's own checkout configuration, not only the global setting. The Group Membership Application Checkout form itself is not configurable in the Console |
Tip
The Group Administrator Confirmation Email goes to the person who receives the membership's benefits, not automatically to anyone else. If a related add-on product's own confirmation email reaches only the group administrator, or you need every applicant to see instructions about their own selections, you can add that content to this process-level email instead. Keep in mind it goes to everyone processed through the group, so write add-on-specific instructions in a way that still makes sense to applicants who did not choose that add-on.
Tip
Override Checkout Settings changes the checkout configuration a group's order uses, such as its business unit or accounts. You cannot redesign the checkout screen or add fields to it from the Console; it is a fixed step that turns a group's draft applications into one order.
Dependencies and Precedence
Only the contact-role restriction narrows the Portal's process list. Membership type, package, and eligibility-criteria restrictions are saved, but they do not change which processes a contact is offered. A group application process can also exceed what a package's "Application Process (Membership)" eligibility field can represent, because a group involves multiple process selections. Do not rely on that field as a direct gate for a group process.
Confirmation email and its "include the administrator" checkbox share one control. When you change one, the other reflects the same value.
A membership type needs its own process. If members can join through group applications for one membership type but not another, the first type has a group process and the second does not. Create a separate process for each membership type you want to offer as a group option. If different packages need to appear for different flows, the more reliable setup is a dedicated membership type and package used only by the group process, with the remaining types and packages assigned to your individual processes instead.
Deleting a contact form, account delegation process, or checkout configuration a process still names is refused while that process points to it.
Group application processes in the Portal cannot be manually reordered. Regular application processes can be reordered, but you cannot change a group process's position in the list.
There is no documented limit on how many applications a group application batch can hold. If checkout for a large group fails with a "Message too long" error, that is more likely a sign of another underlying issue than a known batch-size limit. Contact Support with the group's details instead of assuming you need to reduce the group's size.
When Rhythm's eligibility criteria and enforcement do not cover a scenario, such as eligibility based on a related contact's membership, use a supported fallback instead of expecting the process to filter it for you. You can require a contact role or a custom field the organization maintains, allow submission with clear instructions and review contacts manually afterward, or build a query to find eligible organizations for review.
A group application process may not work well as an eligibility condition elsewhere in your account. For example, an "Application Process (Membership)" condition on a package's eligibility criteria is built around a single process selection, and a group application involves more than one. If you rely on this kind of condition to gate something for group applicants, confirm it actually recognizes them before depending on it.
Warning
Deleting a group application process is refused while a group or an application still names it. If you no longer want to offer the process but cannot delete it, use Status: Inactive instead.
Removing a Package's Advanced Rules & Logic Broadens Who Can Access It
If a package's eligibility depends on Advanced Rules & Logic and members you expect to qualify cannot process in the Portal or Console, removing those rules lets affected memberships process again in both places. It also means other users who do not meet your intended custom-field criteria can see and access that membership type and package. Treat this as a temporary measure while you review the eligibility configuration, not a lasting fix.
Change Impact and How to Revert
- Deactivating a process with its Status switch stops new groups from being started under it in the Console and Portal, while groups already in progress continue. This is the recommended way to retire a process without deleting it. It is also more reliable than Show in Portal for hiding a process: at least one report found that turning Show in Portal off did not remove a process from the Portal flow, while setting the process Inactive did. If the Portal visibility setting is not being followed for a process, set it Inactive as a reliable temporary way to remove it from the Portal while you investigate.
- Changing a process's settings while groups are already using it affects those groups the next time their page loads. Nothing prevents you from editing a process while groups are actively checking out under it.
- Deleting a process is permanent in the product. You can recover a previous version only through your account's audit history.
Permissions
Membership Administrators can create, edit, deactivate, and delete group application processes from Setup › Applications › Group Processes.
Validation and Errors
| Message or symptom | Cause | What to do |
|---|---|---|
| The process cannot be saved; Contact Form: shows required | No contact web form is selected, or your account does not have a Rolodex contact web form yet | Create a Rolodex contact web form, then choose it |
| The process cannot be saved with the confirmation email switch on | Group Administrator Confirmation Email is on, but no subject or body is written | Write a subject and body, or turn the switch off |
| A restriction checkbox is on but the process is still offered to everyone, or to nobody | Membership type, package, and eligibility-criteria restrictions do not narrow the Portal's offered list; only the contact-role restriction does | Use the contact-role restriction if you need to limit who is offered the process |
| A membership type never appears as a group option | No group application process exists for that type | Create a process and, if you use type restrictions for your own records, include that type |
| The delete fails | A group or application still names the process, or it still names a contact form, account delegation process, or checkout configuration another record depends on | Deactivate the process instead of deleting it, or remove the dependent records first |
A validation error naming merchant_account_id or bank_account_id needing to start with business_unit_id | The Override Checkout Settings payment accounts you chose belong to a different business unit than the one selected on this process | Choose a merchant account and bank account that belong to the same business unit as the process's checkout settings |
Related
- Membership Terms and Renewal Rules
- Search, Start, and Manage Application Groups
- Start and Manage Your Application Group
- Contact Roles
- Email Settings: Senders, Reply-To, Footer, and Sandbox Redirects