Classic release strategies

Before flexible workflow, SAP approvals for requisitions and purchase orders used release procedures. Contoso's ECC 6.0 system has them, and after conversion to SAP S/4HANA they still work. Many companies keep them for a while, so testers, key users and process owners need to understand them, and to know how they live alongside flexible workflow.

How a classic release strategy works

The usual form is release with classification. Characteristics such as total value, plant, purchasing group, material group or document type are defined on communication structures (CEBAN for requisitions, CEKKO for purchase documents) and grouped in a class. Each release strategy is a combination of characteristic values (for example, plant 1710 and value over $25,000) with the release codes that must approve, their sequence, and the release indicators that say what the document may do at each stage (for example, "blocked" until the last code releases). Requisitions can also use a simpler release procedure without classification, at item level only.

Releasing documents

Approvers release with their release code. Collective release lists many documents at once and releases them in one action, but does not support rejection; individual release allows approving or rejecting specific documents. Release codes can be linked to workflow so that approvers are notified, but many companies simply ran a collective release list each morning.

Running both

SAP lets you choose per document type: one PO document type can use flexible workflow while another still uses a release strategy, and the same is true for requisitions. That allows a gradual move. It also creates risk: if both are configured for the same document type, or switched mid-process, documents can behave unexpectedly, for example a release strategy not being triggered or the workflow starting when it should not. SAP has published knowledge base articles on these symptoms. Contoso's design keeps an explicit table of document types and their approval method, and every change to it is a change request.

Moving from release strategies to flexible workflow

Contoso's plan converts with release strategies unchanged, so day one behaves like ECC, and moves PO document types to flexible workflow one at a time after go-live. Each move is a small project: rebuild the strategy's values as start conditions and steps, map release codes to roles or team functions, decide what happens to POs already in release, and retest the thresholds. Documents created under the old method keep their release status, so expect a period in which both methods are visible in reports. In Public Edition this question does not arise, because flexible workflow is the approval approach there.