Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Approvals and evidence

10 min

An approval without evidence is a signature on a guess. Each approval step in your process should name three things: who approves, what evidence they need to see, and where that evidence lives in Cloud ALM. If any of the three is missing, the step will degrade into a rubber stamp under schedule pressure.

Approval steps at Contoso

StepApproverEvidence requiredWhere it lives
Requirement approvedProcess owner (Dan, Maria)Business case, scope, affected processesRequirement, with its approval history
Design acceptedSolution architectTechnical design, impact on interfaces and authorizationsFeature description and references
Successfully TestedTest lead (Priya)Linked test runs passed with evidence; defects closed or acceptedTest runs and defects linked to the feature
Ready for ProductionChange Manager (Luis)Test sign-off, transport checks clean, ATC clean or exempted, release confirmedFeature status history, transport check results
Deployed confirmedBasis lead (Sam)Import completed without errorsFeature Traceability and transport logs

Who approves what, on what evidence, and where it is recorded.

In Cloud ALM, approving a feature for production (setting Ready for Production) needs the Change Manager or Project Admin role. That gives you separation between the people who build and the people who release. Requirements can go through an approval workflow, with workflow updates captured in the requirement history. Check what your tenant offers today for additional approval steps; SAP has been extending workflow options, and SAP's own roadmap material has listed further approval and segregation-of-duties items. Where Cloud ALM does not enforce a step, your procedure must, and the evidence must still be recorded on the feature.

DecisionLuis sets Ready for Production; the history records who and when
Sign-offsPriya’s test sign-off; Dan or Maria accept any open defect in writing
ChecksTransport checks and ATC results attached or referenced
Execution evidenceTest runs in CMQ with results and attachments
ScopeApproved requirement linked to the feature
Evidence builds from scope up to the decision. Remove a layer and the decision has nothing under it.
The Sign-Off Table · thesignofftable.com/academy/sap-rel-301

Evidence that stands up later

  • Specific: the test run for this feature in this system, not "regression passed last month".
  • Dated and attributed: who executed it and when, recorded by the tool, not typed into a comment.
  • Linked: attached to the feature or reachable from it in one click.
  • Complete for the risk: a change to pricing needs pricing test cases, not a smoke test of the login.
  • Honest about gaps: an open defect is acceptable when the process owner accepts it in writing with a workaround and date.

Separation of duties

The person who builds a change should not be the person who approves it for production or imports it. In a small team that is hard; Kenji may be the only person who understands a custom pricing routine. Separation can still be achieved by role: Kenji builds, Priya's team tests, Luis approves, Sam imports. Where one person must hold two roles, record it and add a second reviewer for that change.

Low risk, light evidenceStandard changes: pre-approved checklist, one confirming test
High risk, light evidenceDanger zone: urgent changes without review. Add a retrospective review
Low risk, full evidenceOver-control: slows routine work. Move to the standard path
High risk, full evidenceNormal changes to core processes: full test, sign-off and approval
Match evidence depth to risk. Both off-diagonal cells need attention.
The Sign-Off Table · thesignofftable.com/academy/sap-rel-301

Timing of approvals

An approval only controls something if it happens before the action it approves. That sounds obvious, yet backdated approvals are one of the most common audit findings. Build the order into the release calendar so the approval steps have room, and so nobody is tempted to approve after the fact on go-live weekend.

  1. Before buildRequirement approvedProcess owner authorizes the scope
  2. End of buildDesign and code checksATC clean; transport checks run on the feature
  3. End of test cycleSuccessfully TestedPriya signs off; open defects accepted in writing
  4. Release boardReady for ProductionLuis approves each feature for the release
  5. After importDeployed confirmedSam confirms the import; smoke test recorded
Approvals in the order they must happen, each before the step it controls.
The Sign-Off Table · thesignofftable.com/academy/sap-rel-301

What would you do?

Maria, the order-to-cash key user, approves a pricing change by replying "looks good" to an email with screenshots. The feature in Cloud ALM has no linked test runs. What should Priya do?

Key points
  • Every approval step names who approves, what evidence, and where it lives.
  • Ready for Production requires the Change Manager or Project Admin role, supporting separation of duties.
  • Evidence must be specific, dated, attributed, linked and proportional to risk.
  • Where the tool does not enforce a step, the procedure does, and the evidence is still recorded on the feature.

Check your understanding · not graded

Lesson check

  1. 1. Which three things should every approval step define?

  2. 2. A process owner accepts an open defect. What makes that acceptable evidence?

  3. 3. Kenji is the only developer who understands a routine. How can separation of duties still be achieved?

  4. 4. Which matrix cell signals the biggest control gap?