Vicedomini Softworks

Software Integrations

Architects: Salesforce Integration Patterns, Costs, and Checklist

23 September 2026

Architects: Salesforce Integration Patterns, Costs, and Checklist

For most organisations, the right approach is to match the integration pattern to the business need: use data virtualisation whenever a live view of external data will do, and reserve MuleSoft or Data 360 replication for enterprise-scale volumes or offline resilience. The immediate next step is not procurement. It is a short discovery phase and a proof of concept that tests timing, data volumes and governance before any code gets written.

TL;DR:

  • Virtual integration is recommended as the default approach unless high data volume or offline resilience demands the use of replication tools like MuleSoft or Data 360.
  • The most common mistake in integration projects is choosing the wrong pattern early, leading to rework if process, data, or virtual designs are not properly aligned with needs.
  • A proof of concept and discovery phase is essential before committing to architecture, especially to evaluate timing, governance, and data volume constraints.
  • Small to medium integrations (up to 20 weeks) typically cost less than high-volume enterprise projects, which can take three to nine months and incur higher licensing and development costs.
  • Avoid duplicating data unnecessarily, as it can cause conflicts with Salesforce limits and drift from the single source of truth, especially in bidirectional or multi-org setups.
Vicedomini Softworks
Plan Your Integration With Engineers
Vicedomini Softworks helps organisations design, integrate, modernise, and maintain reliable software across complex technology ecosystems.
Explore software engineering

Table of Contents

Cos’è l’integrazione Salesforce e quali pattern usare

Every integrazione Salesforce project reduces to three canonical designs, and picking the wrong one early is the single most common source of rework later. Salesforce’s own architecture documentation frames them as process, data and virtual integration, and the distinction matters more than most implementation plans admit.

  • Process integration (Remote Process Invocation) triggers an action in another system the moment something happens in Salesforce, typically synchronously, and suits workflows like order confirmation or credit checks where the caller needs an immediate answer.
  • Data integration (Batch Data Synchronization) moves records between systems on a schedule, asynchronously, and fits nightly reconciliation, bulk imports or reporting feeds where a few hours of lag is acceptable.
  • Virtual integration (Data Virtualisation) leaves data where it lives and exposes it to Salesforce on demand, avoiding a second copy of the record altogether.

The trade-offs sit in timing and consistency. Synchronous process calls are fast but fragile: a downstream outage stalls the calling transaction. Batch synchronisation tolerates outages but risks stale data between runs. Virtualisation keeps a single source of truth and sidesteps reconciliation work, though it depends on the target system’s own availability and response times. The most frequent pitfall is duplicating data that did not need duplicating, which then collides with Salesforce’s governor limits and produces two versions of the truth that quietly drift apart.

Choosing between low-code, hybrid and pro-code integration

Six variables decide which category of tool fits: data direction (one-way or bidirectional), latency tolerance, data volume, who owns the integration long-term, how maintainable the result needs to be, and total cost of ownership. Salesforce’s integration decision guide maps these directly onto three tool tiers.

  1. Low-code: Flow and External Services handle straightforward, moderate-volume connections where an admin, not a developer, needs to maintain the logic over time.
  2. Hybrid/enterprise: MuleSoft Anypoint and Data 360 take over once you need prebuilt connectors, complex orchestration across many systems, or a unified customer profile spanning several orgs.
  3. Pro-code: custom Apex and bespoke REST or GraphQL APIs earn their cost when the logic is genuinely unique, volumes are high, or you need fine-grained control over retries and error handling that no packaged connector offers.

Licensing tips the calculation more than people expect. A paid platform like MuleSoft looks expensive against a free Flow, but once you count developer hours spent maintaining brittle point-to-point Apex callouts across five or six systems, the platform frequently wins on total cost within eighteen months.

Pro Tip: Before comparing tool prices, map your integration count first. Three integrations rarely justify an enterprise platform; eight or more usually do.

How ERP, marketing and analytics integrations actually work

Most integrazione Salesforce requests fall into a handful of recurring shapes, and recognising which one you are dealing with saves weeks of architecture debate.

  • ERP synchronisation: Salesforce is a CRM, not an ERP, and was never built to replace one. The typical flow runs lead to quote to invoice, and Salesforce Billing acts as the bridge, converting CPQ output into transactional records an ERP can consume without custom middleware for every revenue event.
  • Marketing automation: inbound campaign data tends to arrive in bursts. Change data capture streamed into Data 360 handles this better than nightly batch jobs, because campaign response windows are short and stale data means a missed follow-up.
  • Analytics: the choice is ingest versus virtualise. Data 360 supports zero-copy access alongside batch and streaming ingestion, so when the goal is a dashboard rather than a transactional record, zero-copy avoids storing a second copy of data you already own elsewhere.
  • Cross-org and multi-org companies: the recurring risk is the update loop, where two orgs each treat the other’s sync as a new change and re-fire indefinitely. Change-origin tracking, as used in a documented Salesforce and Microsoft Dynamics integration that ran bidirectional sync across accounts, products and orders, breaks that loop by flagging which system authored each change.

Security, testing and monitoring checklist

A working proof of concept is not the same as a production-ready integration. Before go-live, run through this list.

  1. Integration user: create a dedicated API-only profile for every automated connection rather than reusing a human’s credentials. This isolates system-to-system traffic for audit logging and credential rotation.
  2. Sandbox testing: validate the full data path, including error conditions, in a sandbox before touching production records.
  3. Anti-loop detection: apply change-origin tracking so updates that originated externally are not re-synced back to their source.
  4. Idempotency: design every write so retrying it twice does not create duplicate records.
  5. Monitoring and SLAs: define retry policies, alert thresholds and error queues before launch, not after the first failure.
  6. Data governance: agree deduplication rules, master data ownership and consent handling early, since retrofitting them later touches every downstream integration.

Pro Tip: Instrument observability from day one, even on a small integration. Teams that skip monitoring on “simple” syncs are usually the ones firefighting silent data drift six months later.

What integration projects typically cost and how long they take

Every integrazione Salesforce engagement moves through the same phases: discovery, data mapping, proof of concept, build, test, deployment and ongoing monitoring. Skipping discovery to save a week routinely costs a month later in rework.

  • Small integrations (a single system, moderate volume): 4 to 8 weeks.
  • Medium integrations (two or three systems, some custom logic): 8 to 20 weeks.
  • Large or enterprise integrations (multi-org, high volume, strict SLAs): 3 to 9 months.

Cost drivers cluster around four variables: connector licensing (MuleSoft or Data 360 modules), the volume of custom development needed beyond what packaged connectors cover, raw data volume and its effect on infrastructure sizing, and the strictness of the SLA. A nightly batch job with tolerance for a few hours’ delay costs far less to build and run than a real-time bidirectional sync with sub-second latency guarantees.

How Vicedomini Softworks approaches Salesforce integration work

Vicedomini Softworks runs integration engagements without an account-manager layer between the client and the engineers actually writing the API contracts and message schemas. That structure matters most in integration work, where a misread requirement about data direction or transaction timing surfaces weeks later as a production defect if it passes through several hand-offs first.

The technical capabilities that carry an integration from proof of concept to production include REST and GraphQL API design, message-driven architectures for asynchronous flows, and containerised deployment on Kubernetes with the observability needed to catch a broken sync before it silently corrupts records. For readers assessing whether a given integration warrants custom engineering or a packaged connector, Vicedomini Softworks’s service catalogue outlines the systems integration and API development work this covers.

Salesforce integration architecture components

An engineer’s view on getting integration right

The mistake I see most often is teams replicating data by default, out of habit, rather than asking whether a live view would have served just as well. Virtualisation should be the starting assumption, not the fallback. Where replication genuinely earns its place, it deserves the same governance rigour as any system of record. Run the discovery and the proof of concept before committing to an architecture, and put observability in place before scale, not after the first incident forces your hand.

— Pepe F.

Get help planning your Salesforce integration

Vicedomini Softworks approaches integration work the way it approaches every engagement: no account managers between you and the engineers designing your API contracts, no vendor bias towards one connector over another, and a written recommendation at the end of every consulting phase so decisions stay auditable.

Vicedomini Softworks

If your integrazione Salesforce project spans an ERP, a marketing platform or a cross-org data model, the risk is rarely the code itself. It is the architecture decisions made before anyone writes a line. Vicedomini Softworks’s Initial Assessment, priced from €3,500 as a one-off engagement, maps your current systems, data volumes and governance requirements against the pattern that actually fits, before you commit to a platform or a build. For integration programmes that need ongoing technical leadership rather than a single assessment, the CTO Advisory plan starts from €1,800 per month. Broader integration engineering, API development and long-term support sit under the full services catalogue. Request the initial assessment to get a concrete architecture recommendation before your next sprint planning session.

Sources

For teams wanting to go deeper into the technical decisions this article covers, these sources are worth bookmarking.

For e-commerce specific integration work, teams running Salesforce Commerce Cloud alongside their CRM may also find this SEO automation resource useful when aligning integration timing with catalogue and campaign data.

FAQ

Quanto costa la licenza di Salesforce?

Salesforce prices its licences per user, per month, across several editions with different feature sets, and the exact figure depends on which cloud and edition you choose. Current pricing is published directly on Salesforce’s own site rather than fixed at a single rate.

Per cosa si usa Salesforce?

Salesforce is a customer relationship management platform used to track sales pipelines, service cases, marketing campaigns and customer data in one system. It is not an ERP, so it typically works alongside, rather than instead of, financial and operations systems.

Quali sono i moduli di Salesforce?

Salesforce organises its functionality into clouds covering sales, service, marketing, commerce and analytics, plus Data 360 for unified data management. Which modules a given organisation needs depends on whether the priority is pipeline management, customer support, campaign automation or cross-system data harmonisation.

Cosa significa Sfdc?

SFDC stands for Salesforce.com, the platform’s original domain name and one of its earliest shorthand references still used by IT teams and job postings. It refers to the same Salesforce CRM platform discussed throughout this article, not a separate product.

Quando conviene usare MuleSoft invece di Flow?

MuleSoft earns its cost once you are managing several complex integrations with prebuilt connectors and enterprise-scale orchestration needs, while Flow and External Services suit simpler, lower-volume connections an admin can maintain. Teams running three or fewer straightforward integrations rarely need MuleSoft’s overhead.