9 / 81 · Module 4 — Salesforce Connector · filtered: interview← prev ⊞ all next →

4.34Your Salesforce Connector cheat sheet

QUERY
-----
Read Salesforce records
Uses SOQL


QUERY ALL
---------
Read including deleted records
Useful for synchronization/reconciliation


CREATE
------
New record
Risk of duplicates on retries


UPDATE
------
Modify known Salesforce record
Usually uses Salesforce Id


UPSERT
------
External ID
insert OR update
Preferred for many synchronization flows
Excellent for idempotency


DELETE
------
Delete known records
Confirm business lifecycle semantics first


BULK API
--------
Large volumes
Asynchronous/job-oriented
Handle row-level failures


TARGET VARIABLE
---------------
Keep connector result in vars.x
without replacing current payload

And this relationship:

External system
       │
       │ customerId=C001
       ↓
     Mule
       │
       │ DataWeave
       ↓
Salesforce Connector
       │
       │ Upsert Account
       ↓
Salesforce
       │
       ├── Id = 001ABC
       │
       └── External_ID__c = C001

The developer mindset I want you to keep

When somebody gives you a Mule/Salesforce requirement, don't immediately think:

“Which connector box do I drag onto the canvas?”

Run through these questions:

What identifies this entity?

Create / Update / Upsert?

Do I need Salesforce state before writing?

What should happen on retry?

Can this operation produce duplicates?

One record or collection?

Transactional volume or Bulk API volume?

Are there parent/child relationships?

What counts as partial failure?

What should replace payload?
Or should I use a target variable?

Which failures are retryable?

What information is safe to log?

If you naturally start asking those questions, you already sound much more like an integration developer than someone who simply knows MuleSoft syntax.