Systems/Data Integration
Unifying the Data:
From stale copies to a live connection
On paper it's an optimization problem. In practice, the whole thing turned on trust.
Visuals have been white-labeled to protect client confidentiality
Impact at a glance
What used to mean schedulers manually copying the same data between systems now syncs automatically, taking that duplicate entry out of the job entirely
Eliminated stale, hand-copied data by making every field live and traceable to its source
Aircrew see the same authoritative data schedulers do, so requests come in grounded in the current picture rather than assumptions
Highlights
- Reframed a data import as a living connection: every field traceable to its source and visibly current
- Drew a clear ownership line between source-owned and locally-owned fields, so edits never silently fought the sync
- Designed the sync model with engineering (cadence, per-field conflict resolution, and permissions) so every promise the surface made, the system underneath could keep
- Made source conflicts reviewable updates instead of invisible overwrites
- Opened trustworthy, permission-aware data up for discovery, so people could find an event and ask to join
Visuals have been white-labeled to protect client confidentiality
Context
I designed the integration that let schedulers pull the source data in automatically.
The harder problem wasn't the pull itself. It was making the incoming data feel current and trustworthy, and putting it where the people it affected could actually see it.
Problem & Opportunity
Before integrations, scheduling an event meant living in multiple systems at once.
The authoritative details sat in a separate system of record; the event itself was built in the scheduling platform. So a scheduler read from one screen and typed into another: re-entering the same information and dates that already existed a tab away. The work was duplicated by definition, and every manual keystroke was a chance to introduce an error the source never had.
The deeper problem showed up the instant the copy was made. A hand-entered field is a snapshot, accurate the moment it's typed and decaying from then on. When the source changed, nothing downstream knew. The scheduled event kept showing details that were quietly, confidently wrong. Automating the pull would stop the typing, but it wouldn't by itself answer the harder question: how does someone trust a field they didn't enter, sourced from a system they can't see?
The opportunity was to stop treating source data as something to copy, and start treating it as something to connect to: live, traceable, and current, and then to put that newly trustworthy data in front of the people looking for it.
Solution / Process
The work split into two layers: what a scheduler experiences on the surface, and the sync model underneath that has to hold for any of it to be true.
Connecting the two systems is where the work began. The pull itself (authenticating to the source, mapping fields, handling the sync) was the part everyone pictured in the beginning.
The experience layer was about trust. Three things had to be legible at a glance:
- Freshness. A copied field is only trustworthy if you can see how current it is, so every imported field carries where it came from and when it last synced.
- Ownership. Once data flows in automatically, the line between what the source controls and what a scheduler can change has to be explicit, or every edit becomes a quiet fight with the next sync.
- Conflict. When the source updates a field someone already relied on, that change appears as a reviewable update, never an invisible overwrite.
None of that holds without the right system beneath it. That's where I partnered most closely with engineering. We designed the sync model deliberately rather than by default:
- Sync cadence. How often and when data refreshed, and what the interface honestly showed during an outage or a lagging source, so "current" never quietly meant "current as of yesterday."
- Conflict resolution. The rule for what wins when the source and a local edit disagree, defined per field rather than globally, so the visible "reviewable update" always had a predictable answer behind it.
- Permissions. Who could see a field, who could change it, and who could act on the event, so the data opened up to the right people without exposing everything to everyone.
With the data finally current, trustworthy, and permission-aware, it could do something it never could as hand-typed text: be found. The same details that used to be locked inside one scheduler's manual entry became a discovery surface — the right people could see what was scheduled and ask to be part of it, turning a private data-entry chore into a shared, opt-in view of what was happening across the organization.
Visuals have been white-labeled to protect client confidentiality
Results
- User impact. What used to mean schedulers manually copying the same data between systems now syncs automatically, taking that duplicate entry out of the job entirely.
- Sync Speed. A change made in the source of truth reaches every connected system in seconds, so teams stop working from a copy that was only accurate whenever someone last hand-carried it over.
- Trust. Schedulers can now see at a glance which values came straight from the source of truth versus which were manually overridden.
- Downstream impact. Aircrew see the same authoritative data schedulers do, so requests come in grounded in the current picture rather than assumptions.
- Accuracy. Removing manual re-entry removed the errors that rode along with it — a value can't be mistyped on the third copy when there's no third copy.
Reflection / What I Learned
The lesson: the pull was the ask, but trust was the product. The integration that moved fields across was the easy half; the value lived in everything that made a field someone didn't type feel as reliable as one they did. Provenance, freshness, ownership, and the sync model underneath them weren't decoration on top of the pull — they were the actual product.
I decided to design the trust model first to scope mvp as a manual pull to ensure that the data being synced was accurate and trustworthy. Once the trust has been built, auto-syncing with notifications will come next.