A link is meant to save you work. You want to be able to update information in one place and trust that it will end up in the right place. However, this requires a few clear agreements up front.
Where do you make a change? Which system needs to update it? And what happens if someone changes the information on both sides?
Those are the questions I would address first before we build an integration. Otherwise, you’ll end up exchanging data while your employees still have to figure out which version is correct.
Start with the work that needs to be made easier
First, write down which task you’re currently performing twice. What information are you transferring, who is doing it, and when will it be useful to the next employee?
A list of all available data is not yet a work process. You want to know what needs to happen after a change and what information is actually required for that.
When developing custom software, we use a specific action like this as a starting point. This allows you to determine what the integration needs to address and which components you can leave as they are for now.
For each piece of data, determine where to adjust it
One system doesn't have to be the primary source for all information. For example, you can manage a description in one environment, while another environment determines the status associated with the task.
Record that information for each component. An employee must be able to see where a change belongs. The other system will then transfer that information according to the agreed-upon procedure.
This also requires a decision when both sides can make adjustments. Can an automatic update replace a manual correction? Or should that correction remain in place until someone intentionally disables the protection?
I wouldn't base that decision on which system happens to send a message last. Agree on which source takes precedence and make any discrepancies visible. That way, you'll also know where to fix an error.
Distinguish between missing and deleted information
Suppose a system doesn't include a description with an update. Does that mean the description should be removed? Or does it simply mean that part wasn't included in this update?
The link must be able to handle that difference. Otherwise, an incomplete update could delete information that is still perfectly usable.
Therefore, agree separately on how an actual deletion is communicated. Missing information, a field that has been intentionally left blank, and a deleted entry can represent different situations. Defining in advance what each case means makes it easier to monitor the processing.
Keep current data and previous entries separate
Changes you make today do not have to be applied retroactively everywhere.
For example, a document sent earlier may need to retain the information that was current at that time. The current overview, however, may be updated in the meantime.
Keep that in mind during the design process. What information needs to stay up to date at all times, and what constitutes a completed action? If a correction is needed, you want to be able to make it intentionally and track what has been changed.
This prevents a routine change from inadvertently altering your previous entries as well.
Show what has actually been processed
Just because a system is running doesn't mean the last change was successfully applied. Even a successful connection doesn't prove that all the intended information has been processed.
That’s why, in management, you want to be able to see when something last went well and which part still needs attention. If information isn’t available, that should also be made clear. An unknown status shouldn’t be treated as a reassuring checkmark.
Also, discuss how quickly a change is typically applied. Does it happen immediately after an action, or at set intervals? That way, you'll know when it's normal to wait and when someone needs to check.
When it comes to automation, that explanation is part of the setup. You need to be able to assess for yourself whether the work is proceeding as agreed.
Agree on who will handle any discrepancies
Not everyone needs to be able to adjust settings or restart a process. For someone who only performs day-to-day tasks, a clear notification may be sufficient.
Determine who will investigate the cause and who is authorized to make a correction. If the outcome is unclear, first check what has already been done on the other side. Then you can determine what next steps are needed.
Those agreements also help with the handoff. If the regular employee is absent, a colleague should be able to see what’s going on and who to turn to.
First, work through one data stream
You don't have to include every possible exchange right away. Choose one recurring action and describe where the information starts, where it ends up, and what you want to be able to monitor there.
Before development begins, also verify that the existing systems provide the necessary access and functionality. Just because a piece of data appears on a screen does not automatically mean that an integration can read or modify it.
With this kind of scope definition, you can start small and expand later. Would you like to know what’s possible with your systems? Feel free to contact us. We’ll work with you to determine what information you want to integrate and what arrangements are needed to do so.