Pathfinder Spring Release: A Topology Map, Conflict Recipes, and the Honest Demo

In 17 days we shipped 9,800 lines of new Sync UI, replaced the 4-tab dashboard with a topology-first canvas, and rebuilt the conflict-resolution flow around the idea that one good decision should resolve 142 of them. That is the headline. The rest of this post is what it actually looks like, what is live today, and what is wireframe-grade by design.

If you read the April 12 post, you have the foundation. A real sync engine in Rust. Five conflict strategies. A circuit breaker, a rate limiter, RBAC, an audit log, sixteen REST endpoints. 132 audit checks. The bones of a multi-org platform that runs on your hardware with zero data exfiltration. That post described the engine. This one is the dashboard, the Mapping Studio, the Conflict Inbox, the Pair Setup Wizard, and everything an operator actually touches when they sit down to run a sync between two Salesforce orgs.

The thing that changed in 17 days is not the engine. The engine works. What changed is who can use it. April Pathfinder was a tool for the engineer who built it. Spring Pathfinder is a tool you can hand to a Salesforce admin during an M&A integration and have them productive in an afternoon. That is the difference between a code merge and a sellable product, and that distinction is what this release was built around.

Here is what is in this post:

• A new IA built around the topology — Sync became the front door. Map / Pairs / Activity replaced the four engineering tabs. The hero is a Pretext force-physics canvas with frosted-glass org nodes and bezier sync edges that show direction, conflict load, and last-run health at a glance.
• Conflict resolution by recipe, not by row — The Conflict Inbox groups by root cause. AI proposes the fix. You approve once and it applies to all 142 phone-format mismatches. The math on operator hours saved is the part Mulesoft cannot answer.
• Pre-sync gates that prevent bad runs instead of cleaning up after them — Identity Resolution catches cross-org duplicates before the merge. Dedup runs as preflight hygiene with a dollar-value readout. DuckDB renders a 78ms diff preview of 50,000 records before you click run.

Some of this is shipping. Some of it is wireframe-grade by design. We mark the difference clearly throughout — that distinction is the post's whole point.

Org Sync as the New Front Door

The April post described the engine. The four-tab dashboard wrapping it — Dashboard, Jobs, Conflicts, Configurations — was engineering scaffolding. Each tab told you what the system was doing. None told you why it mattered. A buyer opened the app, saw "0 Active Configs · 0 Jobs · 0 Pending Conflicts" across four screens, and understood nothing.

So we threw it away. The new Sync surface has three sections: Map, Pairs, Activity. Map is the front door — a topology of every connected org with sync flows as colored, directional edges. Green for source-to-target, blue for bidirectional, amber for paused, red for circuit-broken. You see the system at a glance. Click an edge, drill into the pair workspace. Click an org, the side panel tells you what's coming in, going out, at risk. Activity is the global event feed across every pair, filterable by actor and time. The auditor's home. The ops drawer — circuit breakers, rate-limit budgets — lives behind a button, not on the front page of your integration product.

The noun is Pair. A Pair has a config; you don't manage configs separately. That rename killed an entire tab and an entire mental model.

The product positioning

Sync alone is Salesforce-to-Salesforce-but-better. Useful, commodity. Sync stacked with the rest of Pathfinder is a category of one. Five things only Pathfinder Sync can ship because of how the primitives compose: sync that previews the dollar cost of duplicates before propagating them (Dedup × Sync — a $1,059 storage readout on the Pre-Sync card before you click run); sync that resolves cross-org identities before merging (Identity × Sync — 47 candidate pairs surface, operator approves, sync runs without creating a duplicate Contact in either direction); sync with AI-suggested conflict resolutions, where the operator approves a recipe and applies to all matching conflicts (Vibes × Sync — 142 phone-format mismatches become one click instead of 142); sync where every record change is reversible by name, time, or actor (Versioning × Sync — Tuesday's run corrupted 2,400 phone numbers, click to revert just those records, the auditor's three questions are all one query); sync where the topology of all your orgs IS your data exploration canvas (Schema Explorer × Sync — the Map view is the same God Canvas with the same multi-dialect query console). None of these is possible with a sync product alone. They are possible because Pathfinder shipped the primitives first and built sync as the surface that ties them together.

The competitive frame

Salesforce-to-Salesforce native is free and brutal. Designed in 2010 for partner-network record sharing — a dealer org sharing leads with a manufacturer — not for prod-to-sandbox replication. Caps at 100 records per sync transaction, rejects most field transformations, no UI worth showing a non-admin. Salesforce's own docs flag it as unsuitable for bulk loads or heavily customized environments. Every team starts with S2S. Most abandon it by year two. If you need to share fifty leads a day between two orgs, S2S is right and we should say so.

Skyvia is the cheap-and-cheerful tier — $99/month for cloud ETL, real bidirectional Salesforce-to-database sync. What Skyvia doesn't ship: an audit trail you'd show a compliance officer. Identity resolution. AI conflict suggestions. A mapping language with transforms beyond direct copy. Every byte of customer data flows through Skyvia infrastructure, which is a procurement conversation we don't have to have.

Mulesoft is the enterprise floor — $15K/month per vCore on the Gold tier, plus an integration architect at $200K+. Powerful, slow to deploy, not designed for an admin who wants to author a mapping in twenty minutes. Right for the Fortune 500 with a Center of Excellence and a budget line. We serve the layer beneath — the one currently paying the Mulesoft tax for a Salesforce-specific subset of what Mulesoft does.

Pathfinder Sync sits in the gap: an audit trail in workspace SQLite, identity resolution as a pre-sync gate, AI as the conflict reviewer, the whole thing running on the operator's laptop with no data egress. We don't compete with the cheap tier on price and we don't compete with the expensive tier on breadth. We win the band currently choosing between two products that both fit them badly.

The pre-sync gates

Before any sync run, the operator walks through three optional gates. Each prevents a class of bad outcome that every other sync tool ships into production by default.

The Identity Gate runs cross-org match detection on extracted samples from both sides. "47 cross-org duplicates surfaced — resolve before bidirectional sync creates 47 garbage records on each side?" Operator approves, defers, or rejects each; on approve, an external-id link is written and the executor consults it before upsert. Six months in, eight thousand cross-org identity links are resolved and the nightly sync stops creating duplicates entirely.

The Dedup Hygiene gate runs source-side duplicate detection with a dollar readout: "1,247 duplicate clusters across Account, Contact, Opportunity. Cleaning prevents propagating $2,040 in target storage." Two CTAs: clean first, or quarantine duplicates with the audit captured. The CFO sees a price tag on garbage propagation. Nobody else does this.

The Object Diff preview is DuckDB-powered and finishes in 78 milliseconds on a 50,000-row dataset. Fourteen NEW, eighty-seven MODIFIED, three DELETED — exactly what would change, before you click run. Mulesoft needs a custom DataWeave script for this. Skyvia can't do it at all.

Then the sync runs against clean data with operator approval already in the audit log.

The honest gap

Real extract_stream for Salesforce and Bloomerang isn't shipped yet. It's connector-side work — auth refresh edge cases, bulk API quirks, rate-limit bucketing, the unglamorous middle mile that lands in the next thirty days. Today's demo runs against seeded data with the executor wired in dry-run mode. The architecture is shipped; the connector wire-up is the obvious next mile.

We mark the difference clearly throughout the rest of this post. The demos you'll see below are the product at GA quality; the executor underneath is a mix of live and seeded depending on which connector you'd point it at today. That distinction is the post's whole point — and the reason the final section exists.

The Topology Map

The Topology Map is the first frame of the Sync product. It is what a buyer sees before they have read a word, and what an operator sees before they have done a thing. Both audiences need to feel the same thing in the first half-second: this is alive, this is mine, this is in motion.

What it is, mechanically: a Pretext-rendered canvas of every connected org, force-laid-out, with sync edges drawn between paired orgs. Each org is a frosted-glass panel with a 4px namespace accent bar on the left edge — Hub blue, Sandbox green, Regional ochre, Partner purple, Integration red. The accent bar is the single most important pixel for fast namespace recognition at low zoom. Edges are thin curved beziers colored by sync status: emerald for active, amber for conflict, red for failed, slate for paused. Direction chevrons sit at the target end. Active edges gently brighten on a 60ms tick when sync is flowing through them — a deterministic phase per edge so adjacent edges don't pulse in unison and read as one big breathing canvas. A live perf chip in the top bar reads the actual rAF-driven framerate: "287fps · 12ms Pretext." The chip is not decoration. It is the audit. If we miss our budget on the demo machine it goes slate-gray and we have lied about the screen's claim.

Force layout config: 40K repulsion, 0.0025 spring stiffness, 0.85 damping, 280px edge rest length. The numbers aren't interesting on their own. What matters is that the canvas settles inside two seconds with 50 orgs and never spends more than 4ms per frame on physics.

Four discrete zoom levels, each tuned for a different question. Galaxy view (under 0.4) collapses each org to a 16px namespace-colored glyph — useful when looking at 50+ orgs at once. Constellation view (0.4 to 0.8) shows org name and record count. System view (0.8 to 1.5) is the default mount and shows the full panel with health pill and last-sync-ago chip. Detail view (above 1.5) expands org panels inline to show the top synced objects as colored chips: [Account 12K] [Contact 45K] [Opportunity 120K]. Transitions are 250ms eased crossfades on the level-conditional elements only — force layout positions don't re-tween, so zoom stays buttery and the canvas doesn't settle again every two notches of the wheel. Same interaction model as Apple Maps. Operators don't need to learn it.

Why it matters strategically. Most enterprise sync tools open on a list of jobs sorted by date. That tells you what the system was doing. It does not tell you what your environment looks like. The topology says: here is your sync architecture, here is its health, here is where work is happening right now. A buyer who opens the canvas and sees their org topology animating in at 287fps forms an opinion before reading anything. The visual quality is the trust signal — the entire pre-verbal pitch happens in the first half-second.

We invested in Pretext, the rendering substrate, precisely so the canvas feels native and not web-laggy. The same substrate powers Schema Explorer — 26 floating panels across all source and target schemas. The Topology Map is the Sync-specific layer on top. One investment, two surfaces. Design as force multiplier is not a slogan; it is a budget decision that pays back twice.

The Conflict Inbox: Approve Once, Apply 142

Every other sync product makes you click 142 times to resolve 142 conflicts. We made that math go away. Approve once, apply 142. The Conflict Inbox is where it happens, and it is the single most operator-hostile thing we fixed in this release.

Here is the bet underneath it. Real-world sync conflicts are not 142 independent decisions — they are one decision repeated 142 times. When you find one Account.Phone format mismatch between two orgs, you have 142 of them, because the source formats phones with parentheses and dashes and the target strips to ten digits. Same pattern. Same fix. Treating each row as its own decision is a UX failure dressed up as thoroughness. So we don't. The Inbox materializes a hash signature on (object, field, conflict_type, value_pattern) at conflict-insert time — not at render time — so groups appear instantly even at fifty thousand conflicts. The hash is a shape signature, not a value match: two phone strings with different digits but the same length and character class collapse into one bucket. The screen surfaces "142 conflicts on Account.Phone — format mismatch" as one card. Not 142 rows. One.

You click the card. You click Apply Recipe. A slide-over opens.

A recipe is the durable thing in this design. It is a reusable resolution rule scoped to a sync pair plus a group signature, and it comes in three shapes. Transform-source applies an expression — NORMALIZE_PHONE, LOWER, TRIM, anything in the transform language — to the source value before accepting it. That is roughly eighty percent of the recipes you will ever write. Lookup-table maps source values to target values, which is what you want when somebody renamed a picklist and now you have "Closed Won" on one side and "Won" on the other across a dozen Opportunity stages. Override-per-record drops you into manual review with bulk affordances for the cases that genuinely need a human — fewer than you think. You pick a shape, the preview shows three sample conflicts with the recipe applied, you click Save and Apply to All 142, and the group clears.

What makes recipes worth building, as opposed to one-off bulk actions, is that they persist. Next sync run, the same pattern reappears, the saved recipe surfaces at the top of the group with "Apply saved recipe (used 3x before)" and a one-click button. The decision compounds. The third time you see Account.Phone format mismatch you do not even open the slide-over. The fortieth time you trust the recipe library because you built it.

The AI layer sits on top of that, not inside it. Open a single conflict's detail and an AI suggestion panel offers a proposed recipe with a real explanation: "Source phone is 13 chars including formatting, target is 10 chars stripped — same number, different format. Suggest NORMALIZE_PHONE then SourceWins." You accept, edit, or reject. On accept, the panel offers "Promote to recipe — apply to all 142 in group." The AI never auto-applies. Every AI-suggested recipe is logged with Actor::AiVibes in the version history, separable from human-authored recipes, individually revertible. Trust through provenance, not through marketing. The AI suggestion layer is wiring in over the next two sprints; today's demo uses deterministic seeded suggestions for the Phone-format case so the loop is real end to end without pretending the cost telemetry is finished.

Identity Resolution and Dedup: The Two Silent Failure Modes

Every other sync product on the market has two silent failure modes baked in.

The first: when you run a bidirectional sync between Org A and Org B, and the same person already exists on both sides under slightly different spellings, the tool happily creates duplicates in both directions. Talend, Informatica, MuleSoft, Salesforce-to-Salesforce — all upsert blindly by external-id with no notion of cross-org identity. The second: when the source is dirty, the garbage propagates into the target on the first run. The sync looks like it succeeded. The audit log says zero errors. The data is degraded. By the time anyone notices, you have 1,247 duplicate Contacts and a fundraising campaign that mailed the same donor four times.

Pathfinder treats both as upstream gates, not downstream cleanup.

Identity Resolution as a sync precursor

Before any bidirectional sync run executes, the Identity Gate fires. The configured pipeline runs against extracted samples from both orgs and surfaces candidate match-pairs grouped by confidence tier with the per-signal breakdown visible: email exact jmartinez@gmail.com 1.0, phone normalized 4155550190 0.95, name fuzzy Jennifer / Jenny 0.92, composite 0.96. The operator picks per-tier action — auto-merge HIGH (≥0.95), defer LOW (<0.7), case-by-case for MEDIUM — and the executor consults those decisions BEFORE upsert. If a candidate has a resolved cross-org link, the upsert routes to the existing target record instead of creating a new one. Every decision writes to cross_org_identity_decisions with operator, timestamp, pipeline version, and signal breakdown. Six months in, a typical pair has 8,400 resolved cross-org identity links and zero duplicate creations.

This is also the answer to the question every CCPA / GDPR / right-to-be-forgotten conversation is actually asking. To honor "delete every record about Susan Lee," you first need to know which records ARE Susan Lee — across every system she touches. Identity Resolution materializes that knowledge with a per-decision audit trail. No other sync tool can answer it.

Dedup as a hygiene preflight

Before pushing 50,000 records from Bloomerang to NPSP, the Hygiene gate fires. The DuplicateManager engine — three default rules (exact_email, normalized_phone, name_address), comprehensive variant adds normalized_name fuzzy, algorithm dropdown now properly honored — runs against the source and surfaces 1,247 clusters covering 2,400 duplicate records. The dollar number is what makes it land: 1,247 clusters × $0.85 USPS-blended mail-drop cost = $1,059 saved per appeal cycle, plus target storage savings, plus zero garbage propagated. The bulk-action bar offers "Auto-merge all HIGH (>0.95)" and "Skip all LOW (<0.6)" per-tier so 412 clusters resolve in a single click. Cleaned data flows into the sync.

The pattern compounds. The recipes you build are saved per pair plus per object, so next Tuesday's sync auto-suggests "Last week's hygiene found 1,247 — run again?" with one click. The five-minute hygiene check becomes a thirty-second confirmation.

Today's demo uses a seeded cross-system match set; the live multi-org pipeline lands next sprint, covered below. The gate UX, the decision-as-data audit trail, the executor consult-before-upsert path — all production. The moat is the architecture, not the demo data behind it.

The Mapping Studio and the Eleven Shapes

Most data migration tools treat field mapping as plumbing. A YAML file in a repo, a CSV column-pair import, a wizard you click through once and never look at again. We treat it as the operator's primary work surface, because it is. Bad mappings are the failure mode of every migration project I've ever shipped — they don't crash, they don't throw, they silently corrupt records for weeks until someone in finance notices the donor totals are off and now you're three sprints into a forensic reconciliation. The Mapping Studio exists because the act of binding source to target is the work. Everything else is logistics around it.

The studio knows eleven mapping shapes. Direct pass-through covers the easy seventy percent — FirstName to FirstName, done. The other thirty percent is where most tools fall over and where we built dedicated authoring affordances for each: combine multiple source fields into one target (FirstName plus LastName into FullName with a separator and skip-empty handling); split one source into N targets (FullName into First and Last with smart presets that already know Email splits on @ into local and domain); conditional branches (if Status = Active then Donor else Lead); lookup tables (Bloomerang fund names resolved to Salesforce GAU references); value maps for the picklist drift that happens between any two orgs; cross-lookups, chains, constants, expressions, formatters. Each shape gets its own modal — CombineModal, SplitMappingModal, ConstantOrFormulaInline — but they all classify through one function (classifyMappingShape) so the badges, the connection-line renderer, and the MCP tool all agree on what kind of mapping they're looking at.

AutoMap does the obvious work in one click. It's a seven-stage matcher: exact name match at 1.0 confidence, case-insensitive at 0.95, normalized (camelCase to snake_case, strip underscores) at 0.90, then nonprofit-specific abbreviation expansion at 0.90 — and that's the stage nobody else has. We hand-curated twenty-eight tokens that matter in this domain: fname becomes first name, dob becomes birth date, chk becomes check, acct becomes account. No general-purpose matcher knows that DonorAcct__c probably means Donor Account; ours does. Then known field patterns at 0.85, Jaro-Winkler similarity (only when raw similarity exceeds 0.8), and a type-compatible fallback. The operator hits AutoMap, accepts twenty-eight of thirty-two suggestions, and hand-authors the four that are actually interesting. That's what the AI should be doing — clearing the obvious so the human can spend their attention on the ambiguous.

Every save snapshots. Mapping is a Versionable entity, so every update writes a new row to entity_versions with a SHA-256 payload hash for dedup and a type-aware diff summary like renamed to 'BAFB Constituent → SF Account', 2 objects added, 5 fields removed — not the generic "Updated mapping" garbage you get from frameworks that bolted versioning on at the end. The History tab renders the timeline with actor-colored dots and action icons. Click any prior version, Compare or Revert. Revert is non-destructive: it writes a new version with the historical payload, the timeline grows, nothing is lost. Compliance and auditability work because the substrate was built for them, not because we papered over a last_modified column with a UI.

The same studio component embeds inside Sync's per-pair Mapping tile through a PairContextProvider wrapper. One investment, two surfaces — the operator authors mappings the same way whether they're staging a one-time migration or tuning a live sync pair. That consistency is the whole point.

Audit, Versioning, SecureCredentials

Most sync vendors talk about audit logging the way you'd talk about a bolt-on alarm system: here's a feature, here's a checkbox, here's a CSV export for your auditor. The problem with bolt-on audit is that nobody trusts the log. If the audit table is just another database row that the application writes to, then any sufficiently motivated insider — or any bug — can quietly amend history after the fact. The log proves nothing it doesn't already cost you to verify out of band.

We made a different bet. Audit and versioning are substrate in Pathfinder, not features. Every mutation in every domain — mapping, sync, dedup, identity, connections — flows through the same Versionable trait, snapshots into entity_versions, and writes a corresponding audit_log row. The two are linked by a real foreign key: audit_log.version_id → entity_versions.id. An auditor drilling into any audit row can pull the exact entity snapshot that captured the post-change state. Time-travel is built in because there's nowhere else for a mutation to go.

What shipped this season: MappingResponse and SyncJob both implement Versionable today, with type-aware diff summaries instead of generic "Updated X" filler that tells you nothing. Every snapshot is content-hash-deduped, so re-saving the same payload doesn't pollute the history. The audit_log.version_id column populates from update_mapping and now start_sync, which means lineage is queryable from day one rather than retrofitted later when somebody asks.

SecureCredentials landed in parallel. It's a newtype that wraps Salesforce and Bloomerang config secrets in secrecy::SecretBox — Debug formats render [REDACTED], Serialize emits [REDACTED], the secret zeroizes on drop. Sub-one-day of work that closes off an entire class of credential-leak bugs (logs, panics, error reports, debug dumps). The other four connectors are still on plain String. That's a day each, and it's next.

Telemetry got the same substrate treatment. Seven hot Tauri commands are now wrapped with an instrument_command helper that emits to a command_telemetry table — duration, status, args hash. Sync executor failures, breaker trips, rate-limit hits all auto-emit. Once LLM cost emission lands, AdminCostPage moves from demo banner to real data.

Next sprint: Versionable extends to ConflictResolutionRule, Connection, and DuplicateCluster — Tier A done. After that, the hash-chain audit verifier: SHA-256 prev_hash plus curr_hash walked by a Web Worker across the entire chain in under three seconds. That's the trust beat for the Compliance buyer — proof, not promise. I'm naming the sequence in public because compliance buyers want roadmap honesty more than they want feature counts.

What Isn't Done Yet

Every other sync vendor's blog post claims their product does everything. You know that's not true. The discovery call is where the gaps surface, the POC is where they bite, and month three is where someone gets fired. We do the inverse. The first thing we tell you about Pathfinder Sync is what isn't done yet, with effort estimates, in the order that actually matters to a buyer. Trust compounds when honesty is the opening move, not the closing apology.

Six things aren't shipped. Here they are, ordered by the size of the hole each one leaves.

The biggest is real extract_stream for Salesforce and Bloomerang. Both connectors implement streaming today as a thin wrap around extract, which loads the entire result set into memory before yielding the first batch. That means a 100K-row Salesforce extract OOMs the desktop app. Both APIs support native pagination — Salesforce via nextRecordsUrl, Bloomerang via ?page=N — and wiring real streaming is roughly two days per connector. Lands in 30 days. Until then, demos and pilots stay under 10K rows per object and we say so out loud.

Next is Versionable expansion to the Tier A entities. Today only MappingResponse and SyncJob carry version history and revert. ConflictResolutionRule, Connection, DuplicateCluster, and Client do not. The trait, snapshot wiring, and revert dispatch each take about a sprint per entity. The four land across the 60-day window, in the order: ConflictResolutionRule, Connection, DuplicateCluster, Client. Until then the audit story is "two of twenty-five entities are revertible," and we don't pretend otherwise.

Then the hash-chain audit verifier. Every audit_log row will carry a SHA-256 prev_hash and curr_hash, and a Web Worker will walk the chain in under three seconds to prove no row has been mutated. Designed; not yet shipped. Lands next sprint.

Then the BridgeQL planner — the SQL+Graph cross-system query language that makes Schema Explorer's query console actually cross-org. Today the console runs SQL against the local SQLite workspace. SOQL passthrough is about three days. The planner that translates BridgeQL into a federated SOQL+SQL plan across orgs is multi-week.

Then OEM mode. The <pathfinder-sync embed-mode="topology" theme="odaseva" /> web component for partners to embed Pathfinder Sync inside their own console. The spec exists. The iframe-isolated build, JWT auth delegation, and theme tokens are multi-week.

Last, cost telemetry from FabricBridge into AdminCostPage — the page carries a "demo data" banner today for that reason. Sub-one-week of wiring.

Naming the gaps with effort estimates is a stronger signal than naming features. Buyers who appreciate this won't be surprised at month three. Buyers who need everything-shipping-today aren't our buyers anyway.

Working with Us

Pathfinder is built for a specific shape of buyer. Multi-org Salesforce environments where two or more production orgs need to stay in continuous agreement on shared records. M&A integration teams six months into consolidating an acquired org and discovering the spreadsheet plan does not scale. Regulated nonprofits and healthcare orgs that need an immutable audit trail because a funder, a board, or a federal agency is going to ask for one. SI and consulting shops managing five or more client orgs who are tired of writing the same conflict-resolution code for the third time.

It is not built for everyone. If you run one org, sync nothing, and your data fits in a single DataLoader job, you do not need this. If your team solves everything with Excel and nobody is auditing you, save your money. And if you are looking for shrink-wrapped software you can buy today, we are still inside the 30/60/90 window described above. The buying window opens with the first design partners, not with this post.

Three ways to engage. Read along by subscribing to the colbysdatamovers.com blog — release notes, architecture writeups, and the occasional honest postmortem. Book a discovery call at colbysdatamovers.com/contact — thirty minutes, no slides, your screen and your questions. Right answer for any multi-org SF team seriously evaluating Pathfinder against MuleSoft, Informatica, or a homegrown sync. Apply for fractional CTO at colbysdatamovers.com/fractional-cto if you want me embedded as engineering leadership for a quarter or longer. Application-only, $6,500/month tier, capped at three clients at a time, currently one seat open.