Systems integration so information reaches the people who need it
An order comes in through sales, moves through operations and reaches finance. Solvers connects the systems, APIs, platforms and services your company already uses, with a defined path for information, failures handled and the result validated with the people who use it. Integration starts with your process, not with the tool.
Prefer email? Write to contato@solvers.com.br.
Signs that your systems need to talk to each other
- The same information is typed into more than one system. Correcting a record in one place does not guarantee the others receive the update.
- Each area looks for information in a different tool. Whoever follows the work has to check several places to find the right information.
- One system says “sent” and the other cannot find the record. Without a clear status, each area reads the situation differently and makes a different decision.
- The tools do their jobs well, but don't share the data. The work of carrying information from one to another starts competing for time with customer service.
What goes into an integration project
- Process map: where information is created, who needs it and which system is the reference for each piece of data.
- Information path: what each tool receives to do its part of the work.
- Permissions and record identification: who can change the data and how each operation is recognized.
- Failure handling: clear statuses for each step, alerts to whoever can act and retries without duplicating operations.
- A record of what happened, to investigate a pending item without unnecessarily reproducing sensitive data.
- Tests on the expected path and on the exceptions, with the people who run the process.
- Result criteria and a baseline, to compare the situation before and after.
The magic has a method: understand, build and validate
Before talking about connecting tools, we understand people's work.
- 01
Understand
The process and its exceptions: where the record is created, what information each area receives and what happens when something arrives incomplete, changes or is canceled.
- 02
Build
With clear rules: which system is the reference, permissions, record identification and what to do when a connection doesn't respond.
- 03
Validate
With the people who use it: the expected path and the exceptions, comparing the solution’s behavior with what was defined and fixing discrepancies.
- 04
Track
What changed: manual steps, time spent on a task or how often discrepancies occur, compared with the initial situation.
An integration also needs to know how to fail
Connecting systems requires defining how a pending item will be identified, followed up and resolved. “Sent”, “confirmed” and “awaiting verification” are not the same thing, and the team needs to know when it can move on and when it should wait for a review.
Not every failure calls for the same action. A temporary outage may get a controlled retry; an incomplete record needs to be corrected. And no response doesn't mean not processed: resending without a control mechanism can record twice what should happen only once.
That is why testing doesn’t end when a record makes it through the systems successfully. We simulate interruptions, invalid data, confirmations that never arrive and repeated requests. Read (in Portuguese): what happens when an update fails →
From a closed order to the management system
Imagine that sales closes an order and the information should go to the management system, but the confirmation never arrives. The salesperson sees “sent”, while finance still can’t find the order.
An integration project would define what each status means for each area, who gets the alert when an update is pending and with what guidance, how many retries are made and how to keep the order from being recorded twice. Testing would include the confirmation that never arrives and the resent order.
Fictitious example, to illustrate the method. It does not represent a client case or result.
Questions about systems integration
Do I need to replace the systems I use to integrate them?
Not necessarily. Integration makes sense precisely when the tools do their jobs but don't share the data that is needed. It connects what already works, defining which system is the reference for each piece of information and what each one needs to receive.
Can every system be integrated?
It depends on the capabilities of the systems involved and the access available. That is why this assessment is part of understanding the process, before building. In some cases, configuring the current tool or developing a specific application works better.
What happens when an update fails?
That is defined in the project. The pending item needs to be visible, with a clear status for each area, and the alert should reach whoever can act. Not every failure calls for the same action: a temporary outage may get a controlled retry, while an incomplete record needs to be corrected.
How do you keep the same operation from being recorded twice?
Sometimes the destination processes the request, but the confirmation doesn't reach the source. Resending without control can duplicate the effect. One approach is to identify each request so repetitions can be recognized, depending on the capabilities of the systems involved. Preventing duplicates is part of the integration design and is validated in testing.
How much does an integration cost and how long does it take?
It depends on the systems, the business rules and the exceptions involved. Investment and timeline are estimated after understanding the process and the systems. Starting with the smallest workflow worth solving helps validate the path before expanding.
Learn more
Articles on the Solvers blog, in Portuguese:
Which systems do you need to connect?
Tell us which process goes through more than one tool, where the information is created and who needs it. From there, we assess together whether the best path is to configure, integrate or develop.
Talk about your integration →Or write to contato@solvers.com.br.