Practical ERP guidance
ERP Integration Exception Handling: A COO's Go/No-Go Control Set for Order and Inventory Feeds
ERP integration exception handling is an operations discipline, not an IT housekeeping task. When an order, a stock update or a shipment confirmation fails to cross the boundary between your ERP and another system, the result lands on your floor, in your warehouse and in your customer's inbox. The COO's job is to insist on three things before go-live: every message ends in a defined outcome, every outcome has a named owner, and a short list of mandatory controls has been proven by test rather than promised in a demo.
This article is written for the COO or Operations Head who inherits the consequences of integration design. It does not ask you to write code. It gives you a proposed outcome model, a plain-language view of the technical controls behind it, and an all-required go/no-go control set you can hand to your CIO and your vendor.
- Scope: eCommerce, CRM, WMS, MES and finance feeds into and out of an ERP, in both cloud (SaaS) and on-premises deployments.
- Not covered: your specific legal obligations. Privacy, retention and audit duties depend on your jurisdiction and contracts, so confirm them with counsel.
- Related reading: for the developer-level view, see our CIO's guide to idempotent ERP integration. This article is the operating-model companion.
Key Takeaways
- HTTP 200 is not the same as "the business outcome happened." Define success at the level of the ERP record, not the network response.
- Use four lanes: Confirmed, Rejected (terminal), Unknown and Held (uncertain input). Unknown means completion could not be confirmed. It is neither success nor verified failure.
- Never blindly retry an ambiguous timeout on a consequential change. Check the authoritative operation state in the target system first.
- Bind each operation to a tenant-scoped identity and an immutable payload hash. Reject a reused identity that arrives with a different payload, and make sure legitimate later orders get new identities.
- Use go/no-go controls, not a points score. Every control in the set below must pass for the flow in scope. A passing set closes known gaps. It does not certify the whole system.
- Name the owner of the exception queue, and of the privacy risk inside it. Identifiers such as order numbers, emails and serial numbers can be sensitive data.
- Vendor claims are inputs to verify, not conclusions. Ask for written answers on idempotency, retries and replay for each interface you rely on.
Why Integration Exceptions Become an Operations Problem
Key takeaway: Integration failures are rarely loud. They show up as a duplicate pick ticket, a phantom reservation or an invoice that never left. Operations absorbs the cost, so operations must own the outcome definition.
Your ERP is the system of record. Everything else, whether a storefront, a CRM, a warehouse scanner or a plant-floor terminal, either feeds it or consumes from it. Each of those feeds is a place where a message can be lost, repeated, delayed, rejected or applied twice. IT teams measure these as error rates and latency. You experience them as customer calls, expedited freight and month-end reconciliations that run late.
The mismatch is structural. Integration is usually built by a technology team against a specification such as "sync orders from the storefront." Nobody writes down what happens to the one order in a thousand where the network drops after the ERP has already created the sales order. That gap is where operational damage accumulates.
| Flow | Typical exception | What operations feels | Who notices first |
|---|---|---|---|
| Storefront order to ERP sales order | Timeout after creation, duplicate delivery, rejected customer match | Duplicate shipments, or an order the customer paid for that nobody picks | Customer service |
| ERP inventory to sales channels | Stale or partially applied stock updates | Overselling, or stock hidden that is actually available | Merchandising, support |
| Shipment confirmation back to ERP | Lost or double-applied confirmation | Stock that is physically gone but still on the books | Warehouse supervisor |
| Shop-floor postings to ERP | Missing or repeated production reports | Wrong WIP and cost, misleading schedule | Plant manager (see our guide to duplicate and missing ERP postings) |
| Invoice and payment status | Status update lost or applied out of order | Dunning sent to a customer who already paid | Finance, account managers |
Staleness windows are also a business decision. In an example published on ArionERP's API page, a central script polls product and inventory endpoints every five minutes and pushes stock levels to several storefronts, while a webhook from each platform creates a sales order in the ERP when an order is placed. Whatever your own polling interval is, it sets the maximum period during which a channel can display stale stock. Choosing that interval is a trade-off between oversell risk and system load, and it belongs on an operations agenda.
2026 Update, Then the Evergreen Rule
As of 2026, more order flow arrives through event notifications and automated agents, and more teams let software initiate ERP transactions without a person in the loop. That raises the volume of messages and shortens the time in which a wrong one can do damage. The control logic does not change: define outcomes, make duplicates harmless, treat uncertainty as its own state, and give every failure an owner. Those four rules will hold regardless of which tools or channels dominate in the years ahead.
How Most Organizations Handle Exceptions, and Why It Fails
Key takeaway: The common patterns, retry until it works, trust the HTTP status, email an alert, are reasonable for low-stakes data and dangerous for orders, inventory and money.
Most integration projects start with the happy path. Exception handling is added later, usually as retries and an alert email. That works until the first ambiguous failure: the request timed out, but the ERP may or may not have created the record. Retrying might create a duplicate. Not retrying might lose the order. The system has no way to say which, so a person guesses.
| Common approach | What it silently assumes | How it fails | Better rule |
|---|---|---|---|
| Retry until it works | The first attempt did not take effect | Duplicate sales orders, double reservations, double postings | Reconcile authoritative operation state before any retry of a consequential change |
| A 2xx response means done | The receiver finished the business work before replying | Receiver replies, then crashes. The sender stops retrying and the order is gone. | Acknowledge only after a durable record and scheduled work exist |
| Email alert on error | Someone is watching and knows what to do | Alert fatigue, unowned failures, no audit trail | Every failure enters a lane with an owner and a time limit |
| Park failures in a dead-letter queue | Isolation equals resolution | Messages sit for weeks. Nobody knows the business impact. | Queue plus runbook plus owner plus age limit |
| Deduplicate by content (same customer, SKU, quantity) | Identical content means a duplicate | A legitimate repeat order is suppressed, or a changed order is treated as the same one | Deduplicate by durable operation identity, not by guessing from content |
| Support re-keys the order by hand | The original is definitely dead | The original resurfaces later and both ship | Close the original operation explicitly before manual replacement |
A dead-letter queue is a useful mechanism. Services such as Amazon SQS dead-letter queues isolate messages that repeatedly fail so they do not block healthy traffic. That is the whole promise. It is scoped to that messaging service, and it says nothing about who reviews the message, what the customer was promised or whether the underlying operation partly succeeded.
An Illustrative Workload Calculation
The following numbers are illustrative assumptions, not measurements from any customer. Suppose a business receives 2,000 orders a day and 0.5% hit an ambiguous failure that needs a person to reconcile. That is 10 cases a day. At 12 minutes per case, the team spends about two hours daily on reconciliation. If the ambiguous rate were 2%, the same assumptions produce 40 cases and roughly eight hours a day, which is a full-time role. Replace these inputs with your own figures. The point is that exception volume is a staffing and cash-flow variable, so someone in operations has to budget for it.
A Proposed Four-Lane Outcome Model With Named Owners
Key takeaway: Give every integration message one of four lanes: Confirmed, Rejected, Unknown or Held. The lane decides who acts and what they are allowed to do.
The model below is a proposed design for you to adapt. It is not a certified method and not something every vendor implements natively. Its purpose is to replace the binary "success or error" view with a vocabulary operations can run on.
| Lane | Meaning | Evidence to enter | Owner | Allowed next step | Never do |
|---|---|---|---|---|---|
| Confirmed | The ERP record exists in the expected state | Target-side confirmation tied to the operation identity | Automated, with sampled audit by operations | Close operation, notify downstream systems | Infer success from a network status alone |
| Rejected (terminal) | The target definitively refused the operation, or retries and age limits are exhausted with a verified absence of effect | Explicit rejection code, or verified "no such operation" after reconciliation | Process owner for that flow (for example, order desk lead) | Correct data and submit as a new, linked operation | Edit and replay under the same identity with a changed payload |
| Unknown | Completion could not be confirmed. It is not success and not verified failure. | Timeout, lost response or expired worker claim | Integration on-call, escalating to the process owner on a time limit | Query authoritative operation state, then act on what it returns | Blindly retry or re-key by hand |
| Held (uncertain input) | The input arrived but cannot be trusted enough to post | Failed validation, ambiguous customer match, low-confidence extraction | Business owner of the data (for example, customer master steward) | Human review, then release as a new or corrected operation | Auto-post a consequential change from uncertain input |
Handling Unknown Correctly
Unknown is the lane most teams do not have, and it is the one that causes the duplicates. When a call that creates or changes something consequential times out, the safe sequence is:
- Freeze the operation. Mark it Unknown and stop automatic resubmission.
- Ask the authoritative system. Query the ERP by the operation identity, not by guessing from customer and amount.
- Act on the answer. If the ERP shows the record, move to Confirmed. If the ERP positively shows no such operation and the original claim has expired, resubmit under the same identity so the target can still reject a duplicate. If the ERP cannot answer, escalate to a person with a time limit.
- Record who decided and why. This is your audit trail when finance asks about a duplicate invoice.
Terminal Failure and Uncertain Input
Two further rules complete the model. First, retries need an end: a maximum attempt count and a maximum age, after which the operation moves to a lane with a human owner instead of looping forever. Second, uncertain input is quarantined, not guessed at. This applies with extra force when an automated agent extracts an order from an email or a PDF. Our article on AI-initiated ERP transactions covers the matching control framework from the CIO's side.
The Controls Behind the Model: What to Ask Your CIO and Your Vendor
Key takeaway: Five controls make the four lanes real: verified acknowledgment, tenant-scoped idempotent identity, atomic claiming, conditional writes in the target, and privacy ownership. You do not need to build them. You need to see them tested.
| Control | Plain-language question for the CIO or vendor | Evidence that answers it |
|---|---|---|
| Verified acknowledgment | When do we tell the sender "we have it"? | A crash test: kill the receiver between receipt and commit. No order may be lost. |
| Operation identity and payload hash | What stops the same order being created twice, and what happens if the same ID arrives with different contents? | Test that resends return the recorded outcome and that a changed payload is rejected |
| Atomic claim | Can two workers process the same operation at once? | A concurrency test with parallel workers on one operation |
| Conditional mutation in the target | Does the ERP itself refuse a stale or conflicting update? | Version or condition check enforced by the target, or a disclosed serialization limit |
| Privacy ownership | Who retains, redacts and can read the stored payloads and failure logs? | Written retention and access rules covering the inbox, the dead-letter store and the logs |
1. Verified Acknowledgment
Acknowledging a delivery tells the sender to stop retrying. That is only safe after the receiver has durably recorded the message and scheduled the work, and those steps must be atomic or explicitly recoverable. If the receiver replies first and crashes, the order exists nowhere. If it commits first and crashes before replying, the sender retries and the duplicate is recognized. The second failure is harmless. The first is not. Providers differ in how they define delivery and retry, so check the documentation of each sender you rely on.
2. Tenant-Scoped Identity Bound to an Immutable Payload Hash
A durable operation identity should combine the tenant or legal entity, the source system and the source's own operation identifier, and be stored with a hash of the approved payload. Two properties follow. A resend of the same payload returns the recorded outcome. A reused identity with a different payload is rejected and flagged, never silently applied or overwritten. Payment APIs offer a familiar example: Stripe's documentation on idempotent requests describes comparing the incoming parameters to the original request and returning an error when they differ. That behavior is specific to that provider's API, and keys are not retained forever, so design your own store to outlive a vendor's key retention window.
Standards help but must be scoped. HTTP semantics in RFC 9110 define which methods are idempotent at the protocol level, but protocol idempotency does not guarantee business-level idempotency for your order-creation endpoint. A separate Internet-Draft, the Idempotency-Key HTTP header field, proposes a header for HTTP APIs. Treat it as a draft aimed at that transport. It does not cover message queues or file transfers, so check its current status before citing it in a requirement.
Finally, distinguish legitimate later operations. A customer who reorders the same item next week, or an amendment to an open order, must produce a new identity (for example, the source order number plus a revision), not be swallowed by deduplication.
3. Atomic Claiming
If two workers pick up the same operation, you have created your own duplicate. The claim must be a single atomic step in the data store, with an expiry so a crashed worker does not hold work forever. An expired claim moves the operation to Unknown, not back to pending, because the crashed worker may have already changed the target.
4. Conditional Mutation in the Target
"Read, compare, then write" is not compare-and-swap. Between the read and the write, another process can change the record. Real protection means the target system enforces the condition during the write, for example a version check that updates zero rows if the version moved. If your ERP or connector cannot offer that, require the vendor to disclose the serialization and conflict limitations in writing, and compensate with process controls such as single-writer queues for that object.
5. Privacy Ownership
An order number, an email address, a device serial or a customer ID can each identify a person or reveal business relationships. Inbox tables, dead-letter stores and debug logs quietly accumulate them. Assign one owner for retention, redaction and access across all three, and decide whether payloads are stored in full or by reference. Frameworks such as the NIST Privacy Framework offer a neutral vocabulary for that conversation. Your own legal obligations depend on your jurisdiction and contracts, so take them to counsel.
Illustrative Sketch: Atomic Record, Claim and Conditional Write
The sketch below is illustrative, PostgreSQL-style pseudocode. It is not an ArionERP API contract and does not describe any specific product's behavior. It shows the shape of the invariants: one transaction records the operation and schedules work before anything is acknowledged, a payload hash detects changed-payload reuse, workers claim atomically, and the final write is conditional.
-- ILLUSTRATIVE ONLY: not an official API contract. -- Step 1: durable, tenant-scoped inbox record + work item in ONE transaction. BEGIN; INSERT INTO integration_inbox (tenant_id, source_system, operation_id, payload_sha256, state, received_at) VALUES ($1, $2, $3, $4, 'received', now()) ON CONFLICT (tenant_id, source_system, operation_id) DO NOTHING; -- Application checks the row: same hash returns the recorded outcome; -- a different hash is rejected as a conflict and flagged. No mutation either way. INSERT INTO integration_work (tenant_id, source_system, operation_id, state) VALUES ($1, $2, $3, 'pending') ON CONFLICT (tenant_id, source_system, operation_id) DO NOTHING; COMMIT; -- Acknowledge delivery to the sender ONLY after COMMIT succeeds. -- Step 2: atomic claim so concurrent workers cannot take the same operation. UPDATE integration_work SET state = 'claimed', claimed_by = $worker, claim_expires_at = now() + interval '2 minutes' WHERE (tenant_id, source_system, operation_id) = ( SELECT tenant_id, source_system, operation_id FROM integration_work WHERE state = 'pending' ORDER BY created_at FOR UPDATE SKIP LOCKED LIMIT 1) RETURNING tenant_id, source_system, operation_id; -- Step 3: conditional mutation enforced by the target itself. UPDATE sales_order SET status = 'released', version = version + 1 WHERE tenant_id = $1 AND order_id = $2 AND version = $3; -- Zero rows affected means a conflict: do NOT report success. -- An expired claim moves the operation to UNKNOWN and requires -- reconciliation of the target's state before any redo.The Mandatory Go/No-Go Control Set
Key takeaway: Every control below is required for the flow in scope. A single failure is a no-go for that flow. There is no weighted score, because a high total can hide one fatal gap.
Use this as a pre-go-live gate for each integration flow, such as storefront orders, inventory publication or shipment confirmation. Run it per flow because a control that holds for one interface may not hold for another. Passing the set means the known gaps in the tested flow are closed under the tested conditions. It does not certify the system as production-ready in general, and it does not replace security review, load testing or legal advice.
| # | Control (all required) | Evidence before go-live | No-go if |
|---|---|---|---|
| 1 | Verified acknowledgment | Crash test between receipt and commit loses nothing | The sender is told "received" before a durable record and scheduled work exist |
| 2 | Tenant-scoped operation identity | Test with identical source IDs from two tenants or legal entities | Identities share one global namespace |
| 3 | Immutable payload hash binding | Changed-payload reuse is rejected and logged | A reused identity with new contents is accepted or overwrites |
| 4 | Atomic claim | Parallel-worker test shows exactly one claimant | Two workers can process one operation |
| 5 | Conditional mutation or disclosed limits | Target-side version or condition check, or written serialization disclosure | Read-compare-then-write is presented as safe concurrency control |
| 6 | Unknown-state reconciliation | Documented query of authoritative operation state, tested with injected timeouts | Consequential timeouts are retried without reconciliation |
| 7 | Terminal failure rule | Maximum attempts and age defined, reason codes recorded, owner notified | Retries can loop indefinitely or failures end with no owner |
| 8 | Uncertain-input quarantine | Invalid or low-confidence inputs land in Held and need a human release | Consequential changes post automatically from uncertain input |
| 9 | Legitimate later operations | A genuine reorder and a genuine amendment are both accepted with new identities | Content-based deduplication blocks valid repeat business |
| 10 | Named owners and time limits per lane | Owner, queue and response time written down and rehearsed | A lane has "IT" or "the team" as its owner |
| 11 | Privacy ownership | Retention, redaction and access rules cover inbox, dead-letter store and logs | Full payloads with personal identifiers persist with no owner or expiry |
| 12 | Replay drill without side effects | Messages replayed in a sandbox do not send notifications, ship goods or post money | Replay in testing can trigger real-world effects |
How to Read the Result
- All twelve pass for the flow: proceed to a limited production release with monitoring, not to full volume.
- Any control fails: the flow does not go live. Fix, retest and rerun the whole set, because fixes can break neighboring controls.
- A control is "not applicable": write down why and who approved it. Unwritten exceptions become failure patterns.
Before you start, our ERP implementation checklist can help you place this gate inside the wider project plan.
Why This Fails in the Real World
Key takeaway: Capable teams fail here because success is defined at the network layer, ownership is split between IT and operations, and testing covers the happy path. These are system gaps, not people gaps.
The scenarios below are illustrative composites of well-known failure patterns. They are not reports about a specific customer, and the figures are not measured results.
Scenario 1: Acknowledged, Then Lost
A receiving service answers the sender's webhook with a success code as soon as it parses the request, then writes the order to the ERP in a background step. During a deployment, the service restarts between the reply and the write. The sender sees success and never retries. The customer paid. The order exists nowhere. It surfaces days later as a complaint.
Why intelligent teams still miss it: the reply code was visible in every test and every dashboard, while the ordering of "reply" and "durable write" was invisible. Nobody owned the question "when do we say we have it?"
Scenario 2: The Timeout That Became Two Shipments
A connector calls the ERP to create a sales order. The ERP creates it, but the response is lost. The connector's retry policy fires, and a second sales order is created. The warehouse picks both. Customer service spends an afternoon on returns and a credit note.
Why it happens: the retry policy was configured as a generic setting for all calls. Nobody classified order creation as consequential, so nobody required reconciliation of the operation's state first.
Scenario 3: The Dead-Letter Queue Nobody Owns
Failed messages accumulate in an isolated queue by design, and the queue is technically healthy. Business owners assume IT is working through it. IT assumes the order desk will tell them what matters. Weeks later, a month-end review finds shipped goods with no invoice.
Why it happens: isolating failures was treated as handling them. No lane had an owner, an age limit or a business impact view.
Scenario 4: The Clever Deduplicator
To stop duplicates, a team suppresses any order with the same customer, SKU and quantity within 24 hours. A genuine repeat order from a distributor, placed the same day for a different delivery site, is dropped. The distributor discovers the gap when stock does not arrive.
Why it happens: deduplication by content infers intent. Durable operation identity records intent, and a later legitimate operation carries a new one.
| Pattern | Root cause (system level) | Control that addresses it |
|---|---|---|
| Acknowledged, then lost | Success defined at the HTTP layer | Controls 1 and 12 |
| Timeout becomes two shipments | Generic retry on a consequential mutation | Controls 2, 3, 6 |
| Unowned dead-letter queue | No lane owner or age limit | Controls 7 and 10 |
| Clever deduplicator | Intent inferred from content | Controls 2 and 9 |
| Sensitive payloads kept forever | No privacy owner for the inbox and logs | Control 11 |
A Lower-Risk Rollout and How ArionERP Fits
Key takeaway: Roll out one flow at a time, with injected failures in a sandbox and a reconciliation period in parallel. Compare platforms on what they publish and what they will commit to in writing, not on integration slideware.
A Phased Rollout Sequence
- Define lanes and owners. Agree on the four lanes, the response time for each and the person accountable. Write the Unknown-state procedure for every consequential flow.
- Test with injected failures in a sandbox. Drop responses, restart receivers mid-request, send duplicates, send the same identity with a changed payload and run parallel workers. ArionERP's API page states that every developer account gets an isolated sandbox with separate keys, which suits this kind of testing.
- Run in parallel. Keep the legacy process live while the new feed runs, and reconcile counts and values daily. Differences are your real exception rate.
- Release a limited scope. Start with one channel, one site or a low-risk product family. Review lane volumes and ages weekly.
- Expand only after the gate holds. Rerun the twelve controls before adding the next flow. Our overview of integrating eCommerce with ArionERP is a useful starting reference for the first storefront flow.
Comparing Platform Postures: Tier-1 ERP, Mid-Market ERP and ArionERP
The table describes evaluation posture, not a product ranking. Capabilities vary by edition, version and the middleware used, so every cell in the first two columns is a prompt to verify. The ArionERP column separates what the company publishes from what you should obtain in writing.
| Evaluation question | Tier-1 ERP suites (SAP, Oracle, NetSuite class) | Typical mid-market ERP | ArionERP |
|---|---|---|---|
| Integration surface | Broad native tooling and large partner ecosystems are common. Confirm which pieces are licensed and which are separate middleware. | Varies widely. Many rely on connectors of differing depth. | Published: RESTful API with JSON, webhooks for event subscriptions (the page cites examples such as 'invoice.created' and 'inventory.updated'), OAuth 2.0, a pre-built connector library and custom integration services. See ArionERP integrations. |
| Exception tooling evidence | Ask for replay, dead-letter and reconciliation behavior per interface. | Ask whether failed messages are visible, searchable and replayable. | Not specified in the public pages reviewed. Request written answers on retry behavior, idempotency semantics, duplicate handling, webhook signing and replay for each interface you plan to use. |
| Deployment and privacy ownership | Cloud, hybrid and on-premises options vary by product line. | Often cloud-first. Check on-premises availability. | Cloud (SaaS) and on-premises. For on-premises, the ArionERP security page states data is hosted on your own infrastructure, so retention of inbox and log data is yours. For cloud, it states ArionERP acts as a data processor and offers a Data Processing Addendum. Your obligations as controller remain yours. |
| Assurance statements | Review the vendor's current reports and scope. | Review current reports and scope. | The security page states SOC 2 Type II compliance and ISO/IEC 27001 certification, with the SOC 2 report available under NDA. These are vendor statements about the vendor's own controls and scope. They do not cover your integration code, your middleware or your legal obligations, so read the report scope. |
| Implementation effort | Often larger programs with specialist partners. | Varies with customization depth. | Fixed-fee implementation packages exist, and industry packs add scope. Confirm how many interfaces and which exception procedures are included. |
Two practical checks follow from the table. First, ask which plan tier includes API access and webhook capacity, since packaging affects what your integration can use. Second, ask for the written answer to control 6: how does an integrator determine, by operation identity, whether an ambiguous create request took effect? If the answer is a workaround rather than a documented capability, you have learned something valuable before signing.
For connectors that serve production planning, quality and traceability, review how ArionERP positions its manufacturing ERP modules alongside your shop-floor systems. If you are still comparing vendors, our ERP comparison page sets out the evaluation criteria in one place.
Will your next integration fail loudly or quietly?
Quiet failures cost the most. Pressure-test your order and inventory flows against the twelve controls before go-live.
Bring your flows. We will walk the failure cases with you.
Contact UsConclusion: Five Actions Before the Next Integration Goes Live
Integration exceptions are guaranteed. What is optional is whether they end in a defined outcome with an owner. Use the following steps as guidance for your next flow.
- Adopt the four lanes for one flow. Pick the most consequential feed, usually customer orders, and document who owns Confirmed audits, Rejected corrections, Unknown reconciliation and Held reviews.
- Write the Unknown procedure on one page. It should say how the authoritative operation state is queried, how long a hold may last and who decides when the system cannot answer.
- Run the twelve-control gate with injected failures. Insist on evidence from tests. Treat any failed control as a no-go for that flow and rerun the whole set after fixes.
- Name the privacy owner for stored payloads and logs. Decide retention and redaction, and take jurisdiction-specific questions to counsel.
- Get vendor answers in writing. For every platform in the shortlist, request documentation on idempotency, retries, replay, conflict handling and plan-level API access, and file the answers with the project record.
About the Authors and Review
ArionERP is an AI-enhanced, modular ERP platform available as cloud (SaaS) and on-premises, built by Cyber Infrastructure (CIS), a software engineering company operating since 2003. ArionERP was launched in 2016 and serves small and mid-market organizations, with a focus on manufacturing. The company's published security page states ISO/IEC 27001 certification and SOC 2 Type II compliance, and its certifications page lists CMMI Level 5. These statements are the vendor's own and are scoped to the vendor's organization and systems, so review the reports and scope for your own due diligence. Reviewed by ArionERP Expert Team.
Frequently Asked Questions
What is ERP integration exception handling?
It is the set of rules, tools and owners that decide what happens when a message between your ERP and another system fails, repeats, times out or arrives with questionable data. Good handling ensures every message ends in a defined outcome, duplicates are harmless and each failure has a named owner and a time limit.
Why shouldn't we simply retry a timed-out request?
A timeout means you do not know whether the target applied the change. For consequential operations such as creating a sales order or posting inventory, a blind retry can create a duplicate. Reconcile the authoritative operation state first, using the durable operation identity, and only then decide whether resubmission is needed.
What does an Unknown state mean, and how long should it last?
Unknown means completion could not be confirmed. It is not success and it is not verified failure. Set a time limit based on business impact, for example shorter for same-day shipments, after which the operation escalates from the integration on-call to the process owner.
Is an idempotency key enough to prevent duplicates?
Not on its own. The key must be scoped to the tenant or legal entity, tied to an immutable hash of the approved payload, stored durably, claimed atomically by workers and honored by a target that rejects conflicting writes. A reused key with different contents should be rejected, and legitimate later operations must receive new keys.
Does an HTTP Idempotency-Key header solve this for all integrations?
No. The Idempotency-Key header is described in an Internet-Draft aimed at HTTP APIs, so it does not apply to message queues, file drops or database links. Even for HTTP, it only helps if the server implements the behavior correctly. Check the draft's current status and the vendor's documentation before writing it into a requirement.
Does a SOC 2 or ISO 27001 statement from the ERP vendor cover our integrations?
Generally not. Those statements describe the vendor's controls within a defined scope. They do not cover your middleware, custom code, storefront or the way you store payloads and logs. Read the report scope, and assign ownership for your own components. Legal obligations depend on your circumstances, so consult counsel.
Does the cloud versus on-premises choice change who owns exception data?
It changes where the data lives and who operates the infrastructure. With on-premises deployment, your team hosts and controls retention for inbox, dead-letter and log data. With cloud, the vendor operates the platform under a contract such as a data processing addendum, but you still define what your integrations store and for how long. Either way, assign a named privacy owner.
What can we verify about ArionERP's integration capabilities today?
ArionERP's public pages describe a RESTful JSON API, webhooks for event notifications, OAuth 2.0 authentication, a sandbox for developers, TLS 1.2 or higher for API traffic and a connector library, with custom integration services. The pages reviewed do not specify idempotency semantics, webhook retry or signing behavior, or replay tooling. Request written answers on those points for each interface you plan to use.