Connect the Systems You Have Before Building Another App

Picture an administrator with an approved order open in one tab and an empty invoice form in another. They copy the customer's address, check the line items, then message the warehouse to say the order is ready. Nothing about the order needs another decision. It just needs to reach the next system intact.

That is a hypothetical workflow, not a client case study. But it gives a software discussion a useful starting point: which part actually needs replacing?

At Cortex Solution, our business automation service includes connecting systems that do not talk to each other. We also build custom software. Our view is that a request for a new app deserves a look at the handoff first. If the existing tools still do their individual jobs, we would rather scope the connection than assume the whole workflow needs rebuilding.

Keep the screens that still do their job

For the order example, ask the administrator to walk through one record. Where is the order approved? Which details get copied? What does finance check before issuing the invoice? Where does the warehouse acknowledge receipt?

Then separate two problems.

If people trust the order screen and the invoice screen but dislike entering the same information again, investigate an integration. If neither screen can represent the way the business sells or bills, investigate changing the underlying tools. Connecting them should not be an excuse to keep a broken process.

Before commissioning anything, check whether the tools already offer the required connection. Ask for a demonstration using your workflow, not just a tick beside an integration logo. Can it transfer the fields you need, at the right point, into the right status? If it can, there may be no custom build to commission.

Start at “approved”, not “saved”

For this example, we would start with an approved order creating a draft invoice. Finance would still review and issue it. We would not include automatic sending to the customer in the first connection.

Write down what qualifies an order for transfer. Saving an unfinished order should not qualify. Neither should adding an internal comment. Decide how an amendment after approval will be handled, and whether cancellation should stop a pending transfer.

There is a useful boundary in SiteClock, which we built and MySteel operates. Its phone app handles clock-ins, leave requests, claims and approvals; its web console handles payroll, payslips and exports. Claims are decided by a manager, while leave and advances go to the account owner.

That is not a claim that SiteClock connects to your accounting package. It is an example of keeping a decision in the workflow instead of treating every saved record as ready for the next step. For an order-to-invoice connection, we would keep the same distinction: saved is not approved, and transferred is not issued.

Give each field one owner

Before building the connection, make a small mapping sheet. We would use these columns:

This is a proposed design, not a list of features in a Cortex product.

Pay attention to the billing account. Do not ask the integration to guess that two similar company names mean the same customer. Agree an explicit link between the records, and give unmatched customers a review path.

Start with one-way movement where possible. Let the order system own order details and finance own invoice status. If both sides must edit an address, decide which edit wins before enabling that behaviour. “Keep everything in sync” is too vague to approve.

Ask to see the transfer that did not finish

A demonstration should include an awkward case: the invoice system accepts the draft, but the connection does not receive confirmation. What should happen when someone presses retry?

Our acceptance requirement would be one order, one intended draft invoice, even when the transfer is attempted again. Ask the builder to show how the original order reference is connected to the destination record and how that link is checked before another creation attempt. Do not accept “just retry it” as the entire recovery plan.

Give the administrator a visible queue. We would distinguish records waiting to transfer from records transferred successfully, and separate those from records needing a person to act. Each failed item should identify the source order, explain the problem in ordinary language and name the next action.

For a missing billing account, that action might be “link the customer, then retry”. For an uncertain response, it might be “check whether the draft already exists”. Do not make an administrator read a developer's log to decide what to do.

A file handoff may be enough for the first release

Do not specify an instant connection until someone explains why the next step cannot wait.

If finance reviews orders together at a scheduled point, consider an agreed export and import instead. Ask the receiving system's owner for its supported format, then test a representative file. Require clear reporting of accepted and rejected rows, with a reference back to each source order.

SiteClock's web console includes exports for office reconciliation. That does not establish compatibility with another tool; it is a reason to ask what the existing export can support before requesting a new connection.

For either route, verify access before agreeing the scope. Ask the software provider what your subscription permits, whether a test environment is available and who can authorise the connection. Where the proposal relies on operating screens rather than a supported data interface, ask how failures will be detected and what maintenance is included. Our automation service includes RPA for repetitive screen work, but we would still want those questions answered.

Test one order all the way through

Keep the first release narrow enough to inspect. For the example here, we would propose one approved-order handoff into a draft invoice, with customer matching and a review queue. Leave stock updates and payment reconciliation outside that first scope unless they are necessary to complete the job.

Before switching it on, ask the team to demonstrate:

• an ordinary approved order reaching the correct billing account;
• an unknown customer stopping for review;
• an amended or cancelled order following the agreed rule;
• a repeated transfer attempt without an extra draft invoice; and
• a failed transfer being found and resolved by the person responsible.

Agree a fallback too. If staff must create a draft manually during an outage, specify how they mark the source order so the automated path does not create another one later. Name who can pause transfers and who checks the queue before restarting.

We agree a fixed price and timeline after scoping, before building. For an integration discussion, bring a redacted source record, the destination fields and the awkward cases. Those are more useful than a request to “connect everything”. Our fixed-price quote checklist covers what to put in writing once that boundary is clear.

FAQ

Should we replace our existing software first?

Not by default. If the tools handle their own jobs properly, investigate the handoff. If the workflow itself no longer fits, consider changing the tools rather than connecting around the problem.

Does an integration have to run instantly?

We would require that only where the business needs it. For a scheduled review, test whether a controlled file handoff is sufficient before commissioning a live connection.

What should we bring to the first conversation?

Bring a redacted example record, a list of the systems involved and the point where somebody currently copies or rechecks information. Include one exception you want demonstrated before launch.

Unsure whether you need a connection or a new app? Book a free consultation with Cortex Solution and bring the handoff you want to stop doing by hand.