A write-back is the moment an agent changes something in the system that owns the data.
Six steps: approve, choose the interface, send, check, answer, record.
An agent reads wherever the data already lives, and writes only where the vendor supports a write. Juno picks the published interface for that business object and that release.
The write goes out under the agent’s own service account, with its own rights. Juno sends the current version of the document with the change, so a document someone else has edited in the meantime is recognised.
Your system then does what it always does: it checks authorisation, applies the release strategy, tests tolerances, assigns the number and posts the change. Every one of those checks runs as it does for a person.
The answer comes back as a document number or as a message that says what to change. Juno stores it as returned, reads the document again and closes the record.
One row per change an agent makes, with the published interface on each side and the checks your system keeps.
| What the agent changes | SAP S/4HANA | Oracle Fusion | What your system checks |
|---|---|---|---|
| Cancel or close a purchase order line | Purchase Order service API_PURCHASEORDER_2, or BAPI_PO_CHANGE on older releases | A change order on draftPurchaseOrders with a cancel flag and a reason, then the submit action | Authorisation, the release strategy, the quantity still open |
| Change a delivery date or an open quantity | A change to the item or the schedule line on the same Purchase Order service | A change order on the line schedule, then the submit action | Tolerances, confirmation control, the document date |
| Update a planning parameter | Product Master service API_PRODUCT_SRV, or BAPI_MATERIAL_SAVEDATA | An update on itemsV2, or the planning import for safety-stock levels | Field authorisation, plant validity, master-data governance |
| Firm or re-date a planned order | Planned Order service API_PLANNED_ORDERS | Planning supplies on the supply plan, with the firm and implement fields | The planning run, the firming rules, the plan version |
| Ask for a stock transfer | A stock transport order through the Purchase Order service | A supply request into Supply Chain Orchestration | Availability at the supplying plant, the transfer route |
| Change a sales order schedule line | Sales Order service API_SALES_ORDER_SRV | An update on the order hub sales order | Availability, credit, the delivery block |
Older releases publish different doors to the same objects. SAP ECC takes function calls and messages: BAPI_PO_CHANGE for a purchase order, and the ORDCHG message where your integration already runs that way.
Oracle E-Business Suite takes interface tables and their import programmes, such as the purchase order interface with the standard import, and the change routine for quantities, prices and promised dates.
A connector holds these settings per application: the service, the release, the account, the fields the agent may write and the rate it may write at. Adding a release is a settings change.
Where a vendor publishes a governed route for master data, Juno uses it. A safety-stock change can go as a change request for a steward to approve, so your master-data rules keep their place.
Interface names as published by SAP and Oracle. The right one for your estate depends on your release and edition. Product.
One object, one application, one confirmed test write, two signatures.
Write-back is off until a test write succeeds. The test runs in your test system, from the agent’s own account, against one object: one purchase order line, one material at one plant.
Your team reads the answer and opens the document. When the change is there and the answer matches, the application owner and the owner of the agent sign it off.
The switch is per application and per object, so a team can start with purchase order changes in one system while everything else stays at report and draft.
The first live day runs with a lower daily action budget, so the team has a short list of answers to read.
Three parts per write: what was sent, what came back, and what the document reads afterwards.
| Time | Part of the write | What was sent, and what your system returned |
|---|---|---|
| Mon 09:12 | The request | Change purchase order 4500067123, item 00020: set the deletion indicator |
| Mon 09:12 | The account used | The agent’s own service account, with rights to change purchasing documents |
| Mon 09:12 | The document version | The current version of the document was read and sent with the change |
| Mon 09:12 | The answer | Item 00020 of 4500067123 updated · message 06 023 stored as returned |
| Mon 09:13 | The read-back | The line reads deletion indicator L, and the open quantity reads 0 |
| Mon 09:13 | The link to the decision | Rule version 3 · approver D. Okafor · reference DEC-2026-09-21-0417 |
One write-back in the showcase estate. Message numbers are illustrative; the mechanics are the product’s.
The answer is the proof. A document number says your system accepted the change and gives an auditor a document to open. A message says what your system asks for, in your system’s own words.
Juno reads the document again after the write. The read-back is what turns an answer into a confirmed state: the line reads the deletion indicator, and the open quantity reads zero.
All three parts sit under one decision reference, with the rule version, the facts as read, the limits checked and the approver. That is the chain an auditor follows, from a change in the ERP back to the sentence a planner wrote.
It is also the answer a buyer gets at the desk: this line was cancelled on Monday at 09:12, by this rule, approved by this person.
Four answers, one behaviour each, and every message stored in your system’s own words.
| What your system answers | What it usually means | What Juno does |
|---|---|---|
| The system is busy | A queue or a lock on the document at that moment | Tries again after a widening gap, up to the limit you set |
| The document has moved on | Someone changed the document after the facts were read | Reads the document again, redrafts the action and sends it back to the approver |
| A check asks for something | A release strategy, a tolerance or a missing field | Stores the message, marks the action as waiting and shows it to the approver |
| The service is out of reach | A window for maintenance, or a connection under repair | Holds the action in the queue; the next run raises the same case while it is still open |
Every one of these answers is stored. A write that waits keeps its place in the queue with the message beside it, so a person sees the reason in your system’s own words.
Retries are bounded. After the last try the action goes to the named desk that receives an overdue approval.
The rate limit keeps a source healthy while a large set of actions goes out. Twenty writes a minute spread 38 cancellations over two minutes, which your system handles as ordinary traffic.
Waiting actions are counted in the manager report, so a pattern of messages from one system is visible within a week.
Showcase estate.
D. Okafor’s eight approvals left the queue at 09:12 and went to SAP S/4HANA through the Purchase Order service, at twenty writes a minute. Each one carried the version of the document it had read, and each came back with a document number.
One line came back with a message: the purchase order had been changed by the plant at 08:55, so the facts were out of date. Juno read the document again, redrafted the cancellation on the new quantity and sent it back to the queue, where it was approved at 09:31.
How competing recommendations on one field are ranked inside a band you set, and when a named person decides.
It writes through the interfaces the vendor publishes for that object, so your authorisation, your release strategy, your tolerances and your numbering all apply.
Older releases keep their own doors: function calls and messages for SAP ECC, interface tables and import programmes for Oracle E-Business Suite. The connector holds the settings per application.
One confirmed test write in your test system, read by the application owner and the owner of the agent, for one application and one business object at a time.
The message is stored in your system’s own words, the action is marked as waiting, and the approver sees the reason. The next run raises the same case while it can still be acted on.
Each one builds on the one before it.
Reads your rows in place.
Connect and move ↗One record per real thing.
Master and govern ↗Apps for every decision.
Operate and decide ↗Asks and acts, at your level.
Ask and act ↗Bring two systems and one decision your planners make every week. In the first week we register the data, confirm the mapping with your team, answer your questions in ChatLima and run the first agent at the level you choose.
