.png)
Salesforce Sales Cloud Integration Guide
Connect Salesforce Sales Cloud with enterprise applications through REST, GraphQL, SOAP, Bulk, file, and event-driven APIs.
Salesforce Sales Cloud integration options at a glance
Salesforce Sales Cloud supports versioned REST APIs for object operations, SOQL, SOSL, composite requests, files, and reports, alongside GraphQL for supported related-data queries and SOAP for established typed integrations. Bulk API 2.0 handles asynchronous high-volume queries and ingest jobs. Salesforce also provides selected event and callback mechanisms, including Platform Events, Change Data Capture, Pub/Sub API, Outbound Messages, and custom callouts. Martini can consume these APIs, expose endpoints for supported callbacks, authenticate through configured OAuth credentials, schedule incremental or bulk workflows, map JSON, XML, and file payloads, and apply validation, deduplication, retry, and reconciliation logic.
| Integration point | Supported by Salesforce Sales Cloud? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | CRUD operations for Accounts, Contacts, Leads, Opportunities, Cases, Tasks, and Events; SOQL, SOSL, composite requests, relationships, files, reports, and metadata access. | Martini can consume Salesforce REST resources from workflows, paginate responses, transform payloads, and expose reusable APIs around Salesforce operations. |
| GraphQL APIs | Yes | Read supported Salesforce data and retrieve related data in a controlled response shape, sometimes reducing multiple read requests. | Martini can consume Salesforce GraphQL APIs and map the returned response into canonical or downstream models; object coverage must be verified for the target organization and API version. |
| SOAP APIs | Yes | Established typed integrations using Enterprise WSDL or generic Partner WSDL operations, including organizations with existing SOAP clients. | Martini can consume Salesforce SOAP services, manage XML mappings, and apply workflow-level error handling for legacy or strongly typed integrations. |
| Webhooks and outbound callbacks | Limited | Selected outbound notifications through Platform Events, Change Data Capture, Pub/Sub API, Streaming API, Outbound Messages, and custom callouts. | Martini can expose REST endpoints for supported Salesforce callbacks and validate, deduplicate, route, and process event-style payloads. Coverage is mechanism- and configuration-specific. |
| Bulk and asynchronous APIs | Yes | Large-volume queries, ingest jobs, migrations, scheduled exports, backfills, reconciliation, and batch upserts using external IDs. | Martini can submit Bulk API jobs, monitor their status, retrieve results, and orchestrate retries or reconciliation as a durable workflow. |
| File and attachment APIs | Yes | Transfer Salesforce Files through ContentVersion, ContentDocument, and ContentDocumentLink, with legacy Attachment support in applicable contexts. | Martini can separate file metadata from binary content, transform metadata, transfer payloads, and route large-content failures for retry or review. |
| Database and analytics access | Limited | Operational data is accessed through Salesforce APIs rather than direct relational database access; reporting and analytics are available through APIs where licensed and applicable. | Martini can consume Salesforce reporting or analytics endpoints and combine results with API data, but it should not assume direct Salesforce database connectivity. |
| Authentication | Yes | OAuth 2.0 through Connected Apps, including authorization code, JWT bearer, refresh-token, and supported client-credentials patterns. | Martini can use configured OAuth credentials and secure environment settings while keeping client secrets, certificates, private keys, and tokens outside workflow payloads. |
How Salesforce Sales Cloud exposes data and business events
Salesforce REST APIs
Salesforce versioned REST APIs provide general-purpose access to standard and custom objects, SOQL, SOSL, composite requests, relationships, files, reports, and metadata. They are the usual starting point for transactional Sales Cloud integrations.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates through the configured Connected App, calls the required REST resource, follows continuation URLs, maps the response, applies business rules, and writes the result to a target system or returns a controlled API response.
Implementation sequence
Salesforce GraphQL APIs
Salesforce GraphQL supports queries for supported Salesforce data and can retrieve related data while allowing the client to control the response shape. Coverage depends on the API version and Salesforce product context.
Martini implementation pattern
Martini implementation pattern: a workflow sends a carefully scoped GraphQL query, validates the returned structure, maps related objects into a canonical model, and routes the result to downstream services. REST remains appropriate where GraphQL coverage is insufficient or writes are required.
Implementation sequence
Salesforce SOAP APIs
Salesforce Enterprise and Partner SOAP APIs remain available for established integrations and strongly typed enterprise clients. Enterprise WSDL is organization-specific, while Partner WSDL is more generic across organizations.
Martini implementation pattern
Martini implementation pattern: a workflow constructs the required XML request, calls the Salesforce SOAP service, parses the typed response, and maps it into the target model. This approach is useful when an existing SOAP contract must be preserved.
Implementation sequence
Salesforce Bulk APIs
Bulk API 2.0 provides asynchronous query and ingest jobs for high-volume operations such as migrations, exports, backfills, and batch upserts of Accounts, Contacts, Leads, and Opportunities.
Martini implementation pattern
Martini implementation pattern: a workflow prepares a bulk payload, submits a job, polls or checks job state with bounded intervals, retrieves results, and records successful and failed rows for reconciliation.
Implementation sequence
Salesforce event notifications
Salesforce supports selected event and callback mechanisms through Platform Events, Change Data Capture, Pub/Sub API, Streaming API, Outbound Messages, and custom callouts. These mechanisms do not provide universal coverage for every Sales Cloud object or event.
Martini implementation pattern
Martini implementation pattern: Martini exposes an API endpoint or consumes the configured event channel, validates the event type and replay information, applies idempotency and routing rules, and invokes downstream workflows. Event ordering, retention, and delivery semantics are treated as mechanism-specific.
Implementation sequence
Common Salesforce Sales Cloud integration patterns
Pattern 1: Synchronize Salesforce customers to an ERP
When to use this pattern
Use this pattern when Salesforce Accounts and Contacts must be reflected in an ERP such as NetSuite for customer master, billing, or order processes. A scheduled incremental workflow is suitable when near-real-time events are not required.
Integration direction
Example Mapping
| Salesforce Sales Cloud Field | Canonical Field | Target Field |
|---|---|---|
| Account.Id | customer.sourceId | NetSuite external ID |
| Account.Name | customer.name | customer name |
| Contact.Email | customer.primaryContact.email | contact email |
| Account.BillingAddress | customer.billingAddress | billing address |
Martini implementation pattern
Martini queries Accounts and related Contacts using SystemModstamp or LastModifiedDate with an overlap window, follows pagination, validates required customer fields, and upserts NetSuite records using stable external identifiers. The workflow stores its watermark only after successful processing and routes permission, validation, and limit failures separately from transient retries.
Martini capabilities used
- workflows
- scheduled execution
- API consumption
- data mapping
- business rules
- idempotency
- error handling
Pattern 2: Distribute and qualify Salesforce Leads
When to use this pattern
Use this pattern when Leads require enrichment, duplicate detection, territory assignment, or marketing qualification before Salesforce ownership or status is updated.
Integration direction
Example Mapping
| Salesforce Sales Cloud Field | Canonical Field | Target Field |
|---|---|---|
| Lead.Id | lead.sourceId | lead external ID |
| Lead.Email | lead.email | person email |
| Lead.Status | lead.lifecycleStatus | lead status |
| Lead.OwnerId | lead.ownerId | owner reference |
Martini implementation pattern
A Martini workflow retrieves or receives selected Leads, validates email and required fields, applies duplicate and territory rules, and calls the downstream enrichment or marketing API. Approved results are mapped back to Salesforce using the Lead ID or an external identifier, while rejected or ambiguous matches are retained for review.
Martini capabilities used
- API consumption
- API exposure
- data mapping
- validation
- business rules
- deduplication
- retry handling
Pattern 3: Orchestrate Opportunity-to-order processing
When to use this pattern
Use this pattern when an Opportunity reaching a defined stage should initiate quoting, order creation, provisioning, or financial processing in another application.
Integration direction
Example Mapping
| Salesforce Sales Cloud Field | Canonical Field | Target Field |
|---|---|---|
| Opportunity.Id | deal.sourceId | sales order external reference |
| Opportunity.Amount | deal.amount | order total |
| Opportunity.StageName | deal.stage | order workflow status |
| Opportunity.CloseDate | deal.expectedCloseDate | requested date |
Martini implementation pattern
Martini receives a supported Salesforce event or finds qualifying Opportunities during a scheduled scan, verifies stage, approval, account, and product prerequisites, then invokes the downstream order or provisioning API. An idempotency key prevents duplicate orders, and status or target identifiers are written back to Salesforce after confirmed success.
Martini capabilities used
- event-driven workflows
- scheduled workflows
- API orchestration
- data transformation
- business rules
- idempotency
- compensation and retry logic
Pattern 4: Route Salesforce change events to applications
When to use this pattern
Use this pattern when selected Account, Contact, Case, or Opportunity changes need near-real-time distribution to several downstream applications and the required objects are covered by Change Data Capture, Platform Events, or another configured Salesforce mechanism.
Integration direction
Example Mapping
| Salesforce Sales Cloud Field | Canonical Field | Target Field |
|---|---|---|
| ChangeEventHeader.recordIds | event.sourceIds | source references |
| Account.Name | account.name | customer name |
| Case.Status | case.status | incident status |
| Opportunity.StageName | opportunity.stage | sales stage |
Martini implementation pattern
Martini exposes an endpoint for supported Salesforce callbacks or consumes the configured event channel, validates event metadata, checks replay and duplicate state, retrieves current data when necessary, and fans out normalized messages. Failed deliveries are retried with bounded backoff or placed into a reconciliation path, without assuming global ordering or exactly-once delivery.
Martini capabilities used
- API exposure
- webhook handling
- event routing
- data mapping
- queue or asynchronous execution
- deduplication
- monitoring and error handling
Applications commonly integrated with Salesforce Sales Cloud
Salesforce Sales Cloud can be integrated with adjacent business applications using each system's supported APIs, events, files, or integration services. Martini can orchestrate these exchanges while preserving ownership rules, identifiers, transformations, and operational controls.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| NetSuite | Synchronize Salesforce Accounts, Contacts, Opportunities, orders, invoices, and customer financial status with ERP processes. | Salesforce Sales Cloud → Martini → NetSuite | Use scheduled or event-driven workflows to retrieve changed Salesforce objects, map them to NetSuite records, apply external-ID and ownership rules, and retry or reconcile failed writes. |
| ServiceNow | Coordinate Salesforce accounts, customers, Cases, and service-request context with service operations managed in ServiceNow. | Salesforce Sales Cloud → Martini → ServiceNow | Expose or consume API endpoints for selected case and account exchanges, validate ownership, transform fields, and write correlation identifiers back to the source systems. |
| Workday | Synchronize worker, organization, territory, or account-ownership reference data where sales administration depends on HR-managed information. | Workday → Martini → Salesforce Sales Cloud | Schedule retrieval of approved Workday reference data, map users and organizational values to Salesforce fields, and apply validation before updating Salesforce. |
| Jira | Link Salesforce Opportunities, Cases, or product issues with engineering and delivery work tracked in Jira. | Salesforce Sales Cloud → Martini → Jira | Trigger workflows from selected Salesforce changes, create or update Jira issues, retain cross-system IDs, and send controlled status updates back to Salesforce. |
| Zendesk | Coordinate customer support Cases, Contacts, and account context between Salesforce and Zendesk. | Salesforce Sales Cloud → Martini → Zendesk | Use REST APIs or supported event callbacks to synchronize selected customer and support fields, with duplicate detection and explicit ownership for case status. |
| Shopify | Connect customers, orders, and commerce activity with Salesforce sales and customer-management processes. | Shopify → Martini → Salesforce Sales Cloud | Consume Shopify events or APIs, map commerce customers and orders to Salesforce objects, use external identifiers for upsert, and handle delayed or duplicate deliveries. |
| Marketo | Synchronize Leads, campaign activity, qualification status, and marketing attribution with Salesforce. | Marketo → Martini → Salesforce Sales Cloud | Orchestrate bidirectional API workflows for Lead and campaign fields, apply qualification and duplicate rules, and write Salesforce ownership or status changes when appropriate. |
| Microsoft Dynamics 365 | Synchronize customer, account, opportunity, or business-unit data during coexistence, migration, or multi-CRM operating models. | Microsoft Dynamics 365 → Martini → Salesforce Sales Cloud | Run staged or bidirectional workflows with field-level ownership, external IDs, conflict handling, and reconciliation reports rather than unrestricted overwrites. |
How to build a Salesforce Sales Cloud integration in Martini
Objective
Create the Salesforce Connected App configuration and select an OAuth pattern appropriate for interactive or server-to-server access.
Instructions in Martini
- Configure OAuth credentials, scopes, environment-specific endpoints, and integration-user permissions
- Store client secrets, refresh tokens, certificates, and private keys in secure configuration
- Verify object permissions, field-level security, sharing rules, and Connected App access
Objective
Select a scheduled, API-led, bulk, or event-driven trigger based on required latency, object coverage, and data volume.
Instructions in Martini
- Use a scheduler for incremental synchronization or reconciliation
- Use a Martini API endpoint for supported Salesforce callbacks
- Use Bulk API workflows for high-volume queries and ingest jobs
- Confirm that the selected Salesforce event mechanism covers the required object and event
Objective
Read Salesforce data efficiently while preserving pagination, query selectivity, relationships, and synchronization state.
Instructions in Martini
- Query only required fields with selective SOQL filters
- Follow REST continuation URLs and use the appropriate Bulk result lifecycle
- Persist SystemModstamp, LastModifiedDate, replay information, or another reliable checkpoint
- Retrieve current Salesforce data when an event payload is only a notification
Objective
Coordinate Salesforce calls, downstream APIs, conditional routing, asynchronous work, and completion state in a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, retrieval, transformation, target writes, and checkpoint updates
- Use conditional branches for validation, ownership, and target-system responses
- Use bounded concurrency and asynchronous processing for large or fan-out workloads
- Retain Salesforce IDs, external IDs, correlation IDs, and job identifiers
Objective
Convert Salesforce object, relationship, file, JSON, XML, or bulk data into the canonical model required by downstream applications.
Instructions in Martini
- Map Account, Contact, Lead, Opportunity, Case, Task, and Event fields explicitly
- Preserve parent references, Salesforce IDs, external IDs, and custom API names
- Normalize dates, addresses, statuses, currencies, and related-object structures
- Handle Salesforce Files metadata and binary content separately when practical
Objective
Enforce data ownership, validation, deduplication, approval, and conflict rules before writing to another system or Salesforce.
Instructions in Martini
- Validate required fields and organization-specific custom fields
- Use stable external identifiers and upsert semantics where appropriate
- Prevent overwriting Salesforce-managed, calculated, approved, or automation-controlled values
- Define the system of record for each field in bidirectional flows
Common Salesforce Sales Cloud data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Account | Represents organizations or companies and their commercial relationships. | NetSuite, ServiceNow, Zendesk, Microsoft Dynamics 365 | Martini retrieves changed Accounts through REST, GraphQL, SOAP, or Bulk APIs, maps Salesforce IDs and external IDs, and applies ownership and deduplication rules. |
| Contact | Represents individuals associated with Accounts. | NetSuite, Zendesk, Marketo, Shopify | Martini maps Contact relationships and communication fields, validates required values, and uses upsert or controlled updates to avoid duplicate people. |
| Lead | Represents prospective customers before qualification or conversion. | Marketo, Shopify, Microsoft Dynamics 365 | Martini routes Leads for enrichment or qualification, applies status and ownership rules, and returns approved changes to Salesforce. |
| Opportunity | Represents potential sales transactions with amount, stage, close date, and forecast information. | NetSuite, Jira, Microsoft Dynamics 365 | Martini monitors stage changes, validates approval and ownership conditions, and invokes downstream quoting, order, provisioning, or reporting workflows. |
| Case | Represents customer service issues or support requests. | ServiceNow, Zendesk, Jira | Martini synchronizes selected case fields and references, preserves source identifiers, and applies explicit rules for status ownership and duplicate events. |
| Task | Represents planned or completed activities associated with Salesforce records. | ServiceNow, Jira, Marketo | Martini maps activity ownership, due dates, and related Salesforce IDs into downstream work models and handles validation failures without overwriting completed work. |
Authentication and security considerations
OAuth and Connected Apps
Salesforce API integrations normally use OAuth 2.0 through a Connected App. Authorization code, JWT bearer, refresh-token, and supported client-credentials patterns can be selected according to the integration context.
Least-privilege access
OAuth success does not guarantee access to every Salesforce object or field. The integration user remains subject to profiles, permission sets, field-level security, sharing rules, Connected App scopes, and organization settings.
Secure configuration
Store client secrets, refresh tokens, certificates, private keys, and environment-specific Salesforce endpoints in secure Martini configuration. Do not embed credentials in workflows, mappings, source code, or payloads.
Operational considerations for Salesforce Sales Cloud integrations
Limits and pagination
Salesforce applies organization and feature-specific limits for API requests, queries, Bulk API jobs, and event delivery. Use selective queries, pagination, composite or bulk operations, bounded concurrency, and controlled polling.
Incremental processing
Persist SystemModstamp or LastModifiedDate watermarks with a safe overlap window. Event-driven flows should retain replay information where applicable and must tolerate duplicate delivery and mechanism-specific ordering.
Schema and permissions
Salesforce organizations commonly use custom fields and objects. Use describe or metadata information where appropriate, verify field-level access, and test API-version changes before production upgrades.
Retries and reconciliation
Distinguish transient errors, limit responses, authentication failures, validation rules, duplicate rules, locked records, and permission errors. Retry only suitable failures and retain failed rows, event identifiers, and correlation IDs for reconciliation.
Files and bidirectional ownership
Salesforce Files require attention to binary content, versions, ContentDocument relationships, permissions, and payload size. Bidirectional integrations should define field ownership to prevent uncontrolled overwrites.
Why use Martini instead of scripts or point-to-point integrations?
Reusable integration workflows
Martini separates authentication, retrieval, transformation, business rules, target writes, checkpointing, and error handling into maintainable workflows rather than embedding logic in isolated scripts.
API-led integration
Martini can consume Salesforce REST, GraphQL, SOAP, Bulk, and event endpoints and can expose controlled APIs for callbacks or applications that need Salesforce data and operations.
Reliable data movement
Scheduled, event-driven, asynchronous, and bulk patterns can share mapping, validation, idempotency, retry, monitoring, and reconciliation logic. This is useful when Salesforce must connect to several applications with different data models.
Environment control
Secure configuration keeps OAuth credentials, API versions, endpoints, and organization-specific mappings separate from workflow logic, supporting controlled promotion and operational maintenance.
Frequently asked questions
Salesforce Sales Cloud can integrate through versioned REST APIs, GraphQL queries, SOAP APIs, Bulk API 2.0, Salesforce Files APIs, and selected event or callback mechanisms such as Change Data Capture, Platform Events, Pub/Sub API, and Outbound Messages. OAuth through a Connected App is normally used for API access.
Yes. Martini can integrate with Salesforce Sales Cloud by consuming its REST, GraphQL, SOAP, Bulk, file, and supported event APIs, using configured OAuth credentials, exposing API endpoints for callbacks, and orchestrating mappings, validation, synchronization, and error handling.
No. A dedicated Salesforce connector is not required. Martini can use Salesforce's native APIs, OAuth authentication, Bulk services, file endpoints, and supported event or callback mechanisms through standards-based workflows and APIs.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Salesforce Sales Cloud with Martini. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Salesforce, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
REST is generally the starting point for transactional object operations. GraphQL is useful for supported read-oriented queries involving related data, SOAP remains relevant for established typed integrations, and Bulk API 2.0 is suited to large asynchronous loads, exports, migrations, and backfills.
No. Salesforce provides several event and callback mechanisms, but coverage is selected and mechanism-specific. The implementation must verify whether the required object and event is supported by Change Data Capture, Platform Events, Pub/Sub API, Outbound Messages, Streaming API, or another configured facility.
A scheduled Martini workflow can query Salesforce with SystemModstamp or LastModifiedDate filters and persist a safe watermark with an overlap window. For supported objects and lower-latency use cases, Change Data Capture or another Salesforce event mechanism can drive synchronization, with duplicate and replay handling.
Martini maps Salesforce fields and relationships into canonical or target models, applies validation and ownership rules, and uses external identifiers and upsert operations where appropriate. Workflows can distinguish retryable limit or transient failures from permission, validation, duplicate-rule, and schema errors, while idempotency and reconciliation controls address repeated delivery.
Related Martini documentation
Events and Files
Workflow Design
Mapping and Security
Connect Salesforce Sales Cloud with Martini
Use Martini to build maintainable Salesforce Sales Cloud integrations across APIs, events, files, and enterprise workflows.