The integration layer is not a separate project.

Inside EAConnect Planning there is an Integrations area with its own Build, Manage and Monitor sections. It is the same product, the same tenant, the same login as the reports and the planning grid. The destination of every pipeline is a planning table in the same workspace.

Two consequences follow that are easy to miss. First, the target of a pipeline is a typed planning table, not a file — so a load either conforms to the table's definition or fails visibly. Second, the process engine that runs data loads is the same engine that later runs budget workflows: the skill a team builds wiring up the ERP transfers directly to governing the planning cycle.

A pipeline is a directed graph of steps — extract this, transform that, validate, load — where each step runs when the steps before it succeed. EAConnect exposes that graph on a canvas at two levels: flows, which move data, and processes, which orchestrate flows with checks and branching.

Figure 3. Flow Builder. A NetSuite master-data flow of three connector tasks in sequence — account list, department list, exchange rates. Flows carry a name, description and group, and can be executed from the canvas while being built.

Each node in a flow is a connector task with its own configuration: which object, which fields, which filters, which target. Flows are grouped and versioned, and — the detail that most shortens the build — they can be run on demand from the same screen, so the loop of "run it, look at the rows, adjust the filter" takes seconds rather than a deployment.

Figure 4. A process. It runs the master-data flow, then a load step that takes the tabular source and writes it to a planning table. The palette on the left shows what else a process can contain.

The word "DAG" — directed acyclic graph — is engineering vocabulary for a simple idea: steps with dependencies and no loops, so the engine always knows what can run next and what must wait. What it buys a planning team is legibility. A month-end load is no longer a script somebody wrote; it is a picture the finance manager can read, with each box's status shown against it after every run.

Two problems appear only after the first month, and they are where most home-grown integrations quietly rot. This section explains them as practice; the platform mechanisms that address them are noted where they have been shown.

Change capture: how much to move, how often

The naive approach re-pulls everything every night. It is correct and, for master data and small ledgers, entirely adequate. It stops being adequate when the general-ledger detail runs to millions of rows and the source API meters requests. The alternatives are to pull only what changed since the last run — which depends on the source exposing a reliable "modified" marker and on deletes being flagged — or to maintain a replicated copy of the source table that receives every insert, update and delete. EAConnect offers a data-replication capability alongside its flows; for most mid-market general ledgers the practitioner's recommendation is incremental loads for detail with a periodic full reconciliation, and full reloads for everything small.

Schema drift: when the source changes under you

Source systems change. A NetSuite administrator adds a custom field; a Xero tenant renames a tracking category; an HRIS upgrade changes a date format. Most integrations discover this when a report is wrong. The right design has three properties: detect the change at the boundary (the target table is typed, so a type change is a rejected load, not a corrupted plan); distinguish the harmless from the fatal (an added column is logged, a removed one stops the process); and route the fatal case to a person, at a named node, before anything is written. In EAConnect the validation monitor is the node that carries these checks, and the alert branch of a process is where the failure lands. The most frequent form of drift — a new department, a merged entity — is not a schema change at all, and is handled by the versioned hierarchies described in the platform's hierarchy article rather than by the pipeline.