# Feature flag rollback referral brief template | SourceX

Canonical: https://refer.sourcex.si/resources/feature-flag-incident-rollback-referral-brief-template
Last updated: 2026-10-20

A company introduction about feature flag rollback records is one page of metadata the engineering director can forward unchanged: company size, the flag and incident systems, years of history, rough record volumes, who owns the records, who can authorize a discussion, the real access deadline and the one open question. It holds no incident text, screenshots or exports. Fill in the template below with the director, check it against the eligibility criteria, then send it to the decision-maker.

This template is part of the [feature flag incident rollback guide](/guides/workflow-feature-flag-incident-rollback). Its single job is the handoff: turning what you learned about a client's rollback history into a short, accurate note that a CEO can act on.

## The blank brief: nine fields, metadata only

Copy the field names and fill each one with a short answer. Every field asks for a description or a count, never a record.

| Field | What to write | Where the answer comes from |
|---|---|---|
| 1. Company and sector | One line, no customer names | You, confirmed by the director |
| 2. Full-time headcount at peak | A number; contractors excluded | HR or the CFO |
| 3. Business task the records show | One sentence on the decision being made | Engineering director |
| 4. Systems | Flag platform, incident platform, chat, postmortem store | Engineering director or admins |
| 5. Years of history | First and last year for each system | Platform admins |
| 6. Record volumes | Rough yearly counts of flag changes, incidents and postmortems | Admins, labeled as estimates |
| 7. Record owner | The company, plus any customer or vendor terms flagged | Legal or the director |
| 8. Authorized contact | Name of the CEO, who can authorize a discussion | Engineering director |
| 9. Deadline and open question | The written access deadline and the one thing nobody knows yet | Engineering director |

Two notes on filling it in. For field 5, ask what the flag platform's history actually holds: LaunchDarkly's change history, for example, records changes per environment with the member, resource, environment, date and a diff, filterable by project, environment and action. Homegrown systems vary widely. For field 6, the incident platform is often the easiest count; PagerDuty gives each incident a timeline with timestamps for each status, the actions taken and the notifications sent, so incident totals by year are usually quick to produce.

## A completed brief (Illustrative)

Illustrative. Every value below is fictional and shows the level of detail that works.

| Field | Entry |
|---|---|
| 1. Company and sector | B2B scheduling software for clinics and gyms, sold by subscription |
| 2. Full-time headcount at peak | 380 |
| 3. Business task | Deciding how far to roll back a release during an incident, applying the change and confirming recovery |
| 4. Systems | Commercial flag platform since 2019; incident platform since 2018; team chat; postmortems in the engineering wiki |
| 5. Years of history | Flag changes 2019 to now; incidents 2018 to now; postmortems consistently from 2021 |
| 6. Record volumes | About 9,000 flag changes a year; about 300 incidents a year, roughly 60 resolved by a flag change; about 45 postmortems a year (estimates) |
| 7. Record owner | The company; customer contracts mention operational data, flagged for legal |
| 8. Authorized contact | CEO, with the CTO supporting |
| 9. Deadline and open question | The flag platform contract ends at cutover on a documented date; unknown whether its full change history can be exported before then |

What the completed brief leaves out is as important as what it includes: no incident titles, no customer names, no screenshots of the flag platform, no sample exports. The open question names the one thing that could change the decision: whether the old platform's full change history, including which customer cohort each partial rollback touched, can still be exported before cutover.

## How to fill each field without handling records

- **Ask for counts, not examples.** "Roughly how many incidents a year were resolved by a flag change?" rather than "can you show me one?"
- **Use the director's words for the task.** Field 3 should describe the decision the records capture, not a technology.
- **Write "unknown" when it is unknown.** An honest gap in field 6 or 9 is better than a guess presented as fact.
- **Let the director correct it.** The brief goes out under their name, so they should be comfortable forwarding it unchanged.

The [rollback system map](/guides/feature-flag-incident-rollback-records-across-systems) helps with fields 4 and 5, and the [retention timeline](/guides/preserve-feature-flag-incident-rollback-records) helps with field 9.

## Checking the brief against the eligibility criteria

Before sending, confirm four points. The company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. The [company fit checker](/tools/company-fit-checker) runs the same test.

Partners sign the Channel Partner Agreement before submitting introductions. The first valid introduction within the 90-day window is credited when the company submits a verified application. Unknown until SourceX reviews it: buyer interest in this record type, how customer names are treated, the rights review result and any offer.

For the first message to the decision-maker, the [warm introduction brief](/resources/a-warm-introduction-brief-for-a-business-owner) gives a short cover note. The [software engineering workflows page](/data-types/software-engineering-workflows) describes the wider record family the brief belongs to.

## How the reward relates to the company's payment

The company is paid under its own agreement with SourceX. Rewards are a share of the compensation SourceX actually pays the company you referred (the Actual Supplier Payout), up to $100,000 per referred company, subject to the program terms. SourceX pays rewards separately; they never reduce the company's payout. Illustrative only: a $120,000 Actual Supplier Payout to the company would mean a $30,000 reward, and a $400,000 payout would reach the $100,000 cap, which applies cumulatively per company across all agreements and renewals. These are examples, not forecasts or quotes. A reward becomes payable after SourceX has paid the referred company under its signed agreement and the payout conditions in the program terms are met, including finance approval and your tax and payment details. See [how rewards work](/rewards).

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

Once the engineering director has corrected the brief and named the signer, [register as a partner](/register), recheck [who qualifies](/who-qualifies), and read the [program terms](/terms) before the brief is forwarded.

## Sources

- https://refer.sourcex.si/terms
- https://refer.sourcex.si/rewards
- https://launchdarkly.com/docs/home/releases/change-history
- https://support.pagerduty.com/main/docs/incidents