Salesforce Integration Basic Details

I’ll explain with 3 scenarios:

1. Salesforce → External System (one-way)

2. External System → Salesforce (one-way)

3. Two-way (bi-directional)

And in between, I’ll clarify Named Credentials, Connected Apps, OAuth, Client Id/Secret, API key, etc.

---

🔹 Step 1: Core Building Blocks in Salesforce Integrations

1. Named Credential

• What it is:
  A secure way in Salesforce to store external endpoint URL + authentication method (OAuth, Basic, API key).
  So your Apex code doesn’t hardcode credentials.

• Why we use it:
  ✅ Centralized credential management
  ✅ No need to store username/password in code
  ✅ Auto handles token refresh (if OAuth)

• When to use:
  Whenever Salesforce needs to call an external system.

---

2. Connected App

• What it is:
  A configuration in Salesforce that allows an external system to connect into Salesforce using OAuth.

• Why we use it:
  ✅ If an external system needs to call Salesforce APIs (REST, SOAP, Bulk)
  ✅ Provides Client Id + Client Secret

• When to use:
  When external system → Salesforce (not needed for Salesforce → external).

---

3. OAuth, Client Id, Client Secret

• OAuth: Protocol for secure access (token-based).

• Client Id & Secret: Credentials given by Salesforce (via Connected App) or by external system (if Salesforce is calling them).

• Why we use:
  Needed for secure integrations where username/password or API key is not enough.

---

4. API Key / Basic Auth

• API Key: External system gives you a key → you include it in header.

• Basic Auth: Username + Password encoded in header.

• ✅ Easier but less secure. Use only for simple integrations.

---

---

🔹 Step 2: Scenarios

---

✅ Scenario 1: Salesforce → External System (one-way)

📌 Example: Push Account data from Salesforce to Oracle API.

What we use here:

• Named Credential → stores Oracle API endpoint + auth (OAuth or API key).

• Apex Callout (HttpRequest) → sends JSON data.

What we do NOT use:

• ❌ Connected App (not needed, because external system is not calling Salesforce).

Steps:

1. Analyse requirement → What data → Frequency (real-time / batch) → Secure auth method.

2. Create Named Credential with Oracle API details.

3. Write Apex class with HTTP callout.

4. Trigger it on DML (insert/update) or use Batch/Queueable for bulk.

5. Test with Mock callouts.

Code Example (Best Practice with Named Credential):

public with sharing class OracleIntegrationService {
    // Push Account data to Oracle API
    @future(callout=true)
    public static void sendAccountToOracle(Id accountId) {
        Account acc = [SELECT Id, Name, Phone FROM Account WHERE Id = :accountId];

        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:Oracle_Integration_API/accounts'); // Named Credential
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');

        // Create JSON body
        Map<String, Object> body = new Map<String, Object>{
            'accountId' => acc.Id,
            'accountName' => acc.Name,
            'phone' => acc.Phone
        };
        req.setBody(JSON.serialize(body));

        Http http = new Http();
        HttpResponse res = http.send(req);

        if(res.getStatusCode() != 200){
            System.debug('Error from Oracle API: ' + res.getBody());
        }
    }
}

👉 This code uses Named Credential → no credentials in Apex.

---

✅ Scenario 2: External System → Salesforce (one-way)

📌 Example: Oracle system pushes customer transactions into Salesforce.

What we use here:

• Connected App → in Salesforce (so Oracle can log in securely).

• OAuth + Client Id/Secret → external system uses this to get token.

• Salesforce REST API → external system calls /services/data/vXX.X/sobjects/Account.

What we do NOT use:

• ❌ Named Credential (not needed, because Salesforce is not making the callout).

Steps:

1. Create Connected App in Salesforce (OAuth enabled, API enabled).

2. Give Client Id + Client Secret to external system.

3. External system requests token (/services/oauth2/token).

4. External system calls Salesforce REST APIs with Bearer token.

5. Test with Postman first, then connect Oracle.

Sample External API Call to Salesforce (Postman or Oracle):

POST https://login.salesforce.com/services/oauth2/token
grant_type=password
client_id=XXXXXXXX
client_secret=YYYYYYYY
username=yourSFuser
password=yourSFpassword+securitytoken

Then use token:

POST https://yourInstance.salesforce.com/services/data/v59.0/sobjects/Account
Authorization: Bearer <access_token>
Content-Type: application/json

{
   "Name": "Oracle Customer",
   "Phone": "1234567890"
}

---

✅ Scenario 3: Two-way Integration (bi-directional)

📌 Example: Salesforce sends Accounts → Oracle; Oracle sends Transactions → Salesforce.

What we use here:

• Salesforce → Oracle: Named Credential + Apex Callout

• Oracle → Salesforce: Connected App + OAuth (Client Id/Secret)

So we use both:

• Named Credential (outbound)

• Connected App (inbound)

Steps:

1. Analyse flows (who sends what, when).

2. Create Named Credential (Salesforce outbound).

3. Create Connected App (Salesforce inbound).

4. Develop Apex callouts for outbound.

5. Oracle uses REST API for inbound.

6. Define error handling + retry strategy.

7. Add logging + Platform Events if async.

8. Write test classes with Mock responses.

---

🔹 Step 3: Summary Table

Direction	What to Use	Why
Salesforce → External	Named Credential + Apex Callout	Secure, no hardcoded creds
External → Salesforce	Connected App + OAuth (Client Id/Secret)	External system logs in securely
Two-way	Both	Outbound (Named Credential), Inbound (Connected App)

---

🔥 Golden Rules:

• Always prefer Named Credentials for outbound (never store secrets in Apex).

• Always use Connected Apps + OAuth for inbound (never expose username/password).

• Use API keys only if system doesn’t support OAuth.

• Always log integration success/failure.