Business software and connected systems explained

A business system is records, actions, states and ownership

Five things describe almost any business system. Actors are the people and services that do something. Applications create and hold records. Records are what the business actually argues about: a customer, an order, a stock movement, an invoice. States show where a record has reached, such as quoted, confirmed, dispatched or paid. Ownership names the one place a fact is authoritative when two systems disagree. Integrations are the wiring that carries information between applications, and evidence is what proves any of it happened.

That is a planning model, not a description of how any particular product behaves. It earns its keep by making the expensive questions visible early: which record is the master, which state change is allowed to whom, and what will actually be inspected when two systems disagree next quarter. The four questions below follow from it, and deeper implementation topics sit beneath each one rather than inside this page.

Map applications, records, states and evidence before choosing software

Before comparing products, write the workflow out with the same fields every time. For each step, record the actor, the application, the record created or changed, the identifier that record carries, the state it moves into, the owner of that record, the trigger that starts the step, the destination the information travels to, and the evidence that would prove the step ran.

The identifier matters more than it looks. One business event often creates or updates records in several applications at once, and a shared reference carried on every copy is the only reliable way to follow it afterwards. Evidence means identifiers, state history, timestamps, exception notes and reconciliation observations: things somebody can go and look at, rather than an assurance that the integration is fine. Note that the cross-application flow you sketch is a proposal about how your business should work, not a behaviour every product provides.

Two related jobs stay outside this exercise. Detailed entity modelling, where every field and relationship is designed, is separate work. So is the organisation-specific decision about who owns which record, which needs the people who will live with the answer in the room.

How do CRM, ERP and accounting systems differ?

Separate the categories by the work they coordinate and the records they own, not by the vendor's name for them. IBM describes enterprise resource planning as "a business management software system that is designed to manage and streamline an organization's functions, processes and workflows with automation and integration", built from modules that "are all connected and share one common database", and places accounting as "just one module in a long list of other features that ERP technology can provide". Odoo's CRM documentation describes CRM work as organising sales activity: tracking leads, closing opportunities, keeping a pipeline and producing forecasts, alongside tasks such as merging similar leads and opportunities.

In practice the boundary is drawn by your own process. A business that quotes, reserves stock and invoices in one place has a different map from one where three teams each work in their own tool, and both are legitimate. The useful next decision is not which product is best in general, but whether one system should cover the whole flow or whether a specific gap needs building around what already works.

What an API does, and how a webhook differs

IBM describes an API as "a set of rules or protocols that enables software applications to communicate with each other to exchange data, features and functionality", working as a request and a response: one system asks, the other answers, according to a specification that fixes the data types, commands and syntax both sides agree on. That is a pull, and somebody has to decide when to ask.

A webhook is the push, and the provider-specific detail is where the real design lives. Stripe documents registering an HTTPS endpoint so that it "pushes real-time data to it when events happen", sending each event as a JSON payload. Its guidance is worth reading closely because the same concerns recur with any provider: every event is signed, so the receiver verifies the signature before acting on it; endpoints "might occasionally receive the same event more than once", so the advice is to log the event identifiers already processed and skip repeats; delivery order is not guaranteed, so a handler must not assume events arrive in the order they were created; failed deliveries are retried with an exponential backoff; and the endpoint "must quickly return a successful status code (2xx) before any complex logic that could cause a timeout", doing the real work on an asynchronous queue.

File transfer behaves differently again. Odoo documents importing a spreadsheet in which an External ID decides whether a row updates an existing record or creates a new one, which is what makes it possible to "import the same file several times without creating duplicates", and it warns that imports "are permanent and cannot be undone". That is one product's import, not a definition of every scheduled transfer. Before choosing between the three mechanisms, settle five things: what triggers the exchange, which direction it runs, how fresh the data has to be, what happens when it fails, and who reconciles the two sides afterwards.

How permissions and workflow states interact

Identity, permission and state answer three different questions, and a system that merges them either blocks the wrong people or lets the wrong change through. Authentication asks who this is. Authorisation asks what this role may do. State asks whether the record has reached a stage where that action still makes sense. Somebody can be correctly signed in, hold the right role, and still be wrong to amend an order that has already shipped.

Odoo's documentation shows one product's way of splitting this, and the shape is common. Access rights control broad create, read, write and delete permissions at the model level, while record rules act as an additional layer restricting access to specific records by condition, and user types run from administrator through internal user to portal and public. The same documentation carries a blunt caution that changing access rights "can have a detrimental impact on the database", including leaving nobody able to change them back. State-gated behaviour appears elsewhere in the same product: reservation methods decide when stock is committed to a delivery, whether at confirmation, manually, or a set number of days before the scheduled date.

The handoff to a deeper permission design is short. For each role, write the resources it may touch, the state transitions it may perform, and the path by which its access is removed when somebody leaves. Those three lines are what a detailed access model is built from, and writing them costs an afternoon.

Diagnosing duplicate records and integration failures

The wholesale business below is invented for teaching. A salesperson agrees an order, a warehouse clerk reserves and dispatches it, and a finance operator records the payment. Every role, policy and system response is an assumption, and the final column lists evidence to collect, never a result already obtained.

When something goes wrong, a proposed sequence beats intuition. Establish the business event and its date. Collect the identifier that event carries in each application. Identify which system owns each record. Compare the states and the timestamps side by side. Inspect the delivery or transformation evidence, which for an event-based integration means the event identifier and its delivery status, and for a file-based one means the imported file and its identifier column. Classify the exception: a duplicate, a missed delivery, a rejected payload, a transformation error or a human entry mistake. Then define the reconciliation test that will prove the fix, and run it.

Duplicates deserve their own note, because the same symptom has several causes with different fixes. Odoo documents merging similar leads and opportunities as a normal CRM task, which addresses duplicates people created by hand. A repeated webhook delivery is a different problem, solved by recording event identifiers rather than by merging anything. A re-run import without a stable identifier is a third. Treating all three as one deduplication job is why the same duplicates come back next month.

What to do next

1. 1Take one business event that crosses more than one application and write it out step by step, with the actor, record, identifier, state, owner and evidence at each step.
2. 2Mark the single authoritative system for each record in that flow. Where two systems both claim one, that disagreement is the work.
3. 3For each connection, state the trigger, the direction, how quickly the data has to arrive, what happens on failure, and who reconciles the two sides.
4. 4Write the acceptance evidence before any product shortlist exists, so demonstrations are judged against your workflow rather than the vendor's.