Salesforce Office Toolkit
The Salesforce Office Toolkit (formally the Force.com Office Toolkit) was a developer library that gave a Component Object Model (COM) interface to the Salesforce SOAP API. Developers used it to wr…
Definition
The Salesforce Office Toolkit (formally the Force.com Office Toolkit) was a developer library that gave a Component Object Model (COM) interface to the Salesforce SOAP API. Developers used it to write client applications in COM-aware languages so those applications could read and write an organization's Salesforce data without hand-coding raw SOAP envelopes. It is retired, and Salesforce now points integrators to current API versions and supported tools.
The toolkit acted as an intermediary between a COM client and the API. It handled login, session management, and data type conversion implicitly, which kept the calling code simpler than working against the WSDL directly. It supported environments such as Visual Basic 6.0, VBA, C++, .NET, VBScript, and JavaScript inside Internet Explorer. Because it leaned on aging COM technology and very old API versions, it has no place in a modern integration.
How the Office Toolkit Wrapped the SOAP API
What the Office Toolkit actually was
People often confuse two different things that both touched Microsoft Office. The Office Toolkit was a developer library, not an end-user add-in. It shipped as a COM component (the SForceOfficeToolkit interface) that wrapped the Salesforce SOAP API. A developer referenced that component from code and then called methods like login, query, create, update, and delete against Salesforce objects. The separate Connect for Office product was the click-and-merge experience inside Excel and Word that business users installed. The Office Toolkit sat one layer below that, aimed at programmers building custom integrations. Both are gone now, which is part of why the names blur together in old forum threads. The toolkit existed because raw SOAP work is tedious. You would otherwise generate code from an Enterprise or Partner WSDL, manage the HTTP transport, and parse XML responses by hand. The COM wrapper hid most of that. For a Visual Basic 6.0 or VBA developer in the mid-2000s, that convenience was the whole appeal.
The COM model and supported languages
COM is a Microsoft binary standard for letting software components call each other on Windows. Because the toolkit exposed a COM interface, any COM-aware language could load it and invoke its methods. That covered Visual Basic 6.0, VBA inside Excel or Access, C++, the early .NET languages, VBScript, and JavaScript running in Internet Explorer. That reach was the toolkit's strength in its era. A finance team could automate Salesforce updates from an Excel macro. An internal tool written in classic VB could push records on a schedule. None of it required deep web service knowledge, only familiarity with COM objects and the toolkit's method names. The same design is also why it aged badly. COM is tied to Windows desktop runtimes and registry-based component registration. It does not fit cloud functions, containers, or cross-platform services. As integration moved to plain HTTP and JSON, a Windows-only COM dependency turned from a shortcut into a liability that teams had to plan around and eventually remove.
What it handled for you under the hood
The value of the toolkit was in the work it did silently. When a client called the login method with a username and password, the toolkit performed the SOAP login, captured the returned session ID, and stored the server endpoint URL. Later calls reused that session automatically, so the developer rarely touched authentication details after the first call. It also smoothed data handling. SOAP responses arrive as typed XML, and converting those into native variables is fussy. The toolkit mapped Salesforce field values into COM-friendly types and back again, so a VBA developer could treat a query result more like an ordinary recordset. Batch operations such as creating or updating several records in one call were exposed through straightforward method signatures. This implicit behavior is exactly what a higher-level library should do. It is also what makes such a library fragile over time. The hidden assumptions about session handling, endpoints, and API versions were baked into a binary you did not control, and those assumptions stopped matching Salesforce as the platform evolved.
Why it was retired
Two forces ended the Office Toolkit. The first was its dependence on very old API versions. Salesforce deprecated SOAP, REST, and Bulk API versions 21.0 through 30.0 in the Summer 22 release and retired them in Summer 25. Tools built on outdated libraries, and Salesforce named the SForceOfficeToolkit COM interface directly, were flagged as sources of these legacy calls. Once those versions were retired, SOAP requests on them began failing with an UNSUPPORTED_API_VERSION error. The second force was the platform shift away from desktop COM. Connect for Office, the related Office add-in, lost support in the same period. Its Excel add-in was retired in early 2017, partly because it ran on environments that could not support modern TLS. The whole family of Windows-desktop Office integrations fell out of favor. So the toolkit was not killed by a single announcement. It was squeezed out as its API foundation was retired and its desktop COM model became a dead end for serious integration work.
What replaced it for developers
There is no like-for-like COM replacement, and that is intentional. Modern Salesforce integration runs over HTTP. For most read and write work, the REST API is the default choice because it speaks JSON and works from any language or runtime. The SOAP API still exists for strongly typed, contract-first integrations that generate code from the Enterprise or Partner WSDL. For moving large volumes of records, Bulk API 2.0 replaced the spreadsheet-driven habits that the old Office tools encouraged. It handles batching and limits for you and suits jobs that once tempted people into Excel macros. Authentication moved on too. Username and password login in code gave way to OAuth through a Connected App, which is safer and easier to govern. A developer who once wrote a VBA macro against the Office Toolkit would today call the REST API from a small script or a serverless function, authenticate with OAuth, and use Bulk API 2.0 for heavy data loads. The result is portable, supported, and not tied to a Windows desktop.
Spotting and removing legacy Office Toolkit usage
If you inherit an older Salesforce org, the toolkit can still haunt it through forgotten desktop tools. Look for Windows applications or Excel and Access workbooks that reference an SForceOfficeToolkit COM object. A registered COM component on a user machine, or a macro that creates that object, is the tell. These integrations often still carry a username and password in code or in a config file, which is a second reason to retire them. The API Total Usage and event monitoring data in Salesforce help you confirm whether old API versions are still being called. A spike of SOAP traffic on versions 30.0 or lower is a strong hint that a legacy client is involved. After the Summer 25 retirement, those calls fail outright, so a tool that suddenly broke is worth checking against this list. The fix is to rewrite the integration on a supported API with OAuth, or to replace it with a maintained tool such as Data Loader. Remove the COM dependency and the stored credentials in the same pass.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Salesforce Office Toolkit.
Hands-on resources to go deeper on Salesforce Office Toolkit.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Is the Salesforce Office Toolkit still a current Salesforce integration product today?
Q2. Which modern tools cover what the legacy Office Toolkit's Excel Connector once did?
Q3. What replaces the legacy Office Toolkit's mail-merge feature for generating documents from Salesforce?
Discussion
Loading discussion…