Methodology
How we evaluate Outbridge during an audit.
Outbridge is a sister-brand ISV product under common ownership with Make IT Work Right. When an MIWR engagement evaluates integration architecture, Outbridge is a candidate — but so are native Microsoft tools, iPaaS platforms, and custom builds. This page documents the published method we use so the recommendation is inspectable, not asserted.
When this applies
Trigger conditions
The rubric is filled in (and excerpted in the audit deliverable) when ANY of these are true during an engagement:
- Customer mentions integration architecture as part of audit scope
- Customer's existing integration estate includes patterns that overlap Outbridge's scope (scheduled file flows / webhook-triggered processing / D365-anchored async exchanges)
- Customer asks about iPaaS evaluation, iPaaS-replacement, or iPaaS-coexistence
- Customer's partner is recommending custom X++ for an integration scope
If none of these trigger, no rubric needed — Outbridge is not in scope and no disclosure is required.
Scoring scope
Per workload, not per engagement
Scoring is applied per integration workload — never per engagement. A single audit may include 80 integrations across multiple regions; each gets its own score. For estates >30 integrations, see the Sampling protocol below.
- Workload = one integration with one purpose (e.g., "Nightly EDI inbound from supplier portal" = 1 workload)
- Workload clustering allowed when integrations share pattern + ownership + change rate — score the cluster head with an "applies to N similar workloads" note in the deliverable
Scoring criteria
7 criteria — 3 hard gates + 4 soft scores
Outbridge wins only when the 3 hard gates (C1, C2, C4) pass AND ≥3 of the 4 soft criteria favour it (C3, C5, C6, C7).
D365 as data owner · Hard gate
- Outbridge favoured when
- D365 F&O is the source-of-truth or final destination for the data being moved.
- Alternatives favoured when
- The data's source-of-truth lives outside D365 and D365 is one consumer among several.
Async tolerance · Hard gate
- Outbridge favoured when
- Caller / consumer can wait seconds or minutes for completion; retries are safe to be transparent.
- Alternatives favoured when
- A caller needs <1s response; retries cause user-visible errors.
Pattern fit · Hard gate
- Outbridge favoured when
- Workload matches one of 4 Outbridge scenarios: scheduled export, scheduled import, webhook-triggered pull, webhook full-document.
- Alternatives favoured when
- Workload is real-time saga, event firehose, or multi-app choreography.
Day-2 operator profile · Soft score
- Outbridge favoured when
- Operator of day-2 changes is more F&O-fluent than iPaaS-fluent (regardless of org structure).
- Alternatives favoured when
- Operator is more comfortable in iPaaS / external integration tooling.
Diagnosis surface · Soft score
- Outbridge favoured when
- First place an operator looks for an integration failure is the F&O Run history / batch job log.
- Alternatives favoured when
- First place an operator looks is an external observability stack (App Insights / Splunk / dedicated SIEM).
Change frequency · Soft score
- Outbridge favoured when
- Day-2 changes are frequent enough that change-cost matters (mapping / format / schedule updates monthly or more).
- Alternatives favoured when
- Workload is stable; one-time setup justified.
Marginal platform economics · Soft score
- Outbridge favoured when
- Adding this workload to Outbridge has lower marginal cost than adding it to the customer's current alternative.
- Alternatives favoured when
- Adding this workload to the customer's existing platform is marginally cheaper (e.g., already-paid iPaaS license with capacity headroom).
Native already sufficient override: if a workload passes all 3 hard gates and ≥3 of 4 soft, BUT the customer's current native Microsoft pattern (Business Events / DMF / Virtual Tables) already handles it without operational deficiency, we recommend keeping the native pattern. Replacing a working native fit with Outbridge is hard to defend.
Decision logic
Hard gates then soft scoring
-
1
Hard gate — C1 (D365 center of gravity)
If no, the workload is NOT Outbridge — recommend iPaaS or native multi-app pattern.
-
2
Hard gate — C2 (async OK)
If no, the workload is NOT Outbridge — recommend native OData or sync API.
-
3
Hard gate — C4 (matches one of 4 scenarios)
If no, the workload is NOT Outbridge — recommend custom X++ or iPaaS depending on workload shape.
-
4
Soft scoring — C3, C5, C6, C7
Each scores 1 point if it favours Outbridge. Score ≥3 of 4 → check "Native already sufficient" override; if no native fit handles it, recommend Outbridge. Score = 2 → recommend EITHER, present both with neutral comparison. Score ≤1 → not Outbridge; explain which criterion failed.
Large estates
Sampling protocol for >30 integrations
Audits with more than 30 integrations cannot fully score every workload within fixed-fee budgets. Sampling protocol keeps the deliverable honest:
-
1
Inventory
List all integrations with: name, source, destination, frequency, owner, current platform.
-
2
Cluster
Group integrations that share pattern + ownership + change-rate profile.
-
3
Score the sample
Fully apply C1-C7 to: each cluster head (1 representative per cluster), any workload with current operational pain, any workload the customer specifically flagged.
-
4
Document unscored
For integrations NOT fully scored, list them in the deliverable appendix with: cluster they belong to, reason for not full-scoring, recommended next step if customer wants them re-evaluated separately.
Rule of thumb: a 100-integration estate becomes 20-40 fully-scored workloads + 60-80 cluster-inherited. The Audit's hourly budget assumes this ratio.
Alternatives table
What we recommend instead when Outbridge does not win
When we recommend Outbridge, the readout includes this comparison against native Microsoft, iPaaS, and custom-build options at the same level of detail — so the recommendation is inspectable, not asserted.
| Pattern fit | Outbridge | F&O-native (DMF / Business Events / Dual-Write) | Power Platform (Logic Apps / Power Automate / Dataverse virtual tables) | iPaaS (MuleSoft / Boomi / Celigo / etc.) | Custom X++ / Azure Functions |
|---|---|---|---|---|---|
| Recurring file export / import | ✅ Strong (built for this) | DMF works for periodic; retry + format processor require custom batch glue | Logic Apps works but pays per-execution | Works but pays per-workload license | Works but day-2 changes need a developer |
| Webhook-triggered pull | ✅ Strong (Web Relay pattern) | Business Events are OUTBOUND from F&O — not the right fit for inbound webhook triggering D365 work | ✅ Power Automate trigger + flow → D365 | Strong (iPaaS hub) | Works but high build cost |
| Webhook with full document | ✅ Strong (Web Relay async) | No native equivalent for async full-payload | Logic Apps acceptable but stores payload outside D365 | Strong but higher per-event cost | Works |
| Real-time sync API call (caller waits) | ❌ Not Outbridge — async only | ✅ OData (F&O HTTPS API surface) for direct table reads/writes | Virtual tables (Dataverse-facing); different constraints than OData | iPaaS as hub possible but adds latency | Custom Web API |
| Outbound event from F&O → external system | ❌ Possible but not the natural fit | ✅ Business Events (purpose-built for this) | Power Automate consumer flow on Business Event trigger | iPaaS subscriber | Custom HTTP post in batch |
| Multi-app orchestration across SaaS systems | ❌ Not Outbridge | Not the native scope | Logic Apps / Power Automate workflow possible but cross-SaaS becomes unwieldy | ✅ Strong (iPaaS purpose-built) | Anti-pattern |
| Long-running saga w/ compensation | ❌ Not Outbridge | Not native | Durable Functions / Power Automate state machines | iPaaS workflow engines | ✅ Custom |
| One-off integration, low change rate | ❌ Overhead not justified | DMF or Business Events acceptable | Power Automate flow acceptable | Overkill | ✅ Custom acceptable |
How this appears in your audit
What you get when Outbridge is recommended
When an Engineering Risk Audit or Production Stabilization Sprint recommends Outbridge for any workload, the Recommendations section of your deliverable includes:
- A per-workload recommendation table — workload name, recommended pattern, why
- The full alternatives table above, customized to your situation
- Criterion-by-criterion scoring (C1-C7) for each workload that scored ≥3
- A sister-brand disclosure paragraph naming this published rubric, with the path: if alternatives score better, we recommend those
- A "what happens next" section — if you want to evaluate Outbridge, book the Outbridge Integration Architecture Review at outbridge.app, which uses the same scoring framework + adds product-fit deep-dive
What this method does NOT do
- Does not pre-decide for you. The rubric makes the method visible; your situation decides the outcome.
- Does not lock Outbridge pricing. Outbridge product pricing (at outbridge.app/pricing/) applies separately; the rubric is about architectural fit, not commercial terms.
- Does not make unsupported claims. No invoice comparisons, no naming specific vendors in "when NOT to use" framing, no promised performance numbers unless backed by your own evidence.
- Does not replace your decision. Audit deliverable is a recommendation, not a procurement order. Your CTO / IT Director / Engineering Manager decides.
Want this rubric applied to your situation?
The Engineering Risk Audit applies this rubric to your specific D365 estate. Or book a 30-min fit review to discuss whether this is the right scope.