SOAP Login() retirement (Summer27) and Windows CLI

[colinkenworthy]

Bearing in mind the announced retirement of SOAP Login() in Summer'27, are there any plans to keep Data Loader working from the Windows Command Line? When I check in the Org, it logs in with a SOAP Login. Will it be possible to make a version using Oauth Client Credentials in time for the retirement?

[jwesterman-salesforce]

Yes, we will provide a solution prior to the retirement of SOAP API login().

Would be interested to know how you use the Data Loader CLI.

• Do you use it interactively or with scripts for automated execution?
• If automated, how is the execution triggered?
• Any other details of your use case you feel comfortable sharing?
  It's useful for us to know how it is being used. Thanks.

[Salesforce-SC-CRM-TA]

Could you please let us know when the version that includes a solution for this issue is expected to be released?
Thank you for your feedback.

[camisotro]

Yes, we will provide a solution prior to the retirement of SOAP API login().

Would be interested to know how you use the Data Loader CLI.

* Do you use it interactively or with scripts for automated execution?

* If automated, how is the execution triggered?

* Any other details of your use case you feel comfortable sharing?
  It's useful for us to know how it is being used.  Thanks.

Note I have created this issue #1658

[camisotro]

Yes, we will provide a solution prior to the retirement of SOAP API login().

Would be interested to know how you use the Data Loader CLI.

* Do you use it interactively or with scripts for automated execution?

* If automated, how is the execution triggered?

* Any other details of your use case you feel comfortable sharing?
  It's useful for us to know how it is being used.  Thanks.

May I just toss in the suggestion that SF make Client Credentials Flow an option for Data Loader CLI? It would just be so easy to set up.

[Manu2pace]

Hello on our part we use the dataloader mainly with the CLI to perform automated data update using powershell on a windows server.

[markmainline]

Yes, we will provide a solution prior to the retirement of SOAP API login().

Would be interested to know how you use the Data Loader CLI.

• Do you use it interactively or with scripts for automated execution?
• If automated, how is the execution triggered?
• Any other details of your use case you feel comfortable sharing?
  It's useful for us to know how it is being used. Thanks.

We've been using the Data Loader CLI for unattended scheduled integrations, primarily via Windows Task Scheduler.

Based on the discussion in this thread around the retirement of SOAP Login(), I've been working on a couple of prototype implementations to keep batch-mode execution working without requiring interactive browser logins.

Two pull requests are currently open:

#1668: PKCE + refresh token reuse/rotation support for unattended batch execution.
#1669: JWT Bearer authentication support using a Salesforce External Client App and certificate-based authentication.

Both approaches have now been tested successfully in batch mode. The refresh-token implementation was independently validated using Windows Task Scheduler and an External Client App with refresh-token rotation enabled. The JWT implementation has also been tested successfully using certificate-based authentication with no browser interaction required.

Our primary requirement is reliable unattended execution from scheduled Windows jobs following the retirement of SOAP Login().

[colinkenworthy]

We use the encrypt.bat to set up the credentials file,
We make some process-conf.xml files containing e.g an upsert.

Upsert job gets the record updates from a CSV file and uploads them to salesforce using 'upsert'.

          class="com.salesforce.dataloader.process.ProcessRunner"
          singleton="false">
        <description>Upsert job gets the record updates from a CSV file and uploads them to salesforce using 'upsert'.</description>
        <property name="name" value="fileUpsertProcess"/>
        <property name="configOverrideMap">
            <map>
                <entry key="sfdc.endpoint" value="https://login.salesforce.com"/>
                <entry key="sfdc.username" value="xxxxxxx@xxxxxxx.com"/>
                <!-- password below has been encrypted using key file, therefore it will not work without the key setting: process.encryptionKeyFile
                the password is not a valid encrypted value, please generate the real value using encrypt.bat utility -->
                <entry key="sfdc.password" value=".....4ffdc29ebccc.....a96c2c3b0947be44c0749e9c6.....8a53a3c5a70d57566a04c69d1.....909b25b6ed148376c7271"/>
                <entry key="process.encryptionKeyFile" value="c:\Users\xxxxx\.dataloader\dataLoader.key"/>
                <entry key="sfdc.timeoutSecs" value="600"/>
                <entry key="sfdc.loadBatchSize" value="200"/>
                <entry key="sfdc.externalIdField" value="ExtId__c"/>
                <entry key="sfdc.entity" value="CustObj__c"/>
                <entry key="process.operation" value="upsert"/>
                <entry key="process.mappingFile" value="c:\Users\xxxxx\dataloader\v47.0.0\configs\xxxxx\fieldMapping.sdl"/>
                <entry key="dataAccess.name" value="c:\Users\xxxxx\dataloader\v47.0.0\configs\xxxxx\MyList.csv"/>
                <entry key="dataAccess.type" value="csvRead"/>
                <entry key="process.initialLastRunDate" value="2006-12-01T00:00:00.000-0800"/>
            </map>
        </property>
    </bean>```
Then in windows we schedule a daily task to run process.bat picking up the correct xml file.
Basically straight out of the documentation and /samples/conf/ folders.

[ColinBuckley765486]

Hi

I use the same process as described in the first post by Colin Kenworthy.
Windows PC monitoring files being dropped into a folder, which then triggers 1 of 4 different file uploads routines.
8 file uploads / day, approx 40000 rows of data / day.

Its all automated.

Cheers

[camisotro]

Hi

I use the same process as described in the first post by Colin Kenworthy. Windows PC monitoring files being dropped into a folder, which then triggers 1 of 4 different file uploads routines. 8 file uploads / day, approx 40000 rows of data / day.

Its all automated.

Cheers

Yes I have a customer who has a similar unattended server setup with Dataloader CLI.

[stuartbate-svg]

I'm watching this one with interest now as ColinBuckley765486 above retired a few months ago and we still need to find a solution before the SOAP Login() retirement next year.

[henrikhelthansen]

Hi @jwesterman-salesforce

User case 1:

• I use the CLI fully automated to query Contacts Records in Salesforce (every 3 hours) for an external phone integration system
• I have configered the process-conf to handle my different query scenarios
• I have configured a Windows Batch File, which is used to execute the process-conf file
• We have set up Windows Sceduler to run the batch file according to the defined intervals
• It has all been configured on a dedicated windows server for this purpose only
• It is running 100% in the background without any humans involved

User case 2:

• Same as user case 1 but with additional
• Upserts from Navision (ERP system) to Salesforce

/Henrik

[markmainline]

Hello,

While testing Data Loader v67 with Salesforce External Client Apps and PKCE authentication, I noticed that Data Loader successfully obtains and stores refresh tokens but does not reuse them for subsequent logins.

I implemented a proof-of-concept that:

Reuses a stored OAuth refresh token on startup.
Uses the refresh token grant to obtain a new access token.
Persists rotated refresh tokens returned by Salesforce.
Falls back to the browser-based PKCE flow only when refresh token authentication fails.

Testing performed:

UI mode authentication.
Multiple application restarts.
Refresh token rotation enabled.
Separate Windows machines.
Batch/CLI mode execution.
Unattended execution after several days.

Results:

Browser authentication is only required for the initial login.
Subsequent executions authenticate via refresh token without user interaction.
Rotated refresh tokens are persisted and successfully reused.
CLI jobs execute successfully without prompting for login.

I'm happy to share the implementation or submit a pull request if this aligns with the project's roadmap.

If this is something of interest to people that moves away from SOAP and consistently uses OAUTH, please let me know. As far as I can tell this ticks all of the right boxes, but validation from experts would be appreciated if it of interest.

Thanks
Mark

[markmainline]

Thanks for testing and for the feedback.

I've updated the PR to remove logging of access tokens and refresh tokens from OAuthServerFlow.java`.

The implementation still logs non-sensitive information such as token lengths and successful refresh-token persistence, but no longer writes usable access or refresh token values to the log output.

Regarding the username dependency, my testing always included sfdc.username. Based on your findings, it appears the refresh-token path currently still requires that value to be present. I haven't changed that behaviour in this PR, but I agree it should be documented.

[personalworkusage2-eng]

Thanks for this PR. We tested it in a sandbox (Data Loader v67 built from this PR, External Client App, PKCE, refresh token rotation on). The refresh token path worked in batch mode, including a run started by Windows Task Scheduler with no browser.

Batch mode command used: process.bat ""

I have one issue and one question.

1. Tokens are written to the log in plain text.
   In OAuthServerFlow.java, the added code logs token values at INFO level
   (line numbers as of the current diff):

   • "TOKEN RESPONSE" (line 361), which includes the access token and the
     refresh token
   • "REFRESH TOKEN=" (line 464)
   • "TOKEN BEING WRITTEN=" (line 506)
   • "REFRESH TOKEN AFTER SAVE=" (line 514)
     In our test, the value stored in config.properties appears to be
     encrypted (a different, longer value than the real token), but the log
     prints the usable token, identical to what Salesforce returned. This
     undoes the protection of the encrypted storage. Could these log lines
     be removed, or masked (for example, log only the length)?

2. Is sfdc.username required for the refresh token path?
   In UI mode, with no sfdc.username in config.properties, the refresh
   attempt failed with "Empty salesforce.com username specified" and fell
   back to the browser. If the username is required, it may be worth
   documenting.

Thanks for testing and for the feedback.

I've updated the PR to remove logging of access tokens and refresh tokens from OAuthServerFlow.java`.

The implementation still logs non-sensitive information such as token lengths and successful refresh-token persistence, but no longer writes usable access or refresh token values to the log output.

Regarding the username dependency, my testing always included sfdc.username. Based on your findings, it appears the refresh-token path currently still requires that value to be present. I haven't changed that behaviour in this PR, but I agree it should be documented.

Thanks for the quick update. Removing the token logging and documenting the
sfdc.username requirement sounds good. I'll re-test with the updated
version and share the result if anything comes up.

[personalworkusage2-eng]

Hello,

While testing Data Loader v67 with Salesforce External Client Apps and PKCE authentication, I noticed that Data Loader successfully obtains and stores refresh tokens but does not reuse them for subsequent logins.

I implemented a proof-of-concept that:

Reuses a stored OAuth refresh token on startup. Uses the refresh token grant to obtain a new access token. Persists rotated refresh tokens returned by Salesforce. Falls back to the browser-based PKCE flow only when refresh token authentication fails.

Testing performed:

UI mode authentication. Multiple application restarts. Refresh token rotation enabled. Separate Windows machines. Batch/CLI mode execution. Unattended execution after several days.

Results:

Browser authentication is only required for the initial login. Subsequent executions authenticate via refresh token without user interaction. Rotated refresh tokens are persisted and successfully reused. CLI jobs execute successfully without prompting for login.

I'm happy to share the implementation or submit a pull request if this aligns with the project's roadmap.

If this is something of interest to people that moves away from SOAP and consistently uses OAUTH, please let me know. As far as I can tell this ticks all of the right boxes, but validation from experts would be appreciated if it of interest.

Thanks Mark

Hi @markmainline, thank you for this PR.

I have a few quick questions:-

1)Which tool and command did you use to build the modified jar (for example Maven, or something else)? I used Maven.
2)Did you put the Consumer Secret in config.properties (or in the Data Loader settings screen) for your setup? In my test I only set the Client ID (eca.clientid) and it worked with PKCE, without the secret. Is the secret required, or optional?

Thanks for your help.

[stuartbate-svg]

Hi,

I work with Mark. I can't answer the question of what tools he used (I'm not a Java coder and Mark is away on course today), but for the JWT Bearer Flow authentication you only require the Client ID along with the username of the Salesforce integration user and private key file for the certificate uploaded to the External Client App. The secret isn't required at all.

The idea for us to implement the JWT Bearer into the Dataloader came about as we had to convert our Salesforce API access from our web portal from a username-password flow in order to strengthen security as Salesforce will be retiring the less secure OAuth flows. It then followed that implementing the same flow into Dataloader would be the next logical step.

[markmainline]

Just to follow on from this; yes Maven was used and the build command I used was: mvn install "-Dmaven.test.skip=true"

[personalworkusage2-eng]

Thanks for the quick update and for removing the token logging. I'll
re-test with the updated version.

We tested this PR in batch mode with Windows Task Scheduler in a sandbox,
using process.bat "<config folder>" <job name>, and the refresh token
path worked without a browser.

Your description mentions multi-day unattended runs on a server. A few
questions about that setup:

1. Which scheduler did you use to start the jobs (for example Windows Task
   Scheduler, cron, or another tool)?
2. Was the machine always on? Is that the recommended setup for this flow?
3. If a run is skipped or the refresh token is rejected, is there a
   recommended way to detect it, for example a non-zero exit code that a
   scheduler can alert on?

[markmainline]

Thanks for testing and for the questions.

My testing was primarily performed using Windows Task Scheduler running Data Loader in CLI mode. The same process definition and configuration were also exercised manually from the command line. The goal was specifically to support unattended scheduled execution without requiring browser interaction after the initial OAuth consent flow.

1. Scheduler used

I used Windows Task Scheduler for unattended testing. The process was started using:

process.bat "<config folder>" <job name>

with no interactive user input required once the refresh token had been obtained and stored.

2. Machine availability

The machine was left powered on during testing. As with any scheduled batch integration, the scheduler can only run jobs when the host system is available. There are no additional requirements introduced by this implementation beyond the normal requirements for running scheduled Data Loader jobs.

3. Detecting failures

During testing, failures were primarily detected through:

Data Loader log output
Windows Task Scheduler execution history
Non-success process execution

I did not add any custom monitoring or alerting logic as part of this PR.

In the event that a refresh token becomes invalid or is rejected by Salesforce, Data Loader follows the existing authentication error path and the batch job does not successfully complete. For production environments I would recommend configuring the scheduler or monitoring solution to watch for failed executions and review the generated log output.

I did not specifically test automated alerting or build additional failure-notification functionality as part of this change, so I'd defer to the maintainers on whether enhanced monitoring or exit-code handling should be considered separately from this PR.

Regarding long-running unattended usage, the main scenario I was validating was allowing scheduled Data Loader executions to continue operating without repeated browser-based re-authentication, even when Salesforce refresh-token rotation is enabled.