ByDesign order-to-cash automation is two lines, not one. Most teams only build the first.

The thesis, plainly

The most common shape of a ByDesign O2C automation project is to map the whole flow as an event diagram and then ask IT to wire OData and SOAP integrations against every node. That works for the API-shaped nodes and stalls on the UI-shaped ones. After two quarters the steady-state pieces are running, and the team is still entering sales orders from PDFs by hand and fighting through partial-match wire allocations every Tuesday.

The shape that ships is to score every touchpoint in O2C as API-only, UI-only, or mixed, build the API-only and the API portion of the mixed nodes against ByDesign's standard services, and use a UI-driven recorder for the UI-only and the UI portion of the mixed nodes. The two lines are not in competition. They cover different screens.

The rest of this page is the seam map. Then it answers the only mechanical question that matters about the second line: what makes a recorded WorkCenter workflow survive a ByDesign release that nudges the layout.

The seam map: seven O2C touchpoints, scored

Cards in teal are the ones that produce the bulk of human hours and where the recorded WorkCenter line earns its keep. The plain cards are either API-shaped or so context-dependent that the right answer is the API in some tenants and the UI in others.

The two lines, side by side

The diagram below is the live shape of a ByDesign O2C automation that admits both lines. On the left, the inputs that show up in a ByDesign tenant every day. In the middle, the runtime that sits between the inputs and the screens. On the right, the WorkCenter surfaces where the human-decision steps actually happen.

The OData and SOAP integrations sit in a parallel pipe in the same tenant. They handle ATP, the standard customer invoice, and the standard delivery confirmation. The diagram is intentionally about what the API pipe does not cover. The two lines together cover the whole flow.

The screen-shaped problem in three deeper passes

Three of the seven touchpoints absorb the bulk of the time. Each one is worth reading on its own.

Sales order entry from a customer-attached PDF

A customer emails a PO. The buyer is a small company that will not adopt EDI in this lifetime. The PDF has the buyer, the ship-to, eight lines with quantities and prices, and a PO number. TheCustomerInvoiceCreateRequestweb service does not help, because the data is not yet in the tenant. A document model parses the PDF into a typed object; the recorded ByDesign workflow opens the Sales Orders WorkCenter, clicks New Sales Order, and types each field by role and name. The validation shape of the object (a posting date inside an open period, a known customer, line items with non-empty product IDs) is what catches malformed inputs before they reach the screen.

Manual payment allocation when the bank file does not auto-match

Most wires hit the auto-match. The wires that do not are the interesting ones: a single inbound payment that covers parts of three open invoices, a payment that arrives 47 cents short of an invoice total, a wire whose memo line names two PO numbers that were merged into one invoice. The Payment Allocation screen is where this is resolved. The recorded workflow does not replace the judgment about which open items the wire actually covers; it takes a structured allocation proposal (open items, allocated amounts, residuals) and drives the screen to apply it, leaving the human to review the proposed split. The apply happens on the screen because the apply button is on the screen.

Dunning review and approval

The dunning run itself is a scheduled job. The review of the proposal is the slow part. Suppress this customer because they are on a payment plan, push that customer to the next dunning level, write off the old item that has been on the books for two years and will not be paid. That review lives in the Receivables WorkCenter and the dunning monitor. A recorded pass that walks the proposal row by row, applies the allowed actions for each row, and parks the remainder for human review is what turns the weekly four-hour ritual into a forty-minute one.

The mechanical question: what survives a ByDesign release

The fair argument against UI automation in a SaaS ERP is that the vendor reshuffles the layout twice a year and the recordings break. That is true if the recordings are tied to coordinates. It is not true if the recordings are tied to the accessibility surface, which is the same surface a screen reader uses and the one ByDesign and the SAP UI shell maintain across releases.

The Mediar desktop runtime makes that explicit. Before two captured DOM trees are compared, a function called remove_volatile_dom_attributes walks the JSON and drops every x, y, width, height field, plus the value attribute on input elements (which would otherwise dominate the diff with content noise). The file is at apps/desktop/src-tauri/src/dom_tree_diff.rs in the open-source desktop agent.

The consequence for a ByDesign tenant is the part that matters: a half-yearly release that nudges a field down a row in the Sales Orders WorkCenter or repaints a column in the Payment Allocation grid does not produce a tree diff. The recorder does not see it. The run continues. A release that actually renames a field or removes one shows up as a real change and is flagged at the recording side, which is the place to fix it.

The retry shape behind a ByDesign cloud session

ByDesign is a cloud tenant. Cloud tenants drop sessions. The runtime accounts for that with a deterministic backoff in crates/executor/src/config/retry.rs. The default schedule is 30 seconds, then 60, then 120, capped at 600, with three Infrastructure retries before the run is marked failed. A session that drops for 90 seconds is invisible: the queue waits, retries, and continues. A tenant that is genuinely down for a planned outage produces three retries inside about three and a half minutes and then a clean failure that surfaces in the dashboard as one alert.

The four WorkCenter surfaces that absorb the work

The recorded line is concentrated in four places in a ByDesign tenant. Each one is reachable by role and name on every input and every table column header, which is what makes the recordings hold up across releases.

When this design is the wrong fit

Three cases where the recorded WorkCenter line is not the right answer.

Pure happy-path O2C with mature integrations. A tenant where every customer is on EDI, the bank file matches cleanly every time, and the dunning policy is small enough that a scheduled run produces almost no review work, has very little for the second line to do. The OData and SOAP layer is doing the job.

High-volume bulk loads. A 40,000-line price-list update or a one-time customer master migration is what the ByDesign data migration cockpit and the standard mass-upload tools are built for. The recorder is built for the steady stream of event-driven O2C tasks (a PDF arrives, a wire posts, a dunning monitor is reviewed), and it is honest to say it is not the right shape for the once-a-quarter migration.

A tenant that mostly needs reporting. If the gap in your O2C is the analytics layer rather than the execution layer, ByDesign analytics and a downstream warehouse are the right answer. Recorded automation does not produce insight; it produces posted documents.

Frequently asked questions