Latest News
Featured Project
Connect With Us
SalesForce API - outstanding issues and areas for improvement
I've been working with SalesForce API for about three years now. During that time, I've come to appreciate the breadth and depth of SalesForce's cloud offerings, but I've also run into snags along the way. I'm not the only one who has dealt with these issues, but I've never taken the time to document them. The following issues range from general gripes to specific technical issues.
API Quotas
-
First and foremost, SalesForce's API Quota poses a serious obstacle to high-volume applications backed by SalesForce API. SalesForce allots a certain number of API calls to clients over a rolling 24 hour period. If the client exceeds this number, their API connection is blocked. Folks have implemented workarounds, and the ones I've seen involve complex caching and queuing systems, data replication, and don't support serving live data from the API. I would like to see increased API Quotas across the board, and perhaps a model like Amazon S3, where users can pay for any overages on their quota API service, instead of losing access altogether. Or maybe the numeric API Quota could be replaced with a bandwidth / storage / CPU cycle quota. Presumably this would more accurately serve to throttle abuse of the API. At the very least, the API should expose a method for clients to check their API quota without counting against it.
-
Outbound SOAP Messages triggered via SalesForce workflow count against the aforementioned API Quota. Is this true?
Enterprise API PHP Client
-
FIXED 12/23/2010.
Besides pervasive documentation issues in the PHP Toolkit, there is a bug in SforceEnterpriseClient::upsert that prevents any SalesForce objects but Contacts from being upserted. I've rolled a simple patch that addresses this bug.
-
There is an issue with the Enterprise version of the API that prevents setting multiple fields to NULL in a single transaction (upsert or update). The fieldsToNull property is a string that, using the Partner API, can be a comma-delimited list of fields to nullify. However, the same input passed via the Enterprise API returns a SOAP Fault exception. The only reported issues I found refer to the PHP Toolkit as well:
PHP Enterprise Update fieldsToNull error
Re: PHP: fieldsToNull with an array of field names...
Re: How do you update a field to null?
The only proposed solution to the Enterprise issues is to switch to the Partner API, which is looking like a better and better option.
Feature Requests
-
Given the API Quota as it is, it would be awesome if the SOAP client could create records of different types via upsert and implement a system to upsert a pair or group of master-detail records simultaneously. For example, a transaction for a typical shopping cart application might create an Account, a Contact, an Opportunity, an Opportunity Contact Role, and an Opportunity Product. In addition to the 5 API upserts to create those objects, I need master-detail IDs for the Contact, the Opportunity Contact Role, and the Opportunity Product records - a total of 8 API calls for a single user interaction.
-
SalesForce offers a tool to identify and merge duplicate Contact records within an Account, which is great. I would like to see this tool expanded not only to be able to merge Contact records across Accounts, but also to be able to merge records of any type. This functionality is among the offerings of the payware Demand Tools, but I'd like to see it rolled into the base platform.
-
Merging Contact records should fire workflow rules for all records involved in the merge - "keeper" AND "merged" records. Merging Contact records through SalesForce's default merge tool only fires Workflow rules for the "keeper" record. For example, if 3 records are being merged, 1 record (the "keeper") will be kept and arbitrary information from the other 2 records (the "merged" records) will be merged with that record. If applicable, "update" Workflow rules for the "keeper" will be fired, but no "update" rules for the "merged" records will be fired, even though the "isDeleted" field will be updated to True for both "merged" records. Conversely, when a record is simply deleted, "update" Workflow rules are fired for the record. This means that instead of SalesForce notifying its clients about such changes, every client will have to continually poll the API for deleted records. Couple this with the API quotas, and you're looking at a huge headache in trying to keep two databases in sync.
- Last on the wishlist: multiple data formats. An API that served different data formats especially JSON, would remove barriers to entry for those who don't wish to consume XML and potentially reduce bandwidth usage.