.png)

Salesforce Health Cloud Integration Guide
Salesforce Health Cloud integrates with enterprise systems through Salesforce REST, GraphQL, SOAP, Bulk, event, file, and authentication APIs.
Salesforce Health Cloud integration options at a glance
Salesforce Health Cloud is built on the Salesforce platform, so enterprise integrations use Salesforce APIs and event mechanisms rather than a separate Health Cloud transport protocol. REST APIs support SOQL, CRUD, Composite requests, metadata, and related resources; GraphQL can retrieve supported related data; SOAP remains useful for WSDL-based and legacy integrations; and Bulk API 2.0 supports large asynchronous loads and queries. Selected objects can publish Change Data Capture events, Platform Events, Pub/Sub traffic, or outbound messages. Martini can consume these interfaces, receive configured callbacks, orchestrate workflows, map Health Cloud objects, apply validation and business rules, and expose APIs for connected systems.
| Integration point | Supported by Salesforce Health Cloud? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Use Salesforce REST API for SOQL and SOSL queries, CRUD operations, Composite requests, metadata, relationships, and content-related resources. | Martini can consume REST endpoints from workflows, manage environment-specific URLs and tokens, transform payloads, and expose REST APIs for connected systems. |
| GraphQL APIs | Yes | Salesforce GraphQL can retrieve supported related data in fewer requests, subject to the target org's schema, permissions, API version, and Health Cloud configuration. | Martini can consume Salesforce GraphQL APIs, map responses, and handle GraphQL-specific authentication and errors. |
| SOAP APIs | Yes | Salesforce SOAP API supports strongly typed WSDL-based enterprise integrations and existing legacy implementations. | Martini can consume SOAP services, transform XML responses, and preserve compatibility with established WSDL-based workflows. |
| Webhooks / outbound callbacks | Limited | Outbound Messages and other callback-style mechanisms can notify external systems for selected workflow or event scenarios; coverage is not universal across Health Cloud changes. | Martini can expose webhook-capable APIs or workflows, validate inbound notifications, retrieve authoritative Salesforce data, and process callbacks safely. |
| Events | Limited | Change Data Capture, Platform Events, PushTopic events, and Pub/Sub API provide event streams for selected objects and configured channels. | Martini can receive supported event traffic, use events as workflow triggers, retrieve complete records, and combine event processing with scheduled reconciliation. |
| Bulk / async / batch APIs | Yes | Bulk API 2.0 supports high-volume insert, update, upsert, delete, and query jobs for migrations, backfills, and recurring synchronization. | Martini can submit jobs, poll status, retrieve results, process partial failures, persist checkpoints, and restart safely. |
| File / attachment APIs | Yes | Salesforce Files use ContentVersion, ContentDocument, and ContentDocumentLink; legacy Attachment availability varies by org and object. | Martini can orchestrate binary retrieval and upload separately from JSON processing, map file relationships, and apply permission and duplicate checks. |
| Authentication | Yes | Salesforce supports OAuth 2.0 authorization code, JWT bearer, client credentials where enabled, device or user-agent flows, and applicable session-based access. | Martini can use secure configuration for tokens, certificates, private keys, scopes, instance URLs, API versions, and environment-specific credentials. |
| Database / analytics access | Limited | Salesforce provides reporting and CRM Analytics APIs, but customers do not receive direct relational access to the underlying Salesforce platform database. | Martini can consume supported analytics or reporting APIs and orchestrate results without assuming direct Salesforce database connectivity. |
How Salesforce Health Cloud exposes data and business events
Salesforce REST APIs
Salesforce REST API is the primary general-purpose interface for SOQL and SOSL queries, CRUD operations, Composite requests, metadata, relationships, and selected file resources. The available Health Cloud objects and fields depend on the target org, licenses, permissions, and API version.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to Salesforce, retrieves or receives input, calls the required REST resource, maps the response to a canonical model, applies validation and business rules, and writes to the target system. Pagination, query locators, external IDs, and API limits are handled as workflow state.
Implementation sequence
Salesforce GraphQL APIs
Salesforce GraphQL can retrieve supported related data in a single request, but object, field, mutation, and version availability must be verified for the Health Cloud org. REST and Composite APIs remain established choices for many write-oriented integrations.
Martini implementation pattern
Martini implementation pattern: a workflow sends a governed GraphQL request, validates the returned data shape, maps nested relationships into the target model, and handles GraphQL errors separately from transport failures. The design should fall back to REST where the required Health Cloud object or operation is not exposed.
Implementation sequence
Salesforce SOAP APIs
Salesforce SOAP API provides a strongly typed WSDL-based interface for enterprise and legacy integrations. It remains relevant where generated clients, existing contracts, or established SOAP workflows must be preserved.
Martini implementation pattern
Martini implementation pattern: a workflow consumes the Salesforce SOAP service, transforms XML and typed responses, applies validation, and routes SOAP faults or business errors through controlled handling. New designs should assess REST, Composite, Bulk, or event APIs first unless SOAP compatibility is required.
Implementation sequence
Salesforce Events and callbacks
Salesforce supports Change Data Capture, Platform Events, PushTopic events, Pub/Sub API channels, and outbound messages for selected configured objects and scenarios. These mechanisms do not provide universal coverage for every Health Cloud object or field change.
Martini implementation pattern
Martini implementation pattern: Martini receives a supported event or outbound notification through an exposed API or event workflow, validates the message, and retrieves the authoritative Salesforce record before processing. Scheduled reconciliation complements event delivery for unsupported, expired, duplicated, or missed events.
Implementation sequence
Salesforce Bulk API 2.0
Bulk API 2.0 supports asynchronous high-volume query and ingest jobs for initial loads, migrations, backfills, and recurring synchronization. Job results can contain partial successes and failures.
Martini implementation pattern
Martini implementation pattern: a workflow submits a Bulk query or ingest job, polls its status, retrieves results, transforms records, and stores checkpoints. Per-record errors are separated from retryable platform failures so that invalid data is not retried indefinitely.
Implementation sequence
Common Salesforce Health Cloud integration patterns
Pattern 1: Synchronize patient and member master data
When to use this pattern
Use this pattern when Salesforce Health Cloud and an external patient, member, provider, or organization system share ownership of identity data. REST is suitable for ordinary volumes, while Bulk API 2.0 is preferable for large populations.
Integration direction
Example Mapping
| Salesforce Health Cloud Field | Canonical Field | Target Field |
|---|---|---|
| Salesforce Account.Id or Contact.Id | sourceId | externalReference |
| Person Account or Contact.Name | personName | patientName |
| Contact.External_Id__c | externalId | memberId |
| Contact.Birthdate | dateOfBirth | dateOfBirth |
Martini implementation pattern
A scheduled Martini workflow queries the configured Accounts, Person Accounts, Contacts, Individuals, and related objects, then maps only the approved fields. It uses stable external IDs and upsert logic, applies minimum-necessary data rules, records cross-references, and retries transient API failures while routing validation and permission errors to an exception path.
Martini capabilities used
- workflows
- scheduling
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Coordinate care plans and programs
When to use this pattern
Use this pattern to synchronize CarePlans, CarePlanGoals, CareProgram records, and enrolment information with a care-management, payer, clinical, or provider application.
Integration direction
Example Mapping
| Salesforce Health Cloud Field | Canonical Field | Target Field |
|---|---|---|
| CarePlan.Id | carePlanId | planReference |
| CarePlan.Status | planStatus | status |
| CarePlanGoal.Description | goalDescription | goalText |
| CareProgram.Id | programId | programReference |
Martini implementation pattern
Martini retrieves related Salesforce objects, resolves parent-child relationships, validates status transitions and effective dates, and maps the result to the receiving application. For bidirectional flows, ownership and conflict rules determine which update wins; rejected relationships and invalid transitions are persisted for review rather than silently discarded.
Martini capabilities used
- workflows
- API consumption
- data mapping
- validation
- business rules
- error handling
Pattern 3: Process event-driven care updates
When to use this pattern
Use this pattern when the Salesforce org publishes Change Data Capture, Platform Events, Pub/Sub traffic, or outbound messages for selected Health Cloud changes and downstream systems need lower-latency notification.
Integration direction
Example Mapping
| Salesforce Health Cloud Field | Canonical Field | Target Field |
|---|---|---|
| ChangeEventHeader.recordIds | sourceRecordIds | sourceReferences |
| ChangeEventHeader.changeType | changeType | eventType |
| CarePlan.Status | careStatus | status |
| Account.Id | organizationId | organizationReference |
Martini implementation pattern
Martini receives the supported event, validates and deduplicates it, retrieves the complete current Salesforce record, and applies downstream routing rules. Because event coverage and ordering are selective, the workflow records checkpoints and uses scheduled REST reconciliation for missed, unsupported, or expired events.
Martini capabilities used
- event-driven workflows
- API exposure
- API consumption
- data mapping
- deduplication
- monitoring
Pattern 4: Run bulk migration and reconciliation
When to use this pattern
Use this pattern for an initial Health Cloud migration, high-volume backfill, recurring population synchronization, or reconciliation between Salesforce and an external data platform.
Integration direction
Example Mapping
| Salesforce Health Cloud Field | Canonical Field | Target Field |
|---|---|---|
| externalPatientId | externalId | Contact.External_Id__c |
| patientName | personName | Contact.Name |
| carePlanStatus | planStatus | CarePlan.Status |
| documentReference | fileReference | ContentDocumentLink.LinkedEntityId |
Martini implementation pattern
A Martini workflow submits and monitors Salesforce Bulk API 2.0 jobs, retrieves result pages, validates records, and performs controlled ingest or comparison. It records job and record checkpoints, separates partial failures from retryable failures, uses idempotent upserts, and produces reconciliation outcomes for operations teams.
Martini capabilities used
- workflows
- API consumption
- asynchronous orchestration
- data mapping
- checkpointing
- error handling
Applications commonly integrated with Salesforce Health Cloud
Salesforce Health Cloud can participate in broader healthcare and enterprise architectures alongside EHRs, workforce, finance, service-management, and cloud platforms. The actual interface depends on each system's APIs, events, files, identity model, and data-sharing agreements.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Workday | Synchronize workforce, provider, employee, and organizational information with Salesforce care-operations processes. | Workday → Martini → Salesforce Health Cloud | Martini can retrieve approved Workday data, map worker and organization identifiers to Salesforce Accounts, Contacts, or HealthcareProvider records, validate ownership, and upsert changes through Salesforce APIs. |
| ServiceNow | Coordinate service requests, operational cases, incidents, and work associated with patients, providers, or care teams. | Salesforce Health Cloud → Martini → ServiceNow | Martini can trigger from selected Salesforce changes, transform Cases or care-related context into ServiceNow work items, synchronize status updates, and route validation or permission failures for review. |
| NetSuite | Exchange account, organization, product, invoice, payment, and commercial transaction context associated with care programs. | Salesforce Health Cloud → Martini → NetSuite | A Martini workflow can map Salesforce Accounts and commercial context to NetSuite customers or transactions, apply ownership rules, and return financial status using REST or other confirmed interfaces. |
| SAP S/4HANA | Exchange business-partner, product, billing, and financial information with healthcare operations managed in Salesforce. | SAP S/4HANA → Martini → Salesforce Health Cloud | Martini can orchestrate bidirectional API exchanges, normalize identifiers and dates, validate required Salesforce fields, and use retry and reconciliation logic for asynchronous or partial failures. |
| Microsoft Dynamics 365 | Coordinate customer, contact, service, and field-service information where business units use both Salesforce and Microsoft platforms. | Salesforce Health Cloud → Martini → Microsoft Dynamics 365 | Martini can synchronize selected Accounts, Contacts, Cases, and service information, apply system-of-record rules, and prevent duplicates with stable external identifiers. |
| Epic | Exchange patient, provider, appointment, clinical, or care-coordination information where Health Cloud complements an EHR. | Epic → Martini → Salesforce Health Cloud | Martini can receive approved Epic interface data, transform it into the configured Salesforce Health Cloud model, minimize transferred protected health information, and send only governed updates in the reverse direction. |
| Oracle Health | Synchronize patient, encounter, provider, and care-management information between an EHR and Salesforce Health Cloud. | Oracle Health → Martini → Salesforce Health Cloud | Martini can orchestrate customer-specific API, FHIR, HL7, or file interfaces where available, map encounter and provider identifiers, and maintain checkpoints for restartable synchronization. |
| Microsoft Azure | Use Azure integration, messaging, data, identity, and analytics services alongside Salesforce Health Cloud. | Salesforce Health Cloud → Martini → Microsoft Azure | Martini can consume Salesforce events or APIs, transform payloads for Azure services, expose controlled APIs for Azure-originated updates, and apply asynchronous processing and monitoring. |
How to build a Salesforce Health Cloud integration in Martini
Objective
Establish Salesforce access using an approved OAuth 2.0 flow and environment-specific configuration.
Instructions in Martini
- Select the required Salesforce API and target API version.
- Configure the connected app or external client application, scopes, instance URL, and credentials.
- Store tokens, certificates, and private keys in secure Martini configuration.
- Confirm Salesforce profiles, permission sets, object permissions, field-level security, and sharing access.
Objective
Select the trigger that matches the required latency, volume, and event coverage.
Instructions in Martini
- Use a scheduler for reconciliation and periodic synchronization.
- Use a Salesforce event, Pub/Sub channel, or outbound message for supported near-real-time changes.
- Use an exposed Martini API when an external application initiates the exchange.
- Use Bulk API 2.0 for high-volume migration or asynchronous processing.
Objective
Retrieve the authoritative Salesforce data needed for the integration while respecting query, pagination, and API limits.
Instructions in Martini
- Use REST, GraphQL, SOAP, or Bulk according to the object and volume.
- Select only required fields with selective SOQL or scoped GraphQL queries.
- Follow query locators, result pages, and asynchronous job state.
- Retrieve the full Salesforce record after an event when the notification is incomplete.
Objective
Coordinate calls, branching, enrichment, state, and target-system operations in a maintainable Martini workflow.
Instructions in Martini
- Create workflow steps for input validation, API calls, transformation, and output.
- Persist checkpoints, source identifiers, job identifiers, and continuation state.
- Separate transport failures, validation failures, permission failures, and business-rule failures.
- Use reusable services or APIs for common Salesforce access and mapping logic.
Objective
Transform Health Cloud objects into the canonical target model and enforce data-quality and privacy rules.
Instructions in Martini
- Map Accounts, Contacts, CarePlans, CarePlanGoals, CarePrograms, or other confirmed objects explicitly.
- Normalize dates, time zones, identifiers, nested relationships, and file references.
- Apply minimum-necessary data rules for protected health information.
- Validate required fields, status transitions, ownership, and external identifiers.
Objective
Write data to the target system or Salesforce and make processing restartable and idempotent.
Instructions in Martini
- Use external IDs and upsert behavior where stable identifiers exist.
- Use Composite requests for related grouped operations where appropriate.
- Use Bulk API for large writes and inspect per-record results.
- Record cross-references, checkpoints, reconciliation totals, and rejected items.
Common Salesforce Health Cloud data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Account | Represents organizations, households, payer organizations, provider organizations, and other business entities; Person Accounts may represent individuals where enabled. | Workday, NetSuite, SAP S/4HANA, Microsoft Dynamics 365, Azure | Martini maps configured Account types and external IDs, applies field-level filtering, and uses REST, Composite, or Bulk operations for synchronization. |
| Contact | Represents patients, members, caregivers, providers, and other stakeholders associated with Accounts. | Epic, Oracle Health, Microsoft Dynamics 365, Workday | Martini validates the configured person model, normalizes identifiers and dates, and upserts Contacts according to ownership and privacy rules. |
| CarePlan | Represents coordinated care plans, planned activities, goals, and care-management information. | Care-management applications, Epic, Oracle Health, Azure | Martini maps CarePlan status, dates, relationships, and ownership, validates transitions, and synchronizes related goals with controlled retries. |
| CarePlanGoal | Represents a goal associated with a CarePlan. | Care-management applications, clinical systems, Azure | Martini links goals to the correct CarePlan, transforms status and target dates, and rejects orphaned or invalid relationships for review. |
| CareProgram | Represents a structured healthcare program or service in which a patient or member participates. | Payer platforms, care-management applications, NetSuite, Azure | Martini synchronizes program identifiers, eligibility or participation attributes, and effective dates while enforcing agreed system-of-record rules. |
| MedicationStatement | Represents medication information associated with a patient or member. | Epic, Oracle Health, clinical applications, Azure | Martini applies minimum-necessary data rules, normalizes medication dates and identifiers, and routes invalid or sensitive payloads through controlled exception handling. |
Authentication and security considerations
OAuth and connected applications
Salesforce access commonly uses OAuth 2.0 through a connected app or external client application. Authorization code, JWT bearer, and client credentials flows may be appropriate depending on the Salesforce configuration; username-password OAuth is generally not recommended for new integrations.
Permissions and sensitive data
Access is governed by scopes, profiles, permission sets, object permissions, field-level security, sharing rules, record-level access, and Health Cloud feature permissions. Martini should store tokens, certificates, private keys, instance URLs, and API versions in secure configuration and transfer only the minimum necessary protected health information.
- Use environment-specific credentials and API versions.
- Protect tokens and certificates through secrets management.
- Avoid sensitive patient or member data in workflow logs.
- Apply customer requirements for HIPAA, GDPR, retention, audit, and data residency.
Operational considerations for Salesforce Health Cloud integrations
Limits and pagination
Salesforce applies API, concurrency, event delivery, and other governor limits. Use selective SOQL, Composite requests, Bulk API 2.0, pagination, query locators, and backoff for temporary or rate-limit responses.
Idempotency and event behavior
Use Salesforce IDs, external IDs, and deterministic keys to prevent duplicates. Event delivery may be duplicated, incomplete, or out of order, so retrieve the authoritative record and maintain checkpoints and reconciliation workflows.
Schema and partial failures
Health Cloud object availability varies by release, edition, license, configuration, permissions, and API version. Validate metadata and test custom fields. Inspect per-record failures in Composite and Bulk results, retry only eligible failures, and monitor API versions and Salesforce releases.
Files and healthcare dates
ContentVersion, ContentDocument, and ContentDocumentLink require separate binary and relationship handling. Normalize care-plan, appointment, medication, and clinical timestamps explicitly, including time zones and effective dates.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of point-to-point code
Martini provides a maintainable workflow layer for Salesforce Health Cloud integrations. It can consume REST, GraphQL, SOAP, Bulk, and supported event interfaces while coordinating target-system calls, transformations, validation, business rules, and exception paths.
Reusable and observable delivery
Rather than embedding Salesforce logic in isolated scripts, teams can centralize secure configuration, reusable API and workflow assets, checkpoints, retries, reconciliation, and monitoring. Martini can also expose controlled APIs so upstream applications use a governed integration façade.
- Separate Salesforce-specific models from canonical and target models.
- Support scheduled, event-driven, API-led, and asynchronous patterns.
- Handle pagination, partial failures, duplicate events, and restartable jobs.
- Adapt mappings as Health Cloud objects, permissions, and API versions change.
Frequently asked questions
Salesforce Health Cloud is integrated through the Salesforce platform APIs and configured event mechanisms. Common approaches include REST and Composite APIs for queries and record operations, GraphQL for supported related-data retrieval, SOAP for WSDL-based or legacy integrations, Bulk API 2.0 for high-volume exchange, Salesforce Files APIs for documents, and selected Change Data Capture, Platform Event, Pub/Sub, or outbound-message scenarios.
Yes. Martini can integrate with Salesforce Health Cloud by consuming Salesforce REST, GraphQL, SOAP, and Bulk APIs, receiving supported event or callback traffic, exposing APIs for Salesforce or other systems, and orchestrating mapping, validation, synchronization, and error handling workflows.
No. A dedicated Salesforce Health Cloud connector is not required. Martini can use Salesforce's confirmed native APIs, event mechanisms, callbacks, file interfaces, and OAuth authentication methods through standards-based API consumption and workflow orchestration.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Salesforce Health Cloud. The integration is 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, API usage, storage, and deployment model.
Use REST for ordinary queries and record operations, Composite APIs for grouped or related requests, Bulk API 2.0 for large asynchronous loads and queries, GraphQL where the required objects and fields are exposed, and event APIs for supported near-real-time changes. SOAP remains appropriate for established WSDL-based integrations.
Salesforce supports selected Change Data Capture, Platform Event, Pub/Sub, PushTopic, and outbound-message scenarios, but it does not provide a universal notification for every Health Cloud object or field change. Martini can receive supported deliveries and should combine them with authoritative REST lookups and scheduled reconciliation where necessary.
Martini workflows map Salesforce objects to canonical and target models, normalize relationships and dates, apply business rules, and use external IDs or cross-references for idempotent upserts. Event-driven flows can be complemented by scheduled reconciliation, while Bulk API jobs support checkpointed high-volume synchronization.
Martini can distinguish transient API, rate-limit, transport, validation, permission, and business-rule failures. Workflows can retry eligible failures with backoff, inspect per-record Bulk or Composite results, avoid retrying permanent data errors indefinitely, and keep sensitive health information out of logs and error payloads. Martini can also expose a controlled API façade for Salesforce-related operations.
Related Martini documentation
APIs
Transformation
Connect Salesforce Health Cloud with Martini
Use Martini to build governed Salesforce Health Cloud integrations across APIs, events, files, data synchronization, and enterprise workflows.