Drupal case study · 06

Member Referrals and Recognition

A guided referral journey that helped community members make introductions, track progress, and recognize meaningful participation.

Problem
Member introductions, including referrals to people outside the community, were disappearing into email with no clear way to follow what happened next.
Built
A guided referral workflow with participant-specific views, automated follow-up messages, and Activity Points that rewarded meaningful milestones such as qualified leads.
Result
Members could follow referrals from introduction to outcome and receive recognition for meaningful participation, while administrators could adjust the reward rules.
  • Content Entities
  • Config Entities
  • Form API
  • Plugin API
  • Events
  • Access API
  • Views
  • Cache API

Why we built it

In a business-networking community that ran for six years, members needed a clear way to make an introduction, whether to another member or to someone outside the community, hand it to the right person, and see what happened next. Without that structure, valuable referrals disappeared into private email threads and neither participant had a dependable history.

We added a guided referral journey and connected meaningful milestones to a reusable recognition system. The goal was not to reward clicks or raw activity. It was to recognize participation that moved a relationship forward while giving members and staff a shared view of the work.

My role

I designed and built the referral entity and lifecycle service, the guided forms and participant-specific form modes, the access checker, personal Views, notifications, and the events emitted as referrals changed state.

I also helped shape the activity-points framework that translated those events into configurable recognition. Other developers and stakeholders worked with me on the surrounding product experience.

What it unlocked

Members gained a visible path from introduction to outcome instead of losing referrals in email. Automated reminders helped prompt the next action, and recognition gave members another reason to follow through.

Qualified referrals could earn greater recognition than simply creating one, while staff retained control over the rules, award history, and reporting.

What we added to the platform

A referral content entity held each introduction and its changing runtime history. Referral-type config entities described deployable variations without turning every type into custom code. Purpose-specific form modes let the sender, recipient, and staff see the fields and actions appropriate to their part of the journey.

A dedicated access checker evaluated both the requested operation and the current user’s relationship to that specific referral. The lifecycle service compared previous and current state and dispatched named Drupal events only for meaningful transitions. Personal Views separated referrals a member sent, received, or still needed to act on. The referral lifecycle emitted meaningful events, while the recognition engine handled shared mechanics such as rules, duplicate prevention, and persistence.

How recognition worked

When a referral reached a configured milestone, an event subscriber asked the activity-points service to evaluate an award. The relevant event plugin supplied the activity label, the category of points, a stable duplicate-prevention key, and the limited context it stores. Administrators controlled enabled rules and base values through config entities rather than requiring a deployment for every adjustment.

Optional modifier plugins could adjust a rule using referral context. Each modifier was isolated so one failure did not have to block the entire award. Before saving, the manager checked the stable key for an existing user-and-event record and ignored duplicate or non-positive results. A successful award became a content entity, refreshed the member’s totals, and appeared through Views and a cache-aware user block.

Drupal under the hood

Content and Config Entity APIs
Separated runtime referrals and award history from deployable referral types, point categories, and recognition rules.
Form API and form modes
Supported a guided journey with different responsibilities for senders, recipients, and staff.
Plugin API, services, and events
Kept feature-specific meaning in event and modifier plugins while the generic engine handled calculation and persistence.
Access API, Views, Mail API, and Cache API
Protected participant actions and powered personal work lists, notifications, histories, totals, and reusable presentation.

Why I chose this approach

I chose to treat referrals as a real interaction inside the community rather than simply giving members a form for sending someone’s contact information.

We needed to track introductions between members, including referrals to people outside the community, and give both sides a way to follow what happened next.

We also wanted to encourage members to use the feature, so we connected referral milestones to our Activity Points system. Members could earn points for making referrals and earn more when those referrals became qualified leads or moved forward. Automated emails reminded people when there was another action they could take.

The goal was to make valuable participation visible and rewarding: make the introduction, follow through, record what happened, and receive recognition for contributing to the community. Because Activity Points was built as a reusable system, we could use the same approach to recognize other kinds of participation later.