Spryker vs. CWS Platform: how do order approval operations hold up?

Editorial note: a comparison between Spryker and CWS Platform written for those who run operations, as COO or VP of Operations. Every fact about Spryker comes from its public documentation, with the address next to it.

In a distributor's operation, the most expensive order is not the one that errors out. It is the one that sits waiting for someone. The cart is built, the customer wants to close, and the approval does not move because the right approver sits in another branch, because the amount exceeds every limit on file, or because the person who has to release it is outside the company network.

For a COO, order approval is not a screen feature. It is a workflow that needs an owner, a fallback path, and access for the people who run it. Every stuck order turns into a call to the sales rep, rework for customer service, and a sale that leaks to another channel.

This comparison looks at Spryker and CWS Platform from that angle only: who approves, what happens when the rule does not cover the case, and where the operations team works. It is not a feature ranking. The broader frame of the architectures is in the post on the three B2B commerce platform models.

71s

What Spryker does well

Spryker brings a detailed structure for the buying company. Company Account organizes the company into business units and users, with configurable roles and permissions, and the Business on Behalf mechanism lets the same user act in different business units with different roles. The business unit hierarchy is organized in levels, as described in the business units overview.

The Approval Process runs on top of that structure. Checkout is restricted when the cart total reaches the limit of the "Buy up to grand total" permission. A buyer with the "Send cart for approval" permission picks an approver, the cart is locked against editing and gets the "Waiting" status. The approver reviews it within the limit of their "Approve up to grand total" permission; if approved, the cart goes back to the buyer to complete, and if declined, the cart is unlocked and can be resubmitted.

For a buying company that needs spend control by role and by business unit, this design is clear: every limit has an owner and every cart state has a name.

Where the architecture diverges

The divergence that matters to a COO is in the cases the workflow does not cover. Per the documented mechanism, the approval relationship is confined to the same business unit: if the user's unit has no approvers, checkout is blocked, even when approvers exist in other units or in the direct parent unit. Per the feature installation guide, only the cart owner can send the approval request.

The vendor's own documentation records two points that shape how operations are designed:

• limitation recorded in the vendor's documentation, accessed on October 16, 2026: approvers can only approve orders from employees within their own business unit; when the quote total exceeds every approver permission set for the company, it cannot be processed and the indicated workaround is to edit the quote ("Approvers can only approve orders of employees within their own business unit.", "Quote D can’t be processed because the quote total is higher than any Approver permissions set for that company. In such case, the only workaround is to edit the quote", https://docs.spryker.com/docs/pbc/all/cart-and-checkout/latest/base-shop/feature-overviews/approval-process-feature-overview.html).
• limitation recorded in the vendor's documentation on September 18, 2026: the Back Office application must be secured in an intranet using VPN, Basic Auth, IP allowlist, or DMZ ("Back Office application must be secured in an Intranet using VPN, Basic Auth, IP allowlist, or DMZ.", https://docs.spryker.com/docs/dg/dev/system-requirements/latest/system-requirements.html).

The first point creates two standing jobs for operations: making sure every business unit on the buyer side has an approver, and agreeing on what to do with the large order that exceeds every limit. In distribution, the large order is exactly the one the sales rep most wants to close, and editing the quote to fit the limit means renegotiating it.

The second point weighs on the people who run the operation every day. Per the Order Management System mechanism, order events can be triggered manually in the Back Office. If the Back Office lives inside a protected perimeter, access design for the operations team, from people in the office to people in the field, becomes part of the implementation project.

On CWS Platform, commercial policy sits in parameters of the Commerce Rules Engine (CDL Workspace). The sales rep's discount goes through multi-level approvals, and the customer's credit limit is maintained on the platform, granted in CDL Workspace or through an API. CDL Workspace is a single system for the entire ecosystem, and customer and sales rep use the same interface, on the same order.

The operational decision is knowing how many cases in your approval workflow depend on an exception, and who resolves each one.

What changes in operations, through the COO lens

The cost of an approval workflow shows up at the edges, not on the happy path. Three edges deserve attention in any evaluation.

The first is coverage. B2B customers change structure: they open branches, change buyers, reorganize cost centers. If approval depends on having an approver in each business unit, someone has to keep that setup current, or the order stops at checkout.

The second is the ceiling. Every workflow with limits needs an answer for the order that exceeds the highest one. When the answer is to edit the order, operations needs to know who edits it, who tells the customer, and how long that takes.

The third is access. The team that tracks orders, releases exceptions, and answers the sales rep needs to get into the system from wherever it is. The network model decides whether that is a login or an infrastructure project.

Three questions bring this reasoning to the table: in which cases an order can end up with no possible approver; what happens to the order above every limit; and from where the operations team reaches the platform's administration.

On CWS Platform, one sales rep serves thousands of customers, and a sales rep builds a cart, with the items and the source of each one, and sends the link for the customer to complete the purchase. The order supports payment on terms with split, scheduled deliveries to multiple addresses and from multiple ship-from locations.

When to choose Spryker

Spryker fits scenarios where the buyer's spend control is the center of the operation:

A buying company with limits by role. Choose this architecture when buyers need purchase and approval limits defined by role, as in the Approval Process.

A stable business unit hierarchy. Choose this architecture when the structure of buying companies changes little and every unit has a defined approver, organized in Company Account.

Operations concentrated on a protected network. Choose this architecture when the team using the Back Office already works inside an intranet with VPN, IP allowlist, or DMZ, and the infrastructure team maintains that perimeter.

When CWS Platform is the right choice in this scenario

CWS Platform is the right choice when operations wants commercial rules in parameters and customers, sales reps, and operations working in the same system.

Discount approvals. Choose this architecture when the sales rep's discount needs approval. The sales rep's discount goes through multi-level approvals. Tables, rules, and contracts sit in parameters of the Commerce Rules Engine (CDL Workspace), on the principle of configuration over code.

Credit maintained on the platform. Choose this architecture when the customer's credit needs to live in the same system where the order is closed. Credit is maintained on the platform, granted in CDL Workspace or through an API.

Customer and sales rep on the same order. Choose this architecture when the sales rep takes part in closing. Customer and sales rep use the same interface, and the order records who built the cart and who chose the payment.

One system for the whole ecosystem. Choose this architecture when operations does not want separate tools for each actor. CDL Workspace is a single system for the entire ecosystem, and all customers run the same version.

Where to go from here

To see the same comparison through the technical lens, the comparison of customer-specific pricing in the Spryker and CWS Platform ERP integration covers how commercial data reaches the portal.

If your operation has many approval exceptions, it is worth talking to a CWS Platform specialist to map the edge cases before you choose. The seven questions that separate B2B commerce architectures help structure that conversation, and the page When Selling More Doesn't Mean Earning More covers the pain behind ungoverned discounting, without talking about any vendor.