Turning business requirements into Salesforce stories

A requirements document says what the business needs. A user story says what gets built. The gap between them is where most rework starts: a requirement written in business language gets handed to a developer, who makes reasonable assumptions about which object, which field, which automation, and half of those assumptions turn out wrong in review.

This closes that gap on paper, before anything gets built.

---

Step 1: pull out the requirements as atomic statements

Requirements documents bundle several asks into one paragraph. Split them first, or everything downstream inherits the bundling.

Here is a requirements document:
[paste it]

List every distinct requirement as a separate, numbered, testable
statement. If two sentences in the source describe the same
requirement, combine them. If one sentence bundles two requirements,
split it. Flag anything vague enough that you can't state it as a
testable statement.

The flagged, vague ones are the most valuable output of this step. They’re the requirements that were always going to cause a rework cycle, just moved earlier where it’s cheap to fix.

---

Step 2: map each requirement to the platform, by hand

This step isn’t delegable, the same way splitting business-owner questions from platform questions wasn’t in the spec-prompt workflow. For each requirement, write down: which object it touches, whether it needs a new field or reuses one, and whether standard functionality covers it or it needs automation.

Requirement: [requirement text]
Object(s): [your answer]
New or existing fields: [your answer]
Standard functionality or custom automation: [your answer]
My confidence in this mapping: [high / medium / low]

Anything marked low confidence goes to step 3 before you write a story around it.

---

Step 3: interrogate the low-confidence mappings

I've mapped this requirement to [object/fields/automation]:
[paste it]

I'm not confident in this mapping. What would a senior Salesforce
architect ask before agreeing to it? List the questions, then argue
for an alternative approach if there's a reasonable one.

Same rule as with any spec work: it will confirm a plausible-sounding design if you don’t ask it to argue the other side. Making the disagreement explicit is what surfaces the alternative you hadn’t considered.

---

Step 4: write the stories, one requirement at a time

Requirement: [the confirmed requirement]
Object(s): [confirmed]
Design approach: [confirmed]

Write this as a Salesforce user story:
- Standard "As a [role], I want [capability], so that [reason]" format
- Acceptance criteria specific to this object and field, each one a
  pass/fail statement a QA tester could check without guessing
- Note anything this story depends on or blocks

One requirement per prompt, not the whole list at once. A batch request tends to produce stories that all read alike regardless of how different the underlying requirements actually are.

---

Worked example

The requirement, as written in the source document: “Sales reps should be alerted when a deal has been inactive for too long so it doesn’t fall through the cracks.”

Split in step 1 into two: (a) define what “inactive” means and how it’s measured, (b) define what “alerted” means and to whom.

Mapping for (a): Opportunity object, needs a formula or automation comparing LastActivityDate to today, confidence medium, since “too long” wasn’t defined anywhere in the source.

Interrogation surfaced the real question: does “inactive” mean no logged activity, no stage change, or both? That went back to the business owner rather than getting guessed at.

Final story for (a), after the business owner answered “no logged activity for 14 days”: As a sales manager, I want Opportunities with no logged activity in 14 days flagged, so that stalled deals get noticed before they’re lost. Acceptance criteria included the exact field checked, the exact threshold, and what happens to the flag when new activity is logged.

---

When it breaks

It maps a requirement to a rebuild when a standard feature already covers it. This shows up most on anything involving approvals, notifications, or duplicate detection, all of which Salesforce ships built-in versions of. Ask specifically: “does standard Salesforce functionality already do this?” before accepting a custom design.

The acceptance criteria are vague restatements of the requirement. “The system should notify the rep” is not testable. Push back until each criterion names the specific trigger, the specific field, and the specific outcome.

Two stories turn out to depend on each other in a way neither one states. This is common when one story needs a field the other story creates. Read the batch back together once all stories are written and check for that specific gap; it’s not something step 4’s one-at-a-time approach catches on its own.

The original requirement was never actually testable, no matter how it’s split. That’s a real finding, and the honest move is sending it back to the business owner rather than inventing a testable version that quietly changes what was asked for.

---

What to try next

Keep the requirement number attached to each story through to delivery. When someone asks “why does this field exist,” the answer is the story number and the original requirement, not a guess at intent from someone who wasn’t in the room when it was written.