Scott O.

Hi Satish - There are several ways to control which node or Snaplex a pipeline runs on: 1. Pipeline Configuration in Designer When you have a pipeline open in the Designer, you can select the target Snaplex directly from the Snaplex drop-down menu in the pipeline configuration. This determines where the pipeline will run. 2. Scheduled or Triggered Task Configuration When setting up a Scheduled or Triggered Task, you can specify the Snaplex on which the associated pipeline should run during task configuration. 3. Using the Pipeline Execute Snap (for Child Pipelines) When invoking a child pipeline via the Pipeline Execute Snap, you can control node execution using the "Execute On" field, which offers three options: LOCAL_NODE Runs the child pipeline on the same node as the parent pipeline. Best for performance — no network transfer. LOCAL_SNAPLEX Runs the child pipeline on any available node within the same Snaplex as the parent. SNAPLEX_WITH_PATH Runs the child pipeline on a user-specified Snaplex. A Snaplex Path field appears for you to enter the target Snaplex name. Tip: Using LOCAL_NODE is recommended for most child pipeline executions as it avoids network overhead and improves performance. 4. Using pipe.plexPath Expression You can use the pipe.plexPath expression in the Pipeline Execute Snap to dynamically ensure the child pipeline runs on the same node as the parent pipeline. Note: pipe.plexPath is not recommended for Ultra Pipelines, as sending execution to another node can be resource-intensive. 5. Dedicated Snaplex for a Project An Org/Environment admin can assign a dedicated Snaplex to a specific project by moving it from the Shared project to another project. Only pipelines within that project will have access to that Snaplex in Manager and Designer. Best Practices Summary

Hi Manjula - I checked with SnapGPT desktop version and this was the response to your question: When you use the standard Salesforce Account (configured with Username, Password, Security Token, and Login URL), SnapLogic authenticates using the Salesforce SOAP API login endpoint — specifically via the login() call in the SOAP API. Here's the flow: SnapLogic → POST to login.salesforce.com/services/Soap/u<version> → SOAP login() call with Username + Password + Security Token → Salesforce returns a Session ID (token) + Instance URL → SnapLogic uses this Session ID for all subsequent REST/BULK API calls ⚠️ Key Insight: Even if your Snaps are configured to use REST API or Bulk API for data operations, the initial authentication/session establishment is done via the SOAP API login endpoint. The Session ID obtained is then reused for REST and Bulk API calls. 📊 Authentication Flow by API Type Snap Operation Auth Method Used Data Operation API Salesforce Read/Create/Update/Delete (REST mode) SOAP login() → Session ID REST API Salesforce Bulk Create/Update/Delete/Query SOAP login() → Session ID Bulk API 1.0 or 2.0 Salesforce SOQL SOAP login() → Session ID REST API Salesforce Bulk Update (new) SOAP login() → Session ID Bulk API 2.0 ⚠️ Impact of "Salesforce SOAP API Versions 31.0–64.0 Retirement" This is critically important for your pipelines. Here's what it means: What's Being Retired? Salesforce is retiring SOAP API versions 31.0 through 64.0. The login() SOAP call used by SnapLogic's standard Salesforce Account relies on a specific SOAP API version endpoint. Direct Impact on Your Pipelines Scenario Impact Using Salesforce Account (username/password) with an older Service Version (e.g., 31.0–44.0) ❌ Authentication will FAIL — the SOAP login endpoint for that version will be retired Using Salesforce Account with Service Version 65.0+ ✅ Should continue to work Using Salesforce OAuth2 Account ✅ Not impacted — uses OAuth2 token endpoint, not SOAP login Using Salesforce JWT OAuth2 Account ✅ Not impacted — uses JWT bearer token flow Using Salesforce Mutual Authentication Account ⚠️ Partially impacted — still uses username/password + certificate, check SOAP version used ✅ Recommended Actions 1. Check Your Service Version in All Salesforce Snaps Navigate to each Salesforce Snap and verify the Service Version field. Ensure it is set to 65.0 or higher (post-retirement versions). The default Service Version was updated to 52.0 in the November 2021 release. If your pipelines are older, they may still be on versions 31.0–44.0. 2. Migrate to OAuth2-Based Authentication (Recommended) To completely eliminate dependency on SOAP login, migrate from the Salesforce Account to one of these:

3. Update Login URL if Needed Ensure your Login URL in the Salesforce Account is using the current format:

🔑 Summary Standard Salesforce Account (Username/Password) └── Uses SOAP API login() to get Session ID └── Session ID used for REST/Bulk API data operations └── ⚠️ SOAP API version retirement DIRECTLY impacts authentication └── Fix: Upgrade Service Version to 65.0+ OR migrate to OAuth2 Bottom line: Even though your data operations use REST/Bulk API, the authentication layer still depends on SOAP API when using the standard Salesforce Account. Migrating to Salesforce OAuth2 or JWT OAuth2 accounts is the safest long-term approach to avoid any disruption from the SOAP API version retirement.

This is an impactful innovation Konstantin!