MYOB Exo Integration and Automation

Exo sites can expose a service layer for integration, and where it is available and licensed it is the right door for anything that writes. Coverage is narrower than a modern cloud ERP, so a realistic design usually combines a supported interface for writes with read only database access for the queries that need speed and flexibility. The first thing we do on an Exo project is establish exactly what is installed, licensed and reachable on your site, because the answer varies more between Exo installations than most people expect.

Reading is generally safe and very useful, provided it is genuinely read only, uses an account with no write permissions, and is written with an eye on load so a heavy query does not slow the system for users at nine in the morning. What is not safe is writing. Inserting rows to create orders or invoices skips the logic that keeps the ledger, the document numbering and the audit trail correct, and the resulting mess is usually found weeks later. We use read only access deliberately and never as a substitute for a supported write path.

Yes, and it is one of the strongest reasons to integrate. The important part is resolving price the way Exo does rather than approximating it, which means honouring policies, customer groups, quantity breaks and effective dates for the specific account and quantity in the cart. We generally resolve live at the point it matters and cache with a short expiry so the store stays quick, and we handle the case where a customer is on credit stop by showing a clear message rather than an error page or, worse, an order you cannot fulfil.

Usually not, because the manual handling is costing you money now and a migration is rarely as close as it feels. The right response is to build so the move is survivable: keep field mappings, price logic and exception rules in an integration layer, avoid embedding Exo specific assumptions in the store or the warehouse tools, and document the ownership decisions. Done that way, changing ERP replaces one side of each connection while the channels, the scanners and the customer facing behaviour stay as they are. That is a materially smaller project than a rebuild.

With an outbound connection rather than an inbound hole. Typically a small agent or a properly configured tunnel initiates the connection from your network to the managed layer, so no database port is exposed to the internet, and the integration authenticates with a least privilege service account created for the purpose. We keep separate credentials for test and live, log access at record level, and can tell you exactly what data crossed the boundary and when, which is what you need to be able to answer under the Australian Privacy Principles.

Because Exo does not announce changes, the practical cycle depends on how you detect them and how much load the queries put on the server. Frequent incremental checks on a narrow, well indexed query every few minutes are usually comfortable for availability on fast moving lines, while a full comparison sweep is better scheduled outside trading hours. In practice most distributors land on a short cycle for stock and order status, a slower cycle for product and price changes, and an immediate push for anything a customer is waiting on. Matching the frequency to the actual business need keeps both the server and the cost sensible.

For some combinations, yes, and if one covers your requirement we will say so rather than quote a build. Packaged connectors tend to be strongest on straightforward business to consumer flows: orders in, stock out, a simple invoice back. They tend to struggle with customer specific price policies, multiple branches, serial and batch capture, local customisations and the exception handling that account based trading needs. The honest test is to list your awkward cases first and check them against the product, rather than checking the happy path and hoping the rest is configuration.