Drupal case study · 05

Business Networking Referrals and Recognition

A business networking community needed a better way for members to exchange referrals, track introductions, and follow up on potential opportunities. I developed a Drupal referral system that guided members through each referral, tracked its progress, sent follow-up notifications, and recognized meaningful participation through configurable Activity Points.

Organization: A business networking community whose members made introductions to one another and to people outside the community.
Need: Member introductions were disappearing into email with no clear way to follow what happened next.
Solution: 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.
My role: Designed and built the referral workflow, participant access, notifications, and lifecycle events, and helped shape the Activity Points framework.

The challenge

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 of the introduction or its outcome.

The solution

We added a guided referral journey to the community. Senders, recipients, and staff each saw the fields and actions appropriate to their part of a referral, automated emails prompted the next step, and members could see the referrals they had sent, received, or still needed to act on.

Meaningful milestones were connected to a reusable recognition system, Activity Points. 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.

Results and capabilities

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. Because Activity Points was built as a reusable system, the same approach could recognize other kinds of participation later.

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.

Technical implementation

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. Modeling each referral as an entity with its own lifecycle meant both sides could follow it, access could depend on each person’s relationship to that specific referral, and every meaningful change could be announced as an event.

Keeping recognition separate from referrals was the other key decision. The referral lifecycle only announced what happened; the Activity Points engine decided what that was worth, prevented duplicate awards, and stored the result. Members could earn points for making referrals and earn more when those referrals became qualified leads or moved forward, and the same engine could recognize other kinds of participation without changes to the referral code.