Salesforce for CRM automation
Salesforce's official DX server is our second pick for CRM automation, and it is a developer-grade entry rather than a point-and-click one. It queries org data with SOQL, deploys and retrieves metadata, manages orgs, and runs tests, which makes it the choice for deep, governed access to the most widely deployed CRM rather than a simple log-a-call helper.
It ranks second because the task as most teams frame it, search a contact, update a deal stage, enrich a record from natural language, is exactly where HubSpot's friendlier object model fits ahead of it. Salesforce wins on reach and rigor: anything expressible in SOQL or DX metadata is reachable, but the path runs through queries and deployments, not a CRM-object convenience layer.
How Salesforce fits
The workhorse is run_soql_query, which reads accounts, contacts, opportunities, and any object in the org with a real query, so an agent can pull a pipeline summary or find records by predicate. get_username resolves which org or alias an action targets, list_all_orgs and open_org manage where you are pointed, and assign_permission_set handles access. For changes to the org's structure, deploy_metadata and retrieve_metadata move configuration between a DX project and the org, and run_agent_test exercises Agentforce-style tests.
The honest limit shapes the rank. This is a DX toolkit, so it reads richly through SOQL but does not expose a simple create-or-update-record command for everyday CRM edits; writes go through metadata deployment or are left to the platform. HubSpot fits better for friendly read-and-write across CRM objects, Attio for a flexible modern data model, and Pipedrive for straightforward deal-pipeline moves. Reach for Salesforce when you need governed, query-level depth into a Salesforce org and DX operations alongside it.
Tools you would use
| Tool | What it does |
|---|---|
| get_username | Determines the appropriate username or alias for Salesforce operations, handling default orgs and Dev Hubs. |
| resume_tool_operation | Resumes a long-running operation that wasn't completed by another tool. |
| run_soql_query | Runs a SOQL query against a Salesforce org. |
| deploy_metadata | Deploys metadata from your DX project to an org. |
| retrieve_metadata | Retrieves metadata from your org to your DX project. |
| create_org_snapshot | Creates a scratch org snapshot. |
| create_scratch_org | Creates a scratch org. |
| delete_org | Deletes a locally-authorized Salesforce scratch org or sandbox. |
| list_all_orgs | Lists all configured Salesforce orgs, with optional connection status checking. |
| open_org | Opens an org in a browser. |
FAQ
- Can this Salesforce server update a deal stage or create a contact directly?
- Not through a simple record command. It is the DX server: run_soql_query reads org data richly, and changes go through deploy_metadata and retrieve_metadata rather than a create-or-update-record tool. For everyday CRM edits, HubSpot's object model fits better, which is why Salesforce ranks second here.
- What does the Salesforce DX server do best for CRM automation?
- Deep, governed reads and org operations. run_soql_query pulls any object by query, deploy_metadata and retrieve_metadata move configuration, and run_agent_test exercises tests. It is the pick when you need query-level depth into a Salesforce org rather than a friendly write layer.