Lesson 4 of 5
Recording decisions
9 min
A decision nobody can find is a decision that will be made again, usually worse, by someone who was not in the room. Recording design decisions is how a process owner protects the clean core after the workshops end, and how the test team knows what to prove.
The design decision log
A design decision log is a simple register: one entry per decision, owned by the process owner. In SAP Activate projects it sits alongside the backlog. Many teams keep it in SAP Cloud ALM, where requirements and user stories can be linked to the solution process and on to test cases, which gives you traceability from decision to evidence. A shared spreadsheet works too, as long as it is controlled.
| Field | Contoso example |
|---|---|
| ID and title | DD-O2C-014: Fleet contract number on customer invoices |
| Requirement and source | Great Lakes Fleet Services contract clause 7.2 requires the contract number on every invoice |
| Options considered | Adopt (rejected: breaks contract); configure output text from customer master (rejected: number varies per order); key user custom field (chosen) |
| Decision | Extend: custom field on sales order header, passed to billing and printed on invoice output |
| Rationale | Contractual need; Level A; lifecycle estimate 35.5 person-days over 7 years |
| Clean core level | A |
| Owner and approver | Maria (key user) owns the detail; Dan approves for finance; architect reviewed |
| Date and status | 2026-03-12, approved |
| Linked test scenarios | O2C-07 (order with contract number), O2C-08 (order without), O2C-21 (invoice output), regression set R-O2C |
| Review trigger | Contract renewal or SAP delivers a standard field for contract reference |
A design decision log entry.
Rationale is the important part
Most logs record what was decided. Few record why. The why is what lets someone later tell whether the decision still holds. If the reason was "the contract requires it," the decision should be revisited when the contract changes. If the reason was "SAP has no standard option," it should be revisited when SAP delivers one. Write the reason in one or two plain sentences.
Linking decisions to tests
- GapRaised in fit-to-standard and recorded as a backlog item
- DecisionLogged with option, rationale, clean core level and owner
- BuildConfiguration or extension delivered against the user story
- Test scenariosPositive and negative scenarios linked to the decision ID
- EvidenceTest results prove the decision was implemented as agreed
- Regression setScenarios carried into every future release test
Every decision except "adopt standard" should name at least one test scenario that proves it. Extensions need negative tests as well: what happens when the custom field is empty, too long or wrong? Configuration decisions need tests that show the configured behavior, for example that the new warranty document type is priced at zero. Without those links, the test team tests the standard process and nobody notices the decision was implemented wrongly.
Design sign-off
The Explore phase closes with sign-off of the process designs. For a process owner, that signature means three things: every delta in your area has a decision, every decision has a rationale you can defend, and every non-standard decision has a test that will prove it. Before you sign, filter the log for your process area and read it end to end. Look for open items, decisions with no owner, extensions without a clean core level, and rows with no linked test. Each of those is a question to answer before the signature, not after go-live.
Keep the log readable by people outside the project. An auditor, a new process owner or an upgrade team in three years should be able to understand an entry without the workshop slides. Avoid internal shorthand, spell out document types and org units (sales area 1710 / 10 / 00, plant 1710), and name people by role as well as by name.
- Does every delta in your area have a decision?Yes → check rationale · No → decide or record it as open with an owner and date
- Does every decision have a rationale and an approver?Yes → check level · No → complete the entry before signing
- Does every extension have a clean core level?Yes → check tests · No → ask the architect to classify it
- Does every non-standard decision link to a test scenario?Yes → ready for design sign-off · No → add positive and negative scenarios
Keeping the log alive
- Review new and changed decisions at every design authority or steering meeting.
- Freeze the log with the design sign-off at the end of Explore, then control changes through change requests.
- After go-live, review it before every upgrade: which extensions need retesting, and can any be retired because SAP now offers a standard option?
- Retire decisions explicitly; do not just delete rows.
What would you do?
Six months after go-live, Contoso's auditors ask why a custom approval step exists in purchasing. Nobody on the current team remembers. What would have prevented this?
- Keep a design decision log owned by the process owner.
- Record options considered, decision, rationale, clean core level, owner, approver and date.
- Link every non-standard decision to positive and negative test scenarios and the regression set.
- Review the log before upgrades and retire decisions that SAP standard now covers.
Check your understanding · not graded
Lesson check
1. Which field in a decision log best lets someone judge later whether the decision still holds?
2. Why record rejected requests?
3. What should every extension decision link to?
4. When should the decision log be reviewed after go-live?