Association Membership Portals: Who Receives Benefits Through Another Member?

When an association sells an organisation membership, decide which people may receive benefits through it. The payer, the primary member and the people entitled to participate can be different contacts. A portal needs to explain that relationship instead of treating everyone with the same email domain as a member.

The commissioning decision is whether membership benefits derive from a particular qualifying relationship and how that relationship is maintained. This is not the same as buying software seats or inviting a colleague to administer an account. Do not assume that someone entitled to attend a member event may also inspect the organisation's invoices or change its subscription.

Start with the primary member and the eligible relationship

Imagine a fictional trade association that accepts a business as its primary member and allows designated employees to receive selected benefits. Write down which relationship qualifies, who confirms it and which benefits actually follow. A shared postal address, email suffix or billing contact is not enough on its own to establish the agreed relationship.

The official CiviCRM membership-definition guide describes inherited membership. Its example is a professional trade organisation whose company members pass benefits to employees. The membership type can specify a relationship type along which membership is inherited.

That is a useful model, not evidence that your particular association must use employment as its criterion. Have the responsible association staff approve the rules. Avoid collecting unnecessary personal evidence merely because a portal can upload it; agree what is needed and who may view it.

Specify the allowance, not just the membership label

CiviCRM also documents a “Max related” setting that limits inherited memberships linked to a primary member. If your offer has an allowance, specify what uses a place. Is it an approved related person, an outstanding nomination or another defined population? Tell the administrator which places are occupied and which requests still need review.

For a custom implementation, agree how competing nominations are handled when the allowance is full. Do not silently replace an existing beneficiary or sell an additional membership. These controls are proposed requirements, not behaviour demonstrated by this article in a running CiviCRM installation.

Explain the allowance on the offer page before someone buys. Do not describe a company membership as covering every employee if the actual agreed arrangement restricts the number or the eligible group.

Decide what a changed relationship affects

An employee may leave while the company remains a member. Conversely, the company membership may end while the person's contact record remains useful for legitimate follow-up. Specify who records either change and which benefits must be reconsidered.

Ask the developer to preserve the reason and effective date for a change without deleting unrelated personal history. Decide whether a future event booking needs staff review when the relationship ends. Do not automatically rewrite a past attendance record or cancel an independent personal membership merely because an inherited benefit changed.

The cited relationship configuration does not establish all these transition rules. They belong in your association's approved policy and the implementation brief. In particular, do not promise that every connected system instantly withdraws access without testing the actual integration.

Keep benefit access separate from account administration

Show staff why a person receives membership benefits: the primary membership, qualifying relationship and reviewed status. Separately control who may manage nominations, see payment records or change the primary member's details. A beneficiary should not acquire those administrative permissions merely by appearing in the member list.

Use the existing portal invitation workflow when people need accounts. Account acceptance establishes neither a qualifying association relationship nor a right to all member benefits by itself.

Demonstrate a complete relationship change

Use fictional contacts in the acceptance criteria. Include a valid employee, an unrelated person with a similar email address, a full allowance, a departing employee and someone who also holds an independent membership. Inspect the benefit explanation and permissions after each change.

Bring the approved eligibility rules and a blank nomination example to a membership-portal discussion. The result should be an understandable chain of entitlement, not a contact list with a membership badge. No real membership, access change or association policy assessment was performed for this guide.