A Salesforce ERP integration can connect customer-facing work with finance, inventory, fulfillment, or other operational processes. But connecting systems is not the same as agreeing on what they should share, who owns each record, or what happens when an update fails. Before signing a statement of work, evaluate the business outcomes, boundaries, controls, and recovery plan—not just the connector or diagram.
Discuss your integration requirements
What should a Salesforce ERP integration accomplish?
Start with a business process, not a product feature. List the work that currently crosses between Salesforce and the ERP: for example, converting an approved opportunity into an order, checking product availability during a sales conversation, or returning invoice status to a customer-facing team. These are possible use cases, not assumptions about what your systems support. Confirm each one against your specific Salesforce edition, ERP configuration, licenses, existing customizations, and operating procedures.
For each use case, record the current problem and the desired change. “Connect Salesforce to the ERP” is not testable. “When an approved order is created, the sales team can see its ERP order number and status without rekeying the details” is closer, but still needs specific ownership, timing, exception, and acceptance rules.
Who needs the information? Identify the roles that create, review, or act on it. When do they need it? Distinguish an immediate operational need from a scheduled update. What decision or action will it support? Tie the exchange to a work step and business result. What is the current workaround? Document spreadsheets, duplicate entry, email, or manual checks that the project should address. How will you tell whether it worked?* Define observable acceptance criteria, such as accurate mapped fields, reduced re-entry, or visibility into exceptions.
Rank use cases by business impact, risk, and readiness. A process with clear ownership and stable data may be a better first release than a high-value process whose policies and source records are still disputed. If your wider program includes Salesforce consulting and implementation services, make sure integration work is planned alongside the business process changes it supports.
Which systems and teams own each part of the process?
Ownership is a design decision and a statement-of-work requirement. For every record type and important field, name the authoritative source and the team accountable for its quality. Salesforce may own a sales relationship or opportunity stage while an ERP owns a posted invoice or inventory balance. But this division depends on the actual process; do not assume that one system is always the master for an entire object.
Make a field-level ownership matrix before implementation. Include customer or account identifiers, product references, order details, pricing inputs, shipment or fulfillment status, and financial status only when they are in scope. Capture the system of record, permitted editors, validation rules, and how changes move across systems. If two systems can edit the same value, specify which update wins, whether a user can override it, and how conflicts are identified.
| Evaluation area | What to document before signing | Useful acceptance evidence |
|---|---|---|
| Business process | Trigger, users, handoffs, desired result, and exclusions | Named scenarios pass with the agreed roles and sample records |
| Data ownership | System of record by object and field, identifier rules, and edit rights | Mapped fields match approved examples; conflicts follow documented rules |
| Synchronization | Direction, trigger or schedule, timing expectation, and ordering | Updates arrive within the agreed window and duplicate events are handled as specified |
| Error recovery | Detection, alert recipient, retry policy, manual correction, and audit trail | Test failures are visible, recoverable, and do not silently lose or duplicate work |
| Security | Data classification, access, credentials, logging, and environment controls | Approved roles and access paths are verified in test conditions |
| Testing and rollout | Scenarios, data, owners, cutover steps, rollback or containment plan | Business owners approve results and sign off on release readiness |
| Support | Operational owner, monitoring, incident route, and change process | Named support roles and escalation steps are documented and rehearsed |
This matrix is not a substitute for a technical design. It makes the intended behavior explicit enough for your team and prospective partner to identify missing decisions. It also helps keep the integration proportionate: not every field, object, or process needs to move in both directions.
How should you define the synchronization boundary?
Specify what moves, in which direction, under what condition, and with what timing expectation. A useful scope separates data that must be exchanged from data that merely could be. For each exchange, state the business event that starts it, whether the change is one-way or two-way, the relevant fields, required identifiers, and the expected result in the receiving system.
Be explicit about timing. Some processes can tolerate a scheduled batch; others may depend on a more immediate status update. Ask the partner to explain the implications for your use case and proposed method, including limits, dependencies, and what users will see while an update is pending. Do not accept vague commitments such as “real time” without a defined measurement, trigger, and exception behavior.
Define important edge cases early: a customer record exists in only one system, a product identifier is missing, an order changes after submission, a record is merged, or an update arrives out of sequence. Decide whether the integration creates a new record, rejects the event, queues it for review, or uses another approved rule. Record what is out of scope as carefully as what is included.
Ask the partner to show how the proposed boundaries relate to your existing systems and business model. Omnivo Digital describes work across retail and consumer goods and financial services, where operating processes and information needs can differ. Those examples are not a prescribed integration design; your requirements should reflect your own applications and controls.
What should happen when an update fails?
Every integration has conditions it cannot process as expected: unavailable systems, invalid values, missing references, changed permissions, or records that violate business rules. A credible scope explains how the team will detect a failure, who will be notified, where the issue can be reviewed, and how an authorized person can correct and retry it.
Ask for an error-handling walkthrough using a realistic example. Can an operations user distinguish a temporary failure from a data problem? Is the affected record identifiable without exposing unnecessary sensitive information? Is there a safe retry mechanism? What prevents a retry from creating a second order or duplicating another consequential action? Which errors require technical support, and which can be corrected by a trained business user?
Define which failures retry automatically and under what limits. Specify how non-recoverable items are held and surfaced for review. Identify the record or event needed to trace the issue from source to destination. Agree on who corrects source data and who restarts or reprocesses the exchange. Include duplicate prevention and conflict handling in scenarios where repeated or out-of-order events are possible. Set expectations for alert routing and response ownership; a notification is not the same as resolution.
Also ask how operational history will be retained and who can access it. The purpose is to diagnose and manage the process, not to create broad access to sensitive data. Include failure handling in acceptance tests rather than treating it as a later support enhancement.
How should security and access be addressed?
Security requirements should follow the information and users involved. Inventory the data exchanged, classify sensitive fields, and decide which system accounts and human roles need access. Ask the partner to document how integration credentials are provisioned, restricted, stored, rotated, and monitored in the environments used for development, testing, and production. Confirm who within your organization approves access and how it is removed when no longer needed.
Review what appears in logs, alerts, test files, and support tickets. They should provide enough context to troubleshoot without unnecessarily reproducing sensitive information. Establish whether test data may be copied from production or whether approved synthetic or masked data is required. Include any retention, review, and access expectations that your internal policies require.
Do not settle for a generic statement that the solution is “secure.” Ask the proposed partner to map your actual requirements to the specific systems, access model, environments, and operational responsibilities. If your organization has regulatory or contractual obligations, bring the relevant internal owner into discovery before the scope is fixed. The integration team should not be asked to infer your compliance requirements.
What testing proves the integration is ready?
Testing should cover the full business journey, not only whether a connection can send a sample payload. Build scenarios around normal activity, boundary conditions, and failure recovery. Include the people who own the process so that technical success is not mistaken for business readiness.
Field mapping: Confirm representative values, formats, required fields, and identifier matching in both systems. Process behavior: Run an end-to-end example from the initiating action through the receiving system and back to the user-visible outcome. Permissions: Verify that authorized users and system connections can do only what the approved design allows. Exceptions: Test missing references, rejected values, unavailable systems, retries, duplicates, and manual correction paths that apply to the scope. Volume and timing: Confirm the agreed expected workload and timing behavior with a realistic test approach approved by the technical owners. Regression: Check that releases or changes do not disrupt the existing business steps the integration touches. User acceptance:* Have process owners confirm that the information is understandable, timely enough, and actionable in their actual work.
The statement of work should say who supplies test data, who prepares scenarios, who executes each test, how defects are triaged, and who can approve a fix. Define what constitutes a pass, how retesting works, and what happens if a key scenario is incomplete near a planned release. For additional context on moving and preparing records, see these Salesforce data migration best practices; integration and migration are distinct scopes, but they may share data-quality questions.
How should rollout, support, and change control work?
Plan a rollout around business readiness and the consequences of a failed exchange. The scope should describe deployment sequence, configuration promotion, cutover responsibilities, user communication, and a means to pause or contain the integration if unexpected behavior occurs. Define any rollback or recovery approach that is feasible for the chosen design. In some cases, reversing a data exchange may not be simple; ask what can be restored, what must be corrected forward, and who decides.
Make ownership clear after go-live. Name the business owner who can prioritize process issues, the technical owner who can investigate system behavior, and the support route users should follow. Specify what monitoring is included, who reviews alerts, how incidents are escalated, and how routine changes are requested, tested, approved, and released. If ongoing help is needed, clarify whether it sits within the project scope or requires a separate support arrangement.
Knowledge transfer should leave your team able to operate the solution within its agreed responsibilities. Ask for current integration diagrams, configuration notes, field mappings, known limitations, test cases, runbooks, access ownership, and a walkthrough of common failure scenarios. Confirm which deliverables are included and in what format; do not rely on an informal promise to explain the system at the end.
What should the statement of work make explicit?
A strong statement of work connects outcomes to deliverables, responsibilities, assumptions, and acceptance. Review it for enough detail to prevent a broad integration goal from becoming an open-ended technical exercise. A project may use a standard connector, middleware, custom logic, or a mix, but no option is automatically right for every combination of Salesforce, ERP, requirements, and team capability.
Check that the document identifies:
Included use cases and exclusions: Processes, objects, fields, directions, timing expectations, and known edge cases. Dependencies and assumptions: System access, licenses, environments, vendor participation, data readiness, and decisions your team must supply. Design and build deliverables: Approved mappings, interface or configuration documentation, and implementation items relevant to the selected approach. Testing and acceptance: Scenario ownership, defect handling, pass criteria, approval authority, and retest expectations. Deployment and handoff: Cutover plan, operational documentation, training or knowledge transfer, and post-release responsibilities. Change control: How a new object, workflow, requirement, or constraint is assessed and approved if it changes the agreed scope. Commercial and schedule conditions:* Milestones, prerequisites, decision dates, and the effect of unresolved dependencies.
Look for language that sounds precise but leaves the main decisions unanswered. “Integrate customer and order data” should be supported by a field list, ownership rules, scenarios, and exceptions. “Provide monitoring” should identify what is monitored and who acts. “Complete testing” should specify the scenarios, participants, and approval criteria. If the partner cannot answer every question before signing, distinguish a discovery deliverable from commitments that depend on discovery results.
How can you compare integration partners fairly?
Compare proposals against one common set of business scenarios and evaluation criteria. Otherwise, one proposal may include error management and business testing while another prices only a basic transfer of data. Ask each firm to explain its assumptions and exclusions in the same format.
| Criterion | Questions to ask | What a useful answer includes |
|---|---|---|
| Business understanding | How did you translate our process into integration requirements? | Concrete scenarios, owners, outcomes, and unresolved decisions |
| Architecture fit | Why does this approach suit our systems and constraints? | Trade-offs, dependencies, limitations, and alternatives rather than a universal claim |
| Data and exceptions | How will conflicts, invalid data, and repeated events be managed? | Specific ownership, detection, recovery, and test behavior |
| Delivery and acceptance | How will we know each phase is complete? | Deliverables, acceptance evidence, responsible owners, and decision points |
| Operational readiness | Who supports this after release and how are changes managed? | Monitoring, escalation, documentation, training, and clear responsibility boundaries |
| Commercial clarity | What could change the proposed scope or schedule? | Explicit assumptions, dependencies, exclusions, and a change process |
Ask for relevant experience without assuming that an example proves the proposed design will fit your company. For instance, a partner's Metroll case study or Unison case study can provide context about work described by Omnivo Digital, but your evaluation still needs to establish fit with your systems, data, and desired process. You can also review the firm’s broader Salesforce expertise as part of your own diligence.
Finally, compare how each partner handles uncertainty. A credible proposal separates what is known from what requires discovery, explains how decisions affect cost or timing, and avoids promising one architecture before validating the constraints. Omnivo Digital describes a product-management approach and phased implementations; ask any prospective partner to show how its own method will prioritize your requirements and preserve your team's ability to make informed trade-offs.
Which questions should you answer before signing?
Use this short checklist in your internal review and partner discussions:
- Which business process is the first release meant to improve, and how will the owner measure acceptance?
- Which system owns each important record and field, and who resolves conflicting updates?
- What exact data moves in each direction, in response to which event, and within what agreed timing?
- What is explicitly excluded, including related workflows, history, or records not yet ready?
- How are failures, retries, duplicates, and manual corrections detected and managed?
- Which security, access, environment, logging, and data-handling requirements apply?
- Who supplies scenarios and test data, and who approves business readiness?
- What are the cutover, containment, support, and change-control responsibilities?
- Which assumptions or unresolved decisions could affect delivery, and how will changes be approved?
If answers are incomplete, put them on a decision log with an owner and due date. Decide whether each item must be settled before signing, belongs in a time-boxed discovery phase, or can remain an explicitly documented assumption. This turns uncertainty into a managed project condition instead of a hidden expectation.
Talk through your Salesforce ERP integration scope
Frequently asked questions
Does Salesforce need to synchronize every ERP field?
No. Define the minimum information needed for each approved business process. Sharing unnecessary fields can add mapping, access, testing, and support work without improving the user's task. Include a field only when an owner can explain its purpose and expected behavior.
Should updates move in real time or on a schedule?
It depends on how quickly users need the information and what the systems and chosen integration method can support. Define the business timing requirement first, then ask the technical owners to validate the approach, dependencies, and behavior during delays or failures.
Can one connector work for every Salesforce ERP integration?
No single connector or architecture should be assumed to fit every environment. The choice depends on the specific ERP and Salesforce configuration, data, processes, constraints, and operational capabilities. Require the partner to explain the fit and trade-offs for your situation.
What is the most important item to settle before signing?
There is no one item for every project, but ownership and acceptance are foundational. If your team has not agreed on the source of truth, expected process behavior, and evidence of completion, it will be difficult to judge either the design or the finished work.
A well-scoped integration begins with decisions your business can explain and validate. Document those decisions, test the exceptions as deliberately as the normal flow, and make operational ownership part of the agreement so the connection remains understandable after launch.