The situation
A customer exists in the sales system and in finance, and both are edited. A nightly script pushes changes one way, someone wrote a second script for the other direction, and when both change the same field the last write wins silently. Neither system is agreed to be authoritative, so every disagreement becomes an argument with no evidence.
These are illustrative scenarios showing how the products are used, not customer case studies.
Build-versus-buy lens
What this helps you decide
Use the example to find where product configuration ends and custom code begins — and whether the boundary leaves your team with less infrastructure to own.
- Model fit
- Can the record shape evolve without coordinating a migration, API and UI release?
- Workflow fit
- Can approvals, exceptions and deadlines move out of application code without losing control?
- Integration fit
- Can your existing APIs become reusable steps with retries, throttling and visible run history?
- Control fit
- Can your team reconstruct model changes, workflow runs and human decisions later?
What gets modeled
The structure as it would actually be defined — sections that repeat are marked.
- Customerrecord type
The agreed record — the thing both systems reconcile against
- Identitysection
- External referencesrepeating section
One per connected system, so a match is recorded rather than inferred
- Systemchoice
- External idtext
- Last seendate and time
How it gets built
In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.
Decide what is authoritative, and model it
One record type holds the agreed customer, and external references repeat — one per connected system, recording the identifier rather than inferring it from a name each time. The argument about which system is right becomes a decision made once, in the model.
What it uses: Repeating sections holding one reference per connected system
Register each system once
The sales and finance systems are registered by importing their API descriptions, or authored by hand where there is none, each with its own authentication, retry policy and throttling. Adding a third system is a registration and a mapping rather than a third script.
What it uses: Any API becomes a step, with per-connection authentication and throttling
React to the change rather than sweeping nightly
A change in either system triggers a run over a signed HTTPS call with per-source secrets you rotate, and a record change here triggers the outbound direction. The nightly window stops being how quickly the two agree.
What it uses: Record triggers and signed external triggers
Say where every value comes from
Field-level mapping draws each value from the event, an earlier step’s output, the record, a fixed value or a computed one, with defaults overridden per record type and again per workflow, and a panel showing the result of all three. Mappings are compiled when the trigger is armed, so what runs is what was checked.
What it uses: Layered input mapping, compiled at arming time
Stop the sync loop before it starts
A duplicate of an event already seen is dropped, and a repeated trigger for the same customer hands back the run that is already going. When your own write comes back to you as an event, it does not turn into a second write.
What it uses: Repeat-event recognition, and one run per subject
Send the conflict to a person, not to the last writer
When both sides changed the same field, a conditional link routes it to a human decision with the two values in front of them and your own reason codes. A conflict becomes a decision somebody made rather than a race somebody won.
What it uses: Conditional links, and human decision steps with reason codes
Keep the evidence of every write
History is enabled on the schema, so every write keeps a snapshot and any retained point can be restored. Every change is also published to the event stream in the same transaction as the change, carrying a field-level difference, so a consumer sees what actually changed.
What it uses: Snapshot per write, and events written in the same transaction as the change
Recover the failed direction on its own
Each run is recorded step by step and is findable by the customer it concerns. Recovery is restarting the step that failed or replaying that run — not re-running the night.
What it uses: Per-step run history, and restart, rewind, replay
Numbers used above, and where they come from
Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.
- field types
- 9field typesCounted from egav/backend/app/api/v1/egav/schemas/entity_type_attribute.py — DataType
- destinations for an event
- 4destinations for an eventCounted from egav/backend/app/api/v1/egav/lib/webhook/transports — http, sqs, sns, kafka
What changes
One record is agreed to be authoritative, an echo of your own write is recognised instead of applied, and a genuine conflict is decided by a person with both values in front of them rather than by whichever script ran last.
Written for Integration-heavy platforms.