Skip to main content

Proposing Big-Little relationships

Members can propose their own Big-Little pairings, but officers do it more often — adding pledges who aren't using the app yet, recording crossings retroactively, and stitching the family tree back together after a long-dormant chapter comes back online. This page covers the officer-side proposal flow, who can be a Big, and how the multi-tier approval cascade differs depending on whether you are proposing for yourself or someone else.

This is distinct from the member-add request — that flow brings a new person onto the platform. Big-Little proposing operates on people who are already members; you are recording a lineage relationship between two existing memberships.

What you see​

The proposal entry point lives on the Family tree page. From your sidebar: Family Tree (or under the Members group, depending on your sidebar layout). The page renders an interactive tree visualization of every recorded Big-Little relationship in your organization, with member cards as nodes.

To propose a new pairing, you typically:

  1. Open the proposed Little's member detail page (or open Family Tree and click on their node).
  2. Click Propose Big (or a similarly labeled action — exact wording depends on your build).
  3. A form opens asking for the proposed Big (a typeahead member search across your org), an optional justification text, and a confirmation step.

The form behaves slightly differently depending on who you are and who you are proposing for:

  • Proposing for yourself. The form pre-fills you as the Little; you only pick a proposed Big.
  • Proposing on behalf of another member. The form lets you pick both the Little and the Big. Only officers and admins see this two-field version — regular members can only propose for themselves.

Family tree page with the Propose Big dialog open and a member typeahead. Family tree page with the Propose Big dialog open and a member typeahead.

Who can be a Big​

The system enforces a few rules at submission time. A proposed Big must:

  • Be a member of the same organization as the Little. Cross-org pairings are blocked by the API.
  • Be different from the Little. The system rejects "make me my own big" with a clear error.
  • Not already be a descendant of the Little in the family tree. If your proposed Big is somewhere in the Little's subtree (their little, their little's little, and so on), accepting the pairing would create a cycle, and the system refuses with "This would create a cycle in the family tree."

A proposed Big does not have to be in your specific chapter — cross-chapter pairings are allowed as long as both members belong to the same org. They also do not have to have an Active membership status; an Inactive or Alumni Big is permitted (which is common when you are recording historical lineage).

There is no minimum length of membership, no requirement that the Big has crossed before the Little crossed, and no class-year check — those are policy concerns your chapter handles outside the platform.

Step-by-step: proposing on behalf of a member​

  1. Open the proposed Little's member detail page.
  2. Click Propose Big in their profile sidebar.
  3. In the form, use the typeahead to find the proposed Big. Start typing the name; the dropdown shows matching members in your org.
  4. (Optional) Enter a justification — useful context for the reviewer at the next tier ("Replacing a crossed-out relationship; original Big graduated 2024" works well).
  5. Submit.

What happens next depends on whether you are proposing for yourself or someone else.

Officer on-behalf-of: auto-approved​

When you propose a pairing for someone other than yourself, the request is auto-approved at submission. The Big-Little relationship is set on the Little's profile immediately, the family tree updates, and the request appears on the approvals queue with you marked as both requester and reviewer. There is no waiting period.

This is the most common officer use case — recording a pairing that already happened in real life so the platform's family tree reflects it.

Officer self-request: escalates one tier above your role​

When you propose your own Big as an officer, the request does not stay at the chapter tier. The system escalates self-requests one tier above the requester's role, on the principle that you should not review your own request. So:

  • A regular member's self-request → enters at chapter tier (officers/admins review).
  • An officer's self-request → enters at regional tier (regional admins or org admins review). If your chapter has no region, it enters at the org tier.
  • A regional admin's self-request → enters at org tier (org admins review).
  • An org admin's self-request → auto-approved (they sit at the top of the cascade).

For more detail on what each tier does and why this escalation exists, see The approvals queue.

What the proposed parties see​

When you submit a request that is not auto-approved (so any self-request or a member's self-request), notifications fire to the affected members:

  • The Little (the member the request is for) receives an in-app notification — "Big/Little Request Submitted: Your request to set [Big] as your big has been submitted for review." The target URL points to their My Approvals page where they can see the request and its current status.
  • The proposed Big does not receive a notification at submission — only when the request is approved. At approval time, both the Little and the Big are notified.

A pending request also surfaces on the Little's member detail page so subsequent reviewers see context. You will also see your own pending requests on your member surfaces (if you propose for yourself, the request shows up in your My Approvals).

What admins see that you don't​

National admins see every pending Big-Little request across every chapter in the org, regardless of tier. They can approve at any tier — and when they approve at a lower tier, the request auto-cascades through all remaining tiers in one step (so an org admin clicking Approve on a pending_chapter request finalizes it immediately).

Regional admins see Big-Little requests for chapters in their region. They act at the regional tier and can also act at the chapter tier (regional admin is in scope for chapter-tier reviews).

Officers see only their own chapter's queue. You cannot see pending requests for other chapters, even within your region.

Errors and edge cases​

  • "A pending big/little request already exists for this member." A member can have only one open request at a time. The previous one has to be approved or rejected before a new one can be submitted. If you are stuck, find the existing request in the approvals queue and resolve it first.
  • "This would create a cycle in the family tree." The proposed Big is already a descendant of the Little. The cycle check runs both at submission and again at approval, so a stale page won't slip through. Pick a different Big who isn't in the Little's subtree.
  • "Only officers or admins can assign big on behalf of a member." A regular member tried to propose a pairing for somebody else. Only officers, regional admins, and org admins can do this — and you can do it for any member in your org.
  • "Member is not in this organization." / "Proposed big is not in this organization." Cross-org pairings are blocked. Both parties must belong to the same org.
  • "A member cannot be their own big." Self-explanatory — and yes, the system enforces it.
  • "You do not have permission to review this request at its current tier." This appears on the review side, not the proposal side. The request has advanced past your tier; the next reviewer needs to act.
  • "You cannot approve your own request." Even if you have role permission at the request's current tier, the requester is never allowed to approve their own request. This is why officer self-requests escalate.

Mobile differences​

The Family Tree visualization is interactive on tablet and degrades gracefully on phones (the tree can be panned and zoomed; for very large trees, a list view may be more practical on a small screen). The propose-Big dialog opens as a full-screen modal on phones. The member typeahead works the same way as on desktop, with on-the-fly results as you type. Notifications about new requests come through the in-app bell and (if push is enabled) via native push.

Troubleshooting​

  • The typeahead is empty for a member I know exists. Confirm they have an active or alumni-status membership in your org. Members with the PNM status are not eligible Bigs (they have not crossed yet) and won't appear. Members in the Inactive status may also be filtered depending on your org's directory configuration.
  • I proposed a pairing on behalf of a pledge and the family tree didn't update. On-behalf-of proposals by officers are auto-approved — the relationship is set immediately. Refresh the family tree page; if it still doesn't show, confirm the member's profile actually has big_brother populated by visiting their detail page.
  • My self-request never reached the chapter tier. Correct — officer self-requests escalate one tier up. Your request is at pending_regional (or pending_org if your chapter has no region). Ask your regional admin to review it.
  • A request shows as Approved on the queue but the family tree still shows the old Big. Hard-refresh the tree page. The relationship is set on save; the visualization caches for a few seconds.
  • You want to undo an auto-approved pairing. Officers cannot reverse an approval through the proposal flow. Ask your org admin — they can edit the big_brother field directly on the member's profile.

Last verified against v0.62.1 (2026-05-11).