An organization's membership can reach its people in two ways. It can flow down automatically to contacts and child organizations, or you can assign it seat by seat to named people. This article explains both options, how Rhythm shows where a membership came from, how linked organization contacts differ from people who receive the membership, and what happens when the connection that gave someone membership changes.
Flowdown: Automatic, by Role
When an organization's membership type uses flowdown, contacts linked to that organization in CRM receive the same membership automatically. Your administrator can limit flowdown to contacts with specific roles. If the allowed-role list is truly empty, no one receives the membership. That is different from having no role restriction, where every linked contact receives it. See A Record's Relationships to learn how contacts are linked to organizations, and How Contact Roles Are Assigned Automatically to learn how Membership uses roles to decide whether flowdown reaches a contact. When someone receives an institutional membership this way, their own contact record does not change. They can stay an individual contact and still hold the inherited membership, with eligibility controlled by the contact-role flowdown settings.
Flowdown depends on the contact being linked to an organization profile that still exists. If the organization record was deleted, or the contact was never linked to an organization, organization-level flowdown does not apply. If flowdown looks inconsistent, and some contacts in similar roles receive it while others do not, check whether the membership type's allowed-role list changed after some contacts were connected through another process, such as an application that assigned them directly. Removing a role that was added to the flowdown setup by mistake, and then reprocessing flowdown, usually corrects the issue.
Flowdown can also cascade to child organizations and then to their contacts, based on the parent-organization relationship in CRM. Your administrator can limit cascaded membership to certain organization types. Flowdown and cascading both stop after a set number of levels, so membership does not continue forever through a deep organization hierarchy.
The membership type's flowdown setup controls whether an organization's membership flows down, not the package it uses. Choosing a different package for a child organization does not, by itself, turn off or override flowdown from that membership type. For organization-to-organization flowdown to update cleanly at renewal, the parent and child should use the same membership package and type, and the child's own membership record should have its Origin set to Flowdown rather than Principal. If you manually set a different package or origin on a child organization that should inherit through the hierarchy, that conflicts with the flowdown setup and can cause a Parent Org ID validation error when you save. The same kind of error can appear when you build a flowdown or assigned membership by hand without giving it an organization. Every inherited membership has to name the organization it comes from, or Rhythm refuses the save.
A cascaded child organization's membership takes its type and package from the membership it currently inherits from, just as an individual's flowdown membership does. If cascading is turned off for a membership type, direct child organizations can still receive flowdown from the parent's own membership. Organizations farther down the hierarchy do not, because cascading is what lets flowdown travel more than one level. This changes who actually holds the membership, not just what a directory displays. Once child organizations are part of a cascading hierarchy, there is currently no way to exclude specific children from flowdown while leaving the rest of the hierarchy cascading normally. To stop child organizations from inheriting a membership class you no longer want them to have, turn off cascading flowdown on the membership type and reprocess flowdown for your account. This removes the inherited memberships from every affected child organization and its contacts until they go through their own process to receive the membership you want them to have. If two organizations are linked by membership flowdown incorrectly, or you want to manage and renew them separately, an administrator can edit each organization's own membership and change its Origin from Flowdown to Principal. Temporarily restoring a parent-organization relationship and then removing it again is not a reliable way to clear old flowdown-related fields from an earlier setup, especially when the organizations involved do not actually have membership records of their own.
When a child organization receives membership through flowdown, its Membership Info tab may show a Flowdown Information area that names the actual parent organization the membership comes from. It names the source organization, not the child organization itself, so you can see that the child's membership is inherited. That indicator, and the child's active-member status, depend on a flowdown membership record actually existing for the child. If that record is missing, the child can show as a non-member even when the hierarchy and setup otherwise qualify it. Reprocessing flowdown does not always recreate the record. If a parent organization's own Child Organizations tab fails to load, you may not be able to verify inherited membership on its children from that view. A newly created child organization that receives membership through cascading flowdown can also be difficult to delete while that flowdown relationship is in place.
People who inherit membership can receive a different membership type than the organization has, if your administrator set that up. They always inherit the organization's package. If your administrator has not configured a separate type for inherited memberships, those memberships display with the parent organization's membership type name. That label does not mean the inherited membership is independent; it is still the same inherited relationship.
Inherited memberships also stay in sync with the organization's custom field values, including chapter and section. When you change a value on the organization, Rhythm copies it to every inherited membership unless a staff member already changed that field by hand on the inherited record. For example, a chapter you set directly on a member's own membership is marked overridden, so Rhythm does not replace it with the organization's chapter the next time it syncs. Removing a value from the organization does not remove it from memberships that already inherited that value.
Rhythm tracks these changes automatically. It records which fields you changed directly on an inherited membership, whether the membership came from an organization through flowdown or from another parent membership, so it knows what not to overwrite. You can review and change which fields are treated as overridden in the inherited membership's Overridden Fields area. That area appears only when you view a membership whose origin is Flowdown; a Principal or Assigned membership does not show it. Overrides are not limited to chapter and section. Type, package, status, and add-ons can each be overridden the same way. When type, package, or status was overridden by hand, the membership does not reflect the organization's type, package, or status until you clear the override and let flowdown run again.
Add-ons follow the same rule, with one more condition. Reprocessing flowdown updates an add-on on a member's inherited membership only when that add-on already exists on the organization's own membership record, and only for contacts linked to that organization. An add-on a contact bought directly on their own membership does not flow down to other people connected to the same organization. Flowdown only reads what is already on the organization's record; it never starts from an individual contact's own purchase. Similarly, if a contact changes something on their own downstream membership, such as buying an add-on for themselves, that field becomes overridden on their record and stops following the organization's value for that field. Because these are separate override and precedence rules, flowdown does not by itself prevent someone from keeping their own chapter and section values. Whether the organization's values replace them depends on those same rules.
Add-on charging works differently depending on how people receive the membership. For a flowdown membership, an add-on purchased at the organization level is charged once and then distributed to related individuals through the flowdown rules above. For an assigned membership, add-ons stay on each individual's own membership and can be charged to that person separately at renewal, instead of being paid once at the organization level.
A flowdown membership's join date reflects when the parent organization's membership was created, not the individual's account creation or onboarding date. You cannot change that join date for a flowdown membership. If you need a separate field to record when a person first joined or created their own account, do not rely on the membership join date while flowdown is in use. A contact merge is expected to carry the original membership join date over to the surviving record.
When flowdown creates a brand-new membership for a contact who did not already have one, the new record can briefly carry the parent contact's own member number instead of a new number of its own. If a membership record already exists for that contact, flowdown updates it in place and keeps its existing member number. If you notice a duplicated or otherwise incorrect member number on a newly flowed-down membership, report it to Support. Moving a contact from an individual membership into an organization's membership with flowdown enabled can also clear that contact's chapter, chapter join date, and join date, including prior chapter history, unless those fields were already protected as overridden on the contact's own membership. Set them as overridden first if you need to preserve that history through the move.
A flowdown membership does not inherit the organization's own order-related balance or amount-due information. Rhythm does not copy the principal membership's balance onto every inherited record, because showing the organization's full balance on each person's membership could wrongly suggest that each individual owes the full amount. If you need to find members with an unpaid balance, and the membership might be a flowdown record, check the parent organization's own balance in addition to the member's own balance field.
If a contact already has their own active membership separate from the organization's membership, flowdown usually leaves that membership alone. Flowdown always replaces a contact's own inactive membership. Your account can also be set to prefer the organization's membership over a contact's own membership. When that preference is on and the organization's membership is active, flowdown takes over even if the contact already has their own active membership. When this happens, the contact's own membership record changes from an origin of Principal to Assigned or Flowdown as appropriate, and the details on their record refresh to reflect the organization's membership. Turning on this account-wide preference changes every affected contact's effective membership type and package to the organization's own, overriding whatever individual membership they already had, so confirm that is what you want before enabling it broadly.
Other parts of Rhythm rely on whether a contact currently has an inherited membership, so changes to flowdown setup or qualifying roles can change how that contact is treated elsewhere. That can affect event registration pricing or member-type reporting, not only Membership. Turning on Membership Flowdown for an organization's membership type is also what makes its contacts receive the membership type itself and any related confirmation email. Without it, contacts added through an organization membership process can be missing both, even though they are connected to the organization.
A contact's flowdown eligibility can also depend on fields elsewhere on their contact record. For example, if a related date-status field was not updated after an organization's membership application was processed, the contact can remain inactive until that field is corrected and flowdown is reprocessed. A change-affiliation or add-on process is also offered only to the membership holder category it was configured for. A contact with a flowdown membership may not see a change-affiliation or add-on process unless it is set up for Flowdown. If the organization really owns the membership as Principal, the process may need to be configured for Principal instead, even when a contact is acting on the organization's behalf.
Using a broad, organization-wide membership as a workaround for individual membership does not validate the email domain of someone who links themselves to the organization. If your linking process does not otherwise restrict this, someone with an unrelated email address could affiliate themselves with the organization and receive its group membership benefits. There is also no built-in way to drive a custom or calculated field on the organization record directly from a related contact's active membership package, such as populating an organization-level field when any linked contact holds a specific membership and clearing it when that membership lapses or the contact leaves.
If you need to trace why a flowdown outcome changed, your account's audit history can show when a membership type's flowdown or cascading settings were turned on or off. Compare that timing with the date a specific membership changed. Audit history can also show a membership package being reassigned more than once on the same record, which helps when an organization's member contacts unexpectedly lose recognition and the cause is not otherwise obvious.
As long as the parent organization keeps its own membership current, a person's flowdown membership renews with it on the organization's expiration cycle. The person does not pay separately or take any action for the inherited membership to continue. Organizations that use flowdown are renewed by renewing the organization's own membership. You do not need to submit a separate group application for each individual member the way you would for memberships that are not inherited.
A flowed-down membership also follows its source organization's renewal cycle for billing-run purposes. A billing run tied to the organization's expiration date picks up its flowed-down members, even if a dependent contact's own expiration date was changed by hand, because that manual change does not move the record into a different renewal cycle. If the organization's order was paid but not yet fully processed, flowed-down or assigned members' expiration dates may lag behind the organization's for a short time. Give order fulfillment a chance to finish before assuming flowdown is broken. If a contact's organization relationship, or a membership's own Origin, changes after an order has been processed but before it is paid, the resulting membership can stay linked to the original organization and order context, or end up recorded under an unexpected owner type, instead of moving cleanly with the new relationship.
Tip
If a contact's membership record does not show the membership you expect, check whether that membership type is set to flow down to their kind of contact, and whether they have one of the roles your administrator allowed. An organization with an active membership does not make its contacts members unless flowdown is turned on for that membership type. If you have confirmed the linkage, role, and flowdown setting and the record still has not updated, removing and re-adding the organization relationship, described below, or contacting Support are reasonable next steps.
Why a Contact Might Keep Benefits After Leaving
When someone no longer qualifies for an inherited membership, update their organization or role the usual way to withdraw it. Moving a contact from one organization to another updates their membership to match the new organization, as long as the new organization's own membership has flowdown enabled. If it does not, the contact's inherited membership ends.
When the organization relationship itself gave someone membership, removing that organization or role sets the membership inactive rather than deleting it. After this kind of change, Rhythm is also expected to stop showing that organization's flowdown banner on the contact. If a banner still names the old organization after the change, the display has not caught up; it does not mean the person is still receiving benefits. If the person had their own membership before inheriting the organization's membership, Rhythm restores that original membership instead of leaving them without coverage. The restored membership comes back active only if it is still within its own expiration window. It comes back inactive if it had already expired, had no end date, or did not exist at all.
A contact can still seem to keep membership benefits after you expected them to lose those benefits for a few reasons:
- If they have their own separate membership instead of an inherited one, removing them from the organization does not affect that separate membership. It stays active until you inactivate or terminate it directly, or it lapses through a billing run. Removing the organization relationship alone does not drop it. Even removing someone from an organization's roster in the Portal does not necessarily stop their benefits by itself. If their membership origin is Flowdown, the underlying organization relationship controls the membership, so it stays in effect until that relationship changes.
- Flowdown is checked again when you change a contact's organization or role the usual way, and when an organization's own parent or types change. A bulk import does not trigger that check for each contact individually. Instead, one flowdown pass runs across your account after the import finishes, which can create a delay before an imported batch's inherited memberships are correct. Removing an organization from an imported contact is expected to inactivate that contact's flowdown membership the same way it would for a contact who was not imported. Imported records can also leave old organization associations in downstream data even after the contact's organization changes in Rhythm. Membership records created from an import can have other rough edges. For example, an organization membership application processed for an imported organization has sometimes not carried the applicant contact onto the organization's own membership record, and a flowdown membership has sometimes not been removed correctly for a member whose organization record was imported. If flowdown looks wrong after an import, try running Reprocess Flowdown yourself, even though the process should already have run automatically.
- In the uncommon case that Rhythm does not withdraw an inherited membership, the person keeps it until the next change to their organization or role triggers a fresh check. A background fix for this kind of old membership corrects a record only the next time its organization or role changes, so a record already affected is not automatically repaired and may need a manual correction if you need it fixed sooner. Disconnecting a contact from an organization can also, in some cases, leave the membership recorded with an origin of Principal instead of properly ending it. Check the membership's own Origin and status after a disconnect if the result looks unexpected.
- Membership and flowdown-related access do not always update the instant you make a change. A newly added or reassigned contact may appear as a non-member for a short time, anywhere from a few minutes up to roughly an hour, before flowdown processing finishes and the correct status appears. Refreshing the page or returning to it later is often enough. The same kind of delay can affect Portal access. If a contact you just removed from a corporate association still shows as blocked from an individual-membership signup immediately afterward, that can also resolve itself shortly without any further change.
A few related administrative details are worth knowing. Removing a person from an organization does not send that person any notification. A contact cannot always be deleted while a membership or other organization-linked record still depends on them, so remove the membership connection from the contact's profile first. An unexpected corporate or flowdown membership you want to remove from a contact is not always available from the visible membership details area. Check the contact's own Options menu, which can offer a delete option the details view does not show. If a contact should show as a non-member after losing an organizational relationship, but an inactive flowdown membership is still showing on their record, deleting that membership directly from the contact's own record is a more direct way to get there than relying on removing the organization relationship alone.
If you are reassigning an existing company membership from one organization or contact context to another, changing the visible contact alone is not always enough. The membership record's own parent membership reference may also need to point to the correct organization membership, or the old contact and context can keep showing through. If a contact's inherited flowdown could not be stopped because the linked parent organization reference is invalid and errors when opened, edit the contact's CRM record to attach a valid organization, then remove it again. That can clear the broken association and let cleanup proceed.
When you clean up a batch of memberships tied to organization relationships, watch for exceptions. A mismatched expiration date between a contact and its organization, or a contact with an active membership under an inactive organization, needs individual review rather than one bulk correction. If a membership's renewal billing suddenly fails, a stale reference to a deleted or merged organization on the contact is one possible cause to check with Support. You can spot likely orphaned organization-type membership assignments by querying for memberships whose type requires an organization but whose organization field is blank. If a contact appears to have more than one active membership, such as their own membership plus what looks like a duplicate, check whether a separate, unrelated membership exists on an organization record connected to them. Removing that stray organization membership can resolve what looked like a duplicate.
Tip
If a contact who is already linked to the organization in CRM is not showing the membership you expect, or is missing from Member Contacts even though the relationship looks correct, removing them from the organization and adding them back can resynchronize the relationship, even though this is an uncommon case.
Tip
To check whether the people tied to an organization are current members, what membership type they hold, and when their membership expires, review the organization's own Member Contacts list or run a membership query filtered to that organization, rather than opening each contact's own record one at a time.
Flowdown only moves downward. An organization's membership can reach its contacts and child organizations, but a child organization's membership does not pass back up to its parent. If only a child organization buys a membership, the parent organization receives nothing from that purchase. For a contact to receive benefits through flowdown, the organization itself must hold the qualifying membership, whether it bought that membership directly or received it through cascading flowdown from its own parent. If the organization does not hold the membership at all, its contacts have nothing to inherit, and the organization needs to apply for the membership before flowdown to its people can begin.
Billing can move in the opposite direction from flowdown. Your account can bill a parent organization for a child organization's invoice, even though a child organization cannot be billed for its parent's invoice. Members of a child organization also do not need cascading flowdown turned on to bill their parent organization. That billing relationship does not depend on flowdown being configured.
When a child organization buys or renews a membership package through your online store, eligibility is expected to be evaluated against the organization actually receiving the membership, not a parent or billing organization also involved in the order. If a purchase for a child organization is unexpectedly refused as ineligible while a separate eligibility test for that same organization reports it as eligible, report that mismatch to Support.
Purchase eligibility criteria have a related option for contacts: For contacts, apply this rule to the organization to which the contact belongs. When this is checked, a contact's eligibility for the rule's product is evaluated against their organization's Organization Membership member type rather than against the contact's own membership. Use this when you want a contact to qualify for a purchase because their organization holds the qualifying membership, even if the contact does not hold it individually.
Organization Contacts and Member Contacts
Your CRM organization contacts and Membership's member contacts are two different lists, built from two different relationships. Organization contacts are anyone currently linked to the organization on their own CRM record. Member contacts are the people who actually receive the organization's membership, whether by flowdown or by an assigned seat, because they were connected to it during application processing or seat assignment.
A person can appear on either list without appearing on the other. Someone linked to the organization in CRM who does not qualify for flowdown and was never assigned a seat appears only as an organization contact. Someone who was assigned a seat or received flowdown and later left the organization in CRM can remain on the membership's member-contacts list until you remove them there directly, because removing a CRM link does not automatically clean up the membership side. The console's list of an organization's corporate member contacts works the same way. It reflects the organization affiliation recorded on each contact's own CRM record, so removing someone from the membership alone, without also removing the organization from their CRM record, does not remove them from that list.
Removing a contact from the organization is expected to remove them from that organization's member contacts list at the same time, rather than leaving an old entry behind. If you need to correct many contacts linked to the wrong organization, the reliable path is to remove the incorrect memberships in bulk and then re-link or merge the affected records. Rhythm does not automatically reconcile a contact-to-organization mismatch while preserving the memberships involved.
This distinction matters for Portal access, too. The Portal recognizes someone as a member of the organization only when the membership appears on that person's own contact record. Being listed as a member contact on the organization's membership, or being linked to the organization in CRM, is not enough by itself. If a contact appears as a member contact on the organization's membership but the membership is missing or blank on their own record, the Portal treats them as a non-member and blocks members-only content, even though the Console shows them as assigned. Compare the contact's own membership record with the organization's membership record to tell the two apart. Restoring the connection on the contact's own record restores Portal access, including confirming that the membership record actually names that contact, since a blank or deleted contact reference on the membership prevents access even when CRM shows the relationship.
Similarly, the Portal's display of an organization's contacts depends on the organization's own list of assigned contacts, not just on whether a membership record looks assigned in the Console. If that organization-level list is empty, the Portal can show no organizational contacts even when Console records show assignments. This is common with imported records, where member contacts can be marked assigned without the organization-level linkage the Portal display needs.
A person's status in the Portal's organization contacts area follows their membership record's active or inactive status, not their CRM contact record's active or inactive status. Making a CRM contact record inactive, or marking it deceased, does not by itself inactivate that person's membership or remove them from an organization's member contacts list. You need to separately mark the membership inactive and remove the person from the member contacts list if you want both to happen, because Membership does not link contact-record status and membership status automatically.
Membership Origin: Principal, Flowdown, and Assigned
Every membership records where it came from in a field called Origin, and you can change that field when you edit a membership. Principal means the membership belongs directly to the person or organization and is not controlled by an organization relationship. This is what an individual membership normally is. Flowdown means the membership was inherited from an organization's membership based on the contact's relationship to that organization, as described above. Assigned means the organization's package explicitly gave the membership to a named contact through a seat, as described below.
Origin is not just a label. Downstream processes and reports rely on it. A query for currently active memberships checks the Origin field, so an organization-linked contact who should receive flowdown but is still recorded with an origin of Principal will not appear in those results until the origin is corrected and flowdown runs again. A membership assigned as a seat keeps an origin of Assigned in your reports, which is different from a membership someone applied for or bought on their own.
Origin can also outlive the relationship that created it. Unlinking a contact from an organization does not, by itself, remove a membership whose origin is Assigned. You still need to remove that person from the organization's seat list or membership record directly. When a contact who previously held their own membership is added to an organization's membership through an application, their origin can remain at its prior value, such as Principal, instead of changing to Assigned. When that happens, the organization's own dates can advance at renewal while that person's individual membership information does not update the way an ordinary flowdown or assigned membership would. Correcting the origin resolves the mismatch.
In a membership structure where organizations are expected to own their own memberships, an individual contact holding a Principal membership instead of receiving it through the organization is usually a sign the record should be corrected. Terminate the incorrect individual membership so the person receives benefits through the organization instead. Each organization, including child organizations, should hold its own Principal membership rather than an individual contact holding it on the organization's behalf.
If someone should no longer be tied to a parent or corporate membership, such as when a former flowdown member needs to renew or apply for an individual membership, an administrator can manually change that membership's Origin to Principal. This detaches it from the organization relationship immediately. It does not change the parent membership's own record. You can make this change one membership at a time by editing it, or use a mass update to correct many membership records at once. A mass update is useful when a group of members ended up Assigned or Flowdown when they should not have, or the reverse.
A membership with an Assigned or Flowdown origin is also tied to the organization for Portal self-service. A contact in that state may not be able to renew it from the Portal the way they could renew a Principal membership of their own, even if their contact role otherwise lets them manage organization tasks. Their own record can stay connected to the parent or corporate membership in a way that blocks the Join/Renew flow. Changing the origin to Principal, as described above, lets that person renew or join independently, but it also detaches the membership from the organization going forward.
Assigned Seats: By Name
Separately from flowdown, an organization's package can include a fixed number of seats, and the organization can name specific contacts to fill them. Each contact on the seat list receives their own copy of the organization's membership. If a seat holder named on an application does not already exist as a contact in your account, Rhythm creates one from the information provided. Membership packages bought through your online store work the same way. Buying a membership for an organization through the store is a different process from using the standard join application, but it can still assign the purchased membership to multiple people within the organization, the same as an application with named seat holders. Whether an application requires you to name assigned contacts before you submit it depends on how your association configured that application's form. Membership itself does not require an organizational application to include assigned contacts unless the form's validation requires them.
Seat holders move forward with the organization's membership. When the organization renews or its order is paid, the seat holders' memberships advance with it, keeping their expiration dates aligned with the organization's term. That alignment applies to everyone currently assigned to the seat list, including someone added after the organization's original order or assigned by hand rather than through an application. This depends on the order being processed in the organization's own context. For a group membership, the seat holder marked as the Ship-to recipient on the order is the one whose membership reliably advances, so process the group's application and order at the organization level to make sure every assigned membership updates correctly. An assigned membership can also continue to show on the organization's membership while a renewal invoice for it is still outstanding, if the reassignment was not reflected before that invoice was created. It should clear once the invoice is paid. If your organization's contact or organization relationship changes after a membership order has been processed but before it is paid, the resulting membership can stay linked to the original organization and order context instead of moving with the new relationship.
If your organization buys additional seats through a seat add-on, the number of available seats increases for that term. That extra count does not carry forward automatically. The next time the membership joins or renews, the seat count resets to whatever the package currently includes, so you need to purchase the add-on again if you still need those seats. A seat you bought this way can still be reassigned to a different person during the same active term without buying the add-on again, as long as your active assigned-member count does not exceed the total number of seats you bought. Rhythm compares your active assigned contacts against that total seats-purchased figure, not only against the package's own built-in contact limit, so a seat you paid extra for stays usable for a replacement member even after the person who originally filled it is removed.
The renewal package matters here too. If your organization joined under one package and renews into a different one, give that renewal package the same maximum-contacts setting and add-on product as the original. A renewal package with no organization membership settings of its own can mishandle pricing for a membership that already has assigned contacts, so check this whenever you set up or change a package used for organizational renewals.
When you change the seat list, either at renewal or any other time the organization's membership is saved, Rhythm updates each seat to match. A newly named seat holder receives the membership, and someone removed from the list loses the seat's membership. If that person separately has their own membership, Rhythm leaves it alone. Changing a contact's own individual membership record, such as replacing it with a different type, does not by itself remove that person from a company membership's assigned-member list. The two relationships are updated separately, so remove the person from the organization's seat list directly if you need the assignment gone. Even after a removed member correctly drops out of the assigned-member count, that same contact can sometimes still appear in the Assigned Contacts list while you edit the organization's membership. That is a separate, unresolved display issue; the count itself is correct even if the list briefly is not.
Membership Flowdown and assigned seats are independent settings. Turning both on for the same membership type can let more people receive benefits than the package's seat maximum alone would suggest, because flowdown grants membership by role while the seat count grants it by name. You do not need to use the seat chooser for contacts covered by flowdown. Once flowdown is configured for the membership type, those contacts receive the membership automatically without being named as a seat.
An organization membership's application processing can also assign memberships to a list of contacts directly, giving those memberships an origin of Assigned rather than Flowdown. If you want an organization's membership to reach its people entirely through flowdown, process the organization's own membership without naming assigned contacts on the application, and let flowdown create those memberships instead. Removing assigned-contact components from your remaining application forms lets those members flow down as well. If your account later turns off flowdown for an organizational membership type, individuals who received that type only through flowdown lose it. They drop out of queries and invoicing built on that membership type, and only contacts explicitly on the seat list keep an organization-based membership from that type. If no one was named on the renewal application, the organization's membership can end up with no member contacts connected to it at all.
Manually assign a contact to an organization's membership from the organization's own membership record, in its Assigned Member Contact section, or from the Manage Member Contacts page using Add to Membership. Both put the person on the seat list the same way an application would. When you enter someone on an organization's renewal application who was not already a seat holder, Rhythm creates their contact record if needed and adds them to the seat list, the same as at Join. Leaving a previously active seat holder off the renewal removes their seat's membership, just as removing them from the list would at any other time. Adding a contact to an organization's membership through a change-affiliation request is expected to add them to the organization's Member Contacts list and update their own membership record the same as any other assigned seat. If the person replacing a departing seat holder does not already have a current membership of their own, process the institutional membership for that person directly and then terminate the record for the person they are replacing.
Replacing one assigned member with another during an active term is not meant to create a new charge, even when the organization is already using its included free seats. If a warning about a charge appears during the substitution, the charge itself should not actually be applied. Making this substitution from the Portal's Manage Member Contacts page does not always work the way it does in the Console. Removing the current assigned member there and adding a replacement can behave unexpectedly, so if a portal substitution does not go through cleanly, complete it from the Console instead.
The distinction that matters here is reassignment versus growth. Swapping a replacement person into a seat you already paid for should not add a fee. Increasing the number of active assigned members beyond the total seats you have already purchased should add a fee, typically through the add-on product configured for extra contacts. If a charge shows up on a simple swap, or no charge shows up when your organization is genuinely adding people beyond its purchased seats, check which of these two cases actually happened before assuming the pricing is wrong.
Tip
For organizational memberships, using a base contact allowance together with an add-on product for extra contacts is generally a cleaner way to manage how many people an organization's membership covers, rather than building a separate, more complicated package structure for every allowance you want to offer.
An assigned seat can also fail to appear correctly if the same contact already has an unrelated membership record of their own. Setting that prior membership inactive and letting Membership refresh can allow the assigned seat to display correctly on the organization's membership and in reports. If a contact listed as an assigned member contact does not show the membership correctly on their own record, or has already left the organization but still appears on the seat list, remove that person from the organization's membership and add them back. You can also save the organization's membership again without changing the list. Either action recalculates every seat and usually clears the problem. The same recalculation can fix a case where a contact was assigned but the assignment had not fully carried through to the membership record yet, which can otherwise leave a membership showing no contacts until you save it again. The same kind of gap is why a mass update that simply resaves a batch of organization memberships is sometimes used to correct many records at once.
An organization's used-seat count can include people who are not linked to the organization as contacts in CRM, because a seat is assigned directly to a contact rather than through the CRM relationship. Do not assume the organization's visible list of linked contacts fully explains its seat usage. If assigned seats and visible organization contacts do not match, check how the people involved were originally connected to the organization, such as through a membership package, an import, a mass update, or another process. The assignment method affects how you correct a mismatch. A contact who was imported and is related to an organization with an active organizational membership is not automatically treated as an assigned member unless a membership record actually connects them. Being related to the organization is not enough by itself. An inactive assigned member does not count against the organization's included seat allotment, so inactive assigned members do not consume the package's free included seats when you add another member.
The Portal's Manage Membership Contacts view for a group package can show your assigned-member count compared with the package's free included seats rather than the total number of seats you bought. Because of that, the number shown there may look lower than your organization's actual purchased capacity. Check your organization's total purchased seats in the Console if the portal count looks wrong.
A membership type or package configured for organizations only cannot be selected or reassigned directly on an individual contact's own membership record. You need to make that change through the organization's membership instead. If you try to change a contact's membership type directly while they should receive it through their organization, only unrelated types, such as an honorary type, may be available. You may also be unable to remove one you selected by mistake. Update the organization's membership or the contact's flowdown eligibility instead of editing the contact's membership type directly. If a contact linked to a parent organization is not recognized as part of the organization's group the way its other contacts are, check whether that person's own membership type matches the type the rest of the group uses. Changing it to match can resolve access issues tied to that mismatch.
Checking Do Not Renew on an organization's own membership does not check it on the memberships of contacts who receive that membership by flowdown or assignment. Those related records do not own the membership, so their own Do Not Renew checkbox is unaffected. The organization's renewal status controls whether they are renewed or eventually dropped. When an organization's own membership is dropped, its assigned members' memberships are dropped along with it, the same as flowdown memberships.
A person who begins as an individual, free contact cannot switch themselves into an organization's corporate membership on their own. They need to be connected to an organization that buys the corporate membership, and that purchase is handled from the Console. Group memberships built on an organization's flowdown assignment can also depend on chapter affiliation flowing along with the assignment. If the organization has no chapter of its own, assigning someone to its group membership can clear that member's existing chapter affiliation.
Automatic renewal is independent between an organization and the people who receive its membership by flowdown. Turning on auto-renew from an individual's own membership view does not turn on auto-renew for the organization's membership, and the two can legitimately show different settings. Occasionally, an assigned contact's membership does not update as consistently as expected after the organization's invoice is paid or its seat list changes. If that happens for only some of an organization's contacts, resaving the organization's membership, or asking Support to help retrigger the update, usually resolves it.
Related
For what changes on a membership record after the related order is paid, see How Buying or Renewing a Membership Package Updates Your Record. For how the price of chapters, sections, add-ons, and seats is built into that order, see How an Application's Order Is Priced. To correct a membership's fields, including its Origin and Overridden Fields, by hand, see Create, Correct, and Activate a Membership by Hand. To see everyone an organization's membership reaches, see Search, View, and Print a Membership. To recalculate flowdown for every organization after a configuration change or an import, see Run Membership Maintenance Tasks.