Finance, operations and the website each hold a version of the truth, and the reconciliation between them is a person. It works, it is expensive, and it is the kind of cost that never appears on a budget line because it is distributed across six people's weeks.
Get our systems talking to each other.
Re-keying is rarely anyone's decision. It accumulates: a system is bought to solve one problem, another is bought later to solve a different one, and the gap between them is filled by whoever is closest to it. By the time it is visibly a problem, the manual step has been load-bearing for years and several processes depend on its particular quirks.
The cost is not mainly the time. It is that data entered twice is data that disagrees, and once two systems disagree, everyone downstream develops a private opinion about which one to believe. That is where the spreadsheets come from — not from a lack of systems, but from a lack of agreement between them.
The reason it does not get fixed is that integration is usually quoted as a project with no visible output. There is nothing to show at the end, so it loses every prioritisation argument to a feature somebody can see.
Three routes, chosen by what the other system actually allows. Where it has its own database and you have access, that database can be linked directly, so the data is read where it lives instead of being copied. Where two ActiveManage instances need to stay aligned, datastore sync keeps selected data in step between them.
And where something needs to talk to you, the API engine provides ready-made create, read, update and delete endpoints over any data in the application, with token-based clients and call logging — enforcing the same permission rules as the interface rather than being a back door around them. That last point is the one that gets skipped in hand-rolled integrations and is the reason so many of them are quietly a security problem.
Where none of that fits — a supplier with an idiosyncratic format, a partner who can only send e-mail, an EDI trading relationship — custom functions and inbox processing handle it, and the connection is documented configuration rather than a script on somebody's machine.
The unglamorous step that determines whether the project works. For every field that exists in more than one place, one system is authoritative and the others follow. Most failed integrations skipped this and became two-way syncs that fight.
Linking an external database directly means there is no copy to fall out of date and no sync to fail overnight. Where it is available, this is almost always the better answer.
Datastore sync keeps selected data aligned between ActiveManage instances — the normal case where a customer-facing instance and an internal one need to agree without being the same system.
Create, read, update and delete endpoints over your data, with token-based clients and call logging, enforcing the same rules as the interface. An integration account should not be able to see more than a person could.
Inbound e-mail with attachments processed automatically, custom functions for formats nothing off the shelf handles, and EDI over SFTP, AS2 or OFTP2 where you trade that way. The point is that these become configured, documented connections rather than a script nobody can find.
Nothing here is written specially for this use case — it is the same platform every ActiveManage application is built from. The full feature list is on the platform page.
| Feature | What it does | Why it matters here |
|---|---|---|
| External databases | Link a database used by another application directly to the platform. | No copy, no sync window, no overnight job to fail. The best answer whenever it is available. |
| Datastore sync | Link multiple ActiveManage instances and synchronise selected data between them. | Keeps a customer-facing instance and an internal one aligned without merging them into one system. |
| API engine | Ready-made CRUD endpoints over any data, plus custom functions, with token-based clients and call logging. | Same permission rules as the interface. An integration credential that can see everything is a breach waiting for an excuse. |
| Inbox processing | Inbound e-mail fetched automatically and passed, with attachments, to extraction or a custom function. | Some partners will only ever send e-mail. This makes that a supported integration rather than a person with a mailbox. |
| EDI | Trading partners over SFTP, FTPS, HTTPS, VAN, AS2 or OFTP2, with mapped messages and atomic control numbers. | For anyone trading with large retailers or manufacturers, this is a condition of doing business rather than a nice-to-have. |
| Auditing & call logging | Every change recorded with who and when; every API call logged per client. | When two systems disagree, this is how you find out which one changed and what asked it to. |
The one flow costing the most manual effort, in production. Integration earns its budget by removing a job somebody is visibly doing.
The remaining flows, usually much faster, plus the reporting that becomes possible once the data agrees.
Connections are configuration with logging, so when something changes at the other end your team can see what happened without ringing us.
No, and this page is largely about not doing that. An external database can be linked and read in place, so a system that works keeps working and simply stops being an island.
It enforces the same permission rules as the interface, uses token-based clients and logs every call per client. An integration credential cannot see more than an equivalent user could, which is exactly where hand-rolled integrations tend to go wrong.
Then you use one of the other routes: link its database directly if you have access, process the files or e-mail it can produce, or write a custom function for its particular format. Very few systems have nothing at all.
Yes — trading partners over SFTP, FTPS, HTTPS, VAN, AS2 or OFTP2, with mapped messages and atomic control numbers, which is what large retail and manufacturing customers require.
By deciding, before anything is built, which system owns which fact. Two-way sync without that agreement is the most reliable way to produce an integration that corrupts data slowly.
Tell us what you are trying to fix and we will tell you whether this is the right shape for it — including when it is not.