Sample deliverables - What an SOW and architecture diagram look like.

Every engagement starts with a fixed-bid Statement of Work and a target-state architecture diagram, returned within 3 business days of intake. The example below is synthetic — illustrative of the format, depth, and scope discipline used on every engagement, with no real client data.

Scenario: Acme Distribution, $400M B2B distributor. Salesforce ↔ NetSuite bidirectional sync via MuleSoft Anypoint. Standard tier ($50,000, ~6 weeks).

Scenario 1 — Three-tier MuleSoft - Salesforce ↔ NetSuite bidirectional sync via MuleSoft.

Tech stack: MuleSoft Anypoint (CloudHub 2.0 + Anypoint MQ) · three-tier API design (Experience / Process / System) · RAML 1.0 specs published to Anypoint Exchange · MUnit tests · Anypoint Monitoring + Datadog · PagerDuty alerting.

Experience APIs serve UI consumers; Process APIs orchestrate the canonical model and business logic; System APIs encapsulate Salesforce and NetSuite. Errors land in DLQs with automatic exponential-backoff retry; observability spans Anypoint Monitoring and Datadog.

Sample target-state architecture: Salesforce ↔ NetSuite bidirectional sync via MuleSoftThree-tier MuleSoft API architecture. Experience APIs at top, Process APIs in middle with canonical model, System APIs at bottom connecting to Salesforce and NetSuite. Anypoint MQ dead-letter queues, Datadog observability, and PagerDuty alerts shown.EXPERIENCEAPIsPROCESSAPIsSYSTEMAPIsSales PortalWeb / MobileSalesforce UISales CloudOperations PortalInternal adminProcess API — Canonical Model + OrchestrationAccount Sync↔ bidirectionalContact Sync↔ bidirectionalOrder ReplicationSF → NSInvoice ReplicationNS → SFSystem API — SalesforceREST API · Bulk API · Composite APIAccount · Contact · Opportunity · Invoice__cSystem API — NetSuiteSuiteTalk REST · SuiteScriptCustomer · Contact · Sales Order · InvoiceAnypoint MQDead-letter queuesReplay endpoint3 retries · 30s/5m/30mDatadogMetrics · logs · tracesPagerDutySev1/Sev2 alertsSynchronous flowAsync / event flowError / DLQ pathSynthetic example · not real client data

Scenario 2 — Workato citizen-developer pattern - High-growth SaaS RevOps stack on Workato.

Tech stack: Workato Cloud (US-West) · OAuth-based connectors · Workato OEM tenancy · RecipeOps governance · Common Data Model + Lookup Tables · Workbot for Slack approvals · Splunk for centralized logging.

Trigger systems on the left (Salesforce, HubSpot, Stripe, Outreach, Slack); Workato recipe layer in the middle with 4 production recipes plus a shared Common Data Model; action systems on the right. RevOps team owns recipe authoring with senior architecture oversight on patterns, governance, and reuse.

Sample target-state architecture: SaaS-to-SaaS RevOps integration via WorkatoWorkato citizen-developer pattern. Trigger systems on the left, Workato recipe layer in the middle (Workbot, recipes, connectors, RecipeOps), action systems on the right. Splunk for centralized logging.TRIGGER SYSTEMSWORKATO RECIPE LAYERACTION SYSTEMSSalesforce Sales CloudLead · Opportunity eventsHubSpotMarketing form · MQL eventsStripeSubscription · invoice webhookOutreachSequence · meeting bookedSlack (Workbot)Slash command · approval replyWorkato Cloud (US-West)OAuth-based connectors · OEM tenancy · RecipeOps governanceRecipe: Lead-to-Account-to-SlackHubSpot MQL → SF Lead → Slack #revops alertRecipe: Closed-Won → NetSuite CustomerSF Opp Closed Won → NS Customer + Sales Order + Slack pingRecipe: Stripe → SF Account HealthSubscription change → SF custom field + Outreach pauseRecipe: Approval WorkbotSlack /approve → SF Quote stage updateCommon Data Model + Lookup TablesAccount ID mapping · Pricebook lookup · Owner routingNetSuiteCustomer · Sales Order · InvoiceSalesforce Sales CloudLead · Opportunity · QuoteSlack#revops · #cs · DMsOutreachSequence add/removeHubSpotContact · workflow triggerSplunk (centralized logging + alerting)All recipe runs · errors · job timing · custom dashboardsTech stack: Workato Cloud · OEM connectors · RecipeOps · Common Data Model · SplunkSynthetic example · not real client data

Scenario 3 — Boomi hybrid runtime (cloud + on-prem) - Salesforce Marketing Cloud → on-prem SAP ECC via Boomi.

Tech stack: Boomi AtomSphere · Boomi Cloud Atom (cloud-side orchestration) · Boomi Local Atom HA pair (on-prem, behind corporate firewall) · Atom Queue for async decoupling · Boomi Master Data Hub · SAP RFC + IDoc + BAPI · Oracle DB 19c · Active Directory (LDAPS) · Splunk Enterprise (on-prem).

Industrial manufacturer with a regulated on-prem SAP ECC estate. Boomi's hybrid runtime architecture is purpose-built for this: Cloud Atom handles cloud-side SaaS-to-SaaS orchestration (SF MCN ↔ SF CRM ↔ D365 lead routing), Atom Queue decouples the latency-sensitive cloud from the on-prem; Local Atom (active-active HA) lives behind the firewall and connects to SAP via RFC + IDoc with only outbound HTTPS to AtomSphere.

Sample target-state architecture: Salesforce Marketing Cloud to on-prem SAP ECC via BoomiBoomi hybrid runtime pattern. Salesforce Marketing Cloud in the cloud zone, Boomi Cloud Atom orchestrating outbound lead/customer flows, Boomi Local Atom on-prem behind the corporate firewall connecting to SAP ECC via RFC and IDoc. Atom Queue for async, AtomSphere centralized for governance, Splunk for logs.CLOUD (SaaS)BOOMI ATOMSPHERE (cloud + on-prem hybrid)ON-PREM (corporate datacenter)Salesforce Marketing CloudEngagement (MCN) · Data CloudSubscriber · Journey · ActivationSF CRM Sales CloudLead · Account · OpportunityMicrosoft Dynamics 365Lead · Account · OpportunityBoomi Cloud AtomSF MCN ↔ SF CRM ↔ D365 routingLead routing process · campaign responseIdentity Resolution Rule synchronizerAtom Queue (async)Decoupling cloud from on-prem latencyRetry · DLQ · 24h replay windowBoomi Local Atom (on-prem)Behind corporate firewallSAP RFC connector · IDoc inbound/outboundCustomer / Material / Pricing master dataActive-active HA pairAtomSphere governanceProcess library · env mgmt · deploy promotionBoomi Master Data HubCustomer master golden recordSAP ECC 6.0 EHP8RFC / BAPI / IDoc / SOAPSD · MM · FI modulesKNA1 · KNVV · MARA · MAKTCustom Z-tables for marketing flagsOracle DB 19c (on-prem)Customer master mirrorJDBC connectorActive Directory (LDAPS)Identity for sales repsOwner routing sourceSplunk Enterprise (on-prem)All Boomi process logs · alertsSIEM integration↑ Corporate firewall (only outbound HTTPS from Local Atom) ↑Tech stack: Boomi AtomSphere · Cloud Atom + Local Atom HA pair · Atom Queue · Master Data Hub · SAP RFC/IDoc · SplunkSynthetic example · not real client data

Statement of Work - Acme Distribution — Salesforce ↔ NetSuite Bidirectional Sync.

Representative fixed-bid SOW. Same structure used on every Green Dolphin engagement, tailored to the specific scope, systems, and compliance requirements.

SOW Date

[Effective Date]

Parties

Green Dolphin Software LLC × Acme Distribution Inc.

Tier

Standard — $50,000 fixed bid, ~6 weeks

Reference

MSA dated [date]; intake form #INT-2026-XXXX

1. Background

Acme Distribution is a $400M B2B distributor of industrial fasteners, operating Salesforce Sales Cloud (~80 sales seats) and NetSuite ERP. Today, Account, Contact, Order, and Invoice data is reconciled manually between the two systems on a weekly cycle, costing ~25 ops hours/week and producing recurring data-integrity issues (orphaned orders, stale credit limits, mis-attributed invoices).

The objective is a near-real-time bidirectional sync to eliminate the manual reconciliation cycle and reduce data-integrity defects to <0.5% of records.

2. Scope

The following scope items are in-scope for this fixed-bid engagement.

2.1MuleSoft API design (3-tier)

Experience API for client-side consumers; Process API for orchestration & canonical model; System APIs for Salesforce and NetSuite. RAML 1.0 specs published to Anypoint Exchange.

Key assumption: Anypoint Platform license is in place. Existing Anypoint Org structure (Business Group, Environments) is reusable.

2.2Salesforce ↔ NetSuite bidirectional sync — Accounts

Bidirectional sync of Account records. Create/Update only; Delete is soft-delete via Inactive flag in both systems. Standard field mappings to canonical model + 5 custom field mappings each direction.

Key assumption: External ID strategy: Salesforce External_ID__c ↔ NetSuite externalId. No legacy duplicate consolidation.

2.3Salesforce ↔ NetSuite bidirectional sync — Contacts

Bidirectional sync of Contact / NetSuite Contact records. Contact Role mapping (Primary, Billing, Shipping). Email is enforced as unique key.

Key assumption: Existing Contact deduplication has already been performed in both systems. Email-uniqueness is enforced.

2.4Sales Order replication (Salesforce → NetSuite)

One-way replication of closed-won Opportunities to NetSuite Sales Orders. Includes line items, pricing, and shipping address. Triggered by Opportunity StageName = "Closed Won".

Key assumption: Pricebook / Item Master is the source of truth in NetSuite and is already synced via separate process. Tax calculation is NetSuite-side.

2.5Invoice replication (NetSuite → Salesforce)

One-way replication of NetSuite Invoices to a Salesforce custom object (Invoice__c). Status, balance, and due date kept current via daily batch + on-demand refresh.

Key assumption: Invoice__c custom object already exists in Salesforce. Fields and page layouts pre-built or in-flight.

2.6Error handling framework

Dead-letter queue (DLQ) per System API. Automatic retry with exponential backoff (3 attempts, 30s/5min/30min). PagerDuty alert on >50 DLQ messages OR error rate >2% in 5 min window. Idempotent replay endpoint.

Key assumption: PagerDuty integration is in place with a service for the integration team. SMTP relay configured for fallback email alerts.

2.7Observability dashboards

Anypoint Monitoring dashboards: throughput, error rate, latency P50/P95/P99 per API. Datadog dashboards mirror Anypoint metrics + custom business metrics (orders synced/day, invoice balance reconciled).

Key assumption: Datadog account with API key is provided. Anypoint Monitoring is enabled (Titanium subscription).

2.8CI/CD pipeline

Azure DevOps pipelines for build → unit test → MUnit test → deploy to Sandbox/UAT/Prod. Promotion is manual approval at UAT and Prod. Versioned releases (semver) published to Exchange.

Key assumption: Azure DevOps org is provisioned with build agents capable of running Maven + Mule Maven Plugin.

2.9Knowledge transfer

Up to 2 knowledge-transfer sessions (60 min each). Session 1: architecture walkthrough + runbook. Session 2: error-replay procedure + dashboard tour. Recorded for client archive.

Key assumption: Client identifies 2-4 named attendees for sessions. Sessions scheduled within 5 business days post-deployment.

3. Phases & Approach

#PhaseDurationActivities
1Initiate & ArchitectWeek 1Kickoff meeting (60 min). Discovery sessions with client SMEs. Confirm canonical model, field mappings, identity strategy. Sign off on target-state architecture diagram.
2Construct (build)Weeks 2–4Two 1-week sprints. Sprint 1: System APIs (Salesforce, NetSuite) + canonical model. Sprint 2: Process APIs (Account/Contact/Order/Invoice flows) + Experience APIs. Daily 15-min standups. End-of-sprint demo.
3Validate (UAT)Week 5Internal QA + MUnit test pass. Client UAT execution against UAT environment. Defect triage daily; defect resolution SLA 1 business day for Sev 1, 3 days for Sev 2/3.
4Deploy & HandoverWeek 6Production deployment via Azure DevOps pipeline (manual approval gate). 2 knowledge-transfer sessions. Runbook + architecture documentation finalized. Smoke test plan executed.
5Hypercare+2 weeks (included)Post-go-live monitoring. Daily check-in for 5 business days, then on-demand. Defect fixes related to delivered scope are included in fixed bid; out-of-scope work via Change Order.

4. Deliverables

Green Dolphin owns

  • Configured MuleSoft Anypoint environment (Sandbox + UAT + Prod)
  • RAML 1.0 specs for all APIs published to Anypoint Exchange
  • Target-state architecture diagram (PDF + editable Lucid/Miro link)
  • MUnit test coverage ≥ 70% for Process APIs, ≥ 50% for System APIs
  • Azure DevOps CI/CD pipelines with manual promotion gates
  • Anypoint + Datadog dashboards with documented alert thresholds
  • Runbook (markdown) covering ops, error replay, key rotation, on-call escalation
  • Recorded knowledge-transfer sessions (2 × 60 min)

Client owns

  • Salesforce sandbox + production org access (System Administrator profile, with API access)
  • NetSuite Sandbox + Production access (Integration Role with appropriate permissions)
  • Anypoint Platform org access (Cloud Hub Developer + Deployment User)
  • Azure DevOps project with build agents
  • Datadog API key + service identifier
  • PagerDuty integration key for the integration team
  • Named SMEs (1 Salesforce, 1 NetSuite, 1 PM/BA) with 1-business-day feedback SLA
  • UAT execution + sign-off

5. Commercials

Engagement type: Fixed bid. Total: $50,000 USD. Payment terms: 50% on kickoff, 50% on delivery acceptance. Expense policy: Travel not assumed; on-site (if requested) billed at $250/hr + actuals with prior written approval. Net 15 from invoice date. ACH or wire only.

6. Acceptance Criteria

  • All scope items in §3 demonstrably running end-to-end in UAT against client-supplied test data
  • MUnit tests at coverage thresholds (Process API ≥70%, System API ≥50%) all green
  • Smoke test plan executed in production with sign-off from named SME
  • Documentation handed off (architecture diagram, runbook, KT recordings)
  • Sev 1 / Sev 2 defects resolved or formally accepted via Change Order

7. Key Assumptions

  • Engagement starts within 10 business days of SOW signature.
  • Client provides documented field-level mappings using Green Dolphin's Mapping Workbook template within 5 business days of kickoff.
  • Existing Salesforce + NetSuite metadata (objects, fields, validation rules) is stable; structural changes require Change Order.
  • Client has named SMEs available with 1-business-day feedback SLA. Resource delays >5 business days trigger schedule renegotiation.
  • No client blackout periods (e.g., end-of-quarter freeze) during the 6-week engagement window.
  • Production go-live is scheduled at least 5 business days after UAT sign-off.
  • Travel is not assumed. Engagement delivered remotely. On-site work, if requested, billed at $250/hr + actuals.

8. Out of Scope

The following are explicitly out of scope for this fixed-bid engagement.

  • Salesforce or NetSuite license procurement, sizing, or configuration outside the listed objects
  • Data migration, cleansing, or master data harmonization beyond what is needed for the in-scope syncs
  • Master Data Management (MDM) tooling implementation
  • Custom UI development on Salesforce or NetSuite (Lightning components, Suitelets, etc.)
  • EDI / X12 / mainframe integration
  • Real-time bidirectional sync at >100K events/day (current scope is up to 100K events/day per object)
  • Tax engine integration (Avalara, Vertex)
  • Any third-party connector licensing (e.g., Celigo, Boomi suites) beyond MuleSoft Anypoint
  • Disaster recovery / failover architecture (separate engagement)

9. Change Order Process

The following will trigger a Change Order with a new fixed-bid quote (typically returned within 3 business days):

  • Any new object beyond the 4 in §2.2–§2.5 (Account, Contact, Sales Order, Invoice)
  • Any net-new endpoint, transformation rule, or system not listed in §2
  • Volume above 100K events/day per object (sustained over 5+ business days)
  • New environments beyond Sandbox + UAT + Prod
  • New compliance scope (FedRAMP, HIPAA, PCI-DSS) not explicitly identified at SOW signature

No work proceeds against a Change Order until the client has accepted the new fixed price in writing. The original fixed bid covers the original scope only.

10. Signatures

Green Dolphin Software LLC

By: ___________________________
Name: Max Girin
Title: Founder & Principal Architect
Date: __________

Acme Distribution Inc.

By: ___________________________
Name: __________________________
Title: __________________________
Date: __________

Sample design deliverables - Download representative design documents.

Four downloadable Word documents drawn from real engagements, scrubbed of all client identifiers. Same depth, same structure, same level of detail you would receive on a Green Dolphin engagement. Synthetic company name "Acme Corp" throughout.

MuleSoft Target-State Architecture

Architecture & Design

Current state inventory, gap analysis, target-state three-tier architecture, platform recommendations, 90-day modernization roadmap. Representative of an Architecture & Design tier deliverable.

Process API Design Document

Standard / Enterprise

Detailed API design for a single Process API: business context, sequence diagrams, RAML 1.0 spec, request/response schemas, error models, validation rules, security model, observability hooks. Representative of a per-API design deliverable.

Integration Domain Design Document

Standard / Enterprise

End-to-end domain design for a multi-API initiative: business problem, target architecture, data model, API contracts, integration flows, error handling, deployment topology, runbook excerpts. Representative of a Standard or Enterprise tier design package.

MuleSoft Developer Onboarding Guide

All implementation tiers

Onboarding documentation handed to client developers post-engagement: local setup, build, test, deploy, common patterns, repo structure, code-review checklist, escalation paths. Representative of a knowledge-transfer deliverable.

Note: These documents are anonymized real-world deliverables. Client identifiers, server names, account IDs, embedded screenshots, headers, footers, and document metadata have all been stripped. Synthetic company name "Acme Corp" substituted throughout.

Ready to scope an integration?

Six-step intake. Fixed-bid SOW returned in 3 business days. $25K floor, $25K increments.

Office