Please Login with your Salesforce ID to post, promote or comment.
Salesforce IdeaExchange
FAQs | Terms of Use8070 Ideas; Promoted 170377 Times; 16407 Comments.
- Suggest a New Product Concept
- Promote Ideas That You Want to See Developed
- Discuss With Product Managers and Other Users
- See What We Are Planning To Deliver
Web Services API Ideas
Subscribe
API Access to FY Setting in Organization object without View All Data
It is impossible for appExchange partners or orgs to create custom apps that maintain user security and allow users to select data based on fiscal year setting. Currently the only way for a user to have access to Fiscal Year settings through SOQL and the Web Services API is either:
* Grant them View All Data Access, or
* Enable Customizable Forecasting
I want to allow users to leverage the Fiscal Year settings stored in Salesforce within other non-native apps without enabling additional features or side-stepping security.
Function to determine object type for whoId and whatId
Tasks and Events have two fields (whoId and whatId) that can reference multiple object types ... whoId => Lead|Account, whatId => Account|Asset|Campaign|Case...
I'd like to see a function that would return the name of the object type being referenced that we could use in S-controls, formula fields, reports, etc.
e.g. {!$ObjectTypeName(WhoId)}
This would allow someone working on a Task record to do queries on the related object like so:
var queryResult = sforce.connection.query("Select Name from {!$ObjectTypeName(WhoId)} where Id='{!WhoId}'");
... or construct different query strings depending on the object type returned.
Multi Currency Management: Ability to update currencies via Import/API
When using Advanced Currency Management, the administrator must update all the currencies manually. This is a manual and tedious exercise for an organisation with 30 currencies that are updated regularly.
It would be more efficient if we had the ability to import currencies as a csv and/or we could use the API to call a web service such as bloomberg.
Other option might be for Salesforce to maintain daily mid-market rates that organisations could utilise for their own org. (After all, every company doesn't need to import the same currency each day, week or month.)
Salesforce.com to Outlook Contact sync
I would like to be able to choose what Contacts are synced from Salesforce.com down to Outlook. Right now it is all Contacts that I own and All Contacts on the Accounts I own. I have some Contacts that I own but do not need to be brought down to Outlook and there are other Contacts that are owned by people below me that I would like to have in my Outlook.
The only way I can see to do this now is to create Duplicate Contacts within salesforce.com for the Contacts that I do not own and for the ones I do own is to just put up with having them in my Outlook.
Run APEX/Triggers/etc Code as Another Profile (doAs)
The ability to delegate execution of APEX code under another profile.
Scenario:
Currently a profile that has APEX Enabled turns on a lot of features that may violate business & security practices and should be disabled. Example if you are using an SControl calling APEX webserivces on a standard user, it will fail because APEX is not enabled. If it's enabled the standard user can do lots of stuff they shouldn't. This could violate business and security policies.
Feature:
The feature is the ability on Triggers/Classes/etc, at configuration time, specify a doAs Profile to execute the requested operations with APEX enabled, restricting features to a specific profile (or set of profiles). The consuming profile (standard user) could have privileges to execute the doAs operations, but without receiving all the rights of the privileged profile. The privileged profile could specify the set of profiles that have rights to use it's services. This is very similar to doAs in Java JAAS architecture and is very useful in security and isolation of functionality.
Expose the API via JSON-RPC
This is a big request, but it would make all of your partner's lives much easier:
**Please Expose the Salesforce API via JSON-RPC**
Here are a three reasons. Good ones, I hope:
1. Our browsers will love you.
Web browsers love JSON. Authoring S-Controls would be come far easier.
2. Your partners will love you.
SOAP is basically a pain to use. No two implementations speak the exact same dialect out of the box, so getting a new client library working requires working out the exact sequence of incantations that will make the client speak the same "flavor" as Salesforce. For example, to use the popular SOAP::Lite Perl module, you need to instantiate it with these two options:
multirefinplace => 1
on_action => sub { return '""' }
Why? Um, it's confusing and complicated. You just have to.
Then, SOAP wants you to specify namespaced type information in the message itself. Type information which is unnecessary (Salesforce already has rich type semantics on the server side) and which can be actively harmful (watch what happens if you accidentally specify a date/time field as "xsd:date" instead of "xsd:dateTime". Of course, if you want to specify "xsd:dateTime" you need to make sure you specify "http://www.w3.org/2001/XMLSchema" for your xsd namespace, as the older versions don't have a dateTime type. Why should I have to care about this?)
I could go on and on, but I doubt that anyone seriously argues that SOAP is easier to use that JSON-RPC.
If you are using codegen tools to convert WSDL to a fully compiled stub object, SOAP approaches the level of usability that JSON-RPC gets right out of the box. This doesn't help those partners who use dynamic languages (again the browser argument), which is funny because dynamic languages are so well suited to developing clients of your API where everything is just a scalar, hash, or array.
3. Your bottom line will love you.
JSON-RPC is significantly less verbose than SOAP. Now, message size alone is a poor reason to choose one RPC mechanism over another. However, JSON-RPC is shorter by virtue of being more concise - so readability is increased, rather than decreased.
For example, let's look at a simple API "create" action in both SOAP and JSON-RPC:
<?xml version="1.0" encoding="UTF-8"?>
<soap-env:envelope>
<soap-env:header>
<sforce:sessionheader>
<sessionid>.......</sessionid></sforce:sessionheader>
</soap-env:header>
<soap-env:body>
<sforce:create>
<sobjects>
<sforce:showas>Free</sforce:showas>
<sforce:activitydatetime>2006-08-21T23:45:05Z</sforce:activitydatetime>
<sforce:subject>Test subject</sforce:subject>
<sforce:isalldayevent>0</sforce:isalldayevent>
<sforce:whoid>00Q30000000twaoEAA</sforce:whoid>
<sforce:durationinminutes>10</sforce:durationinminutes>
<sforce:description>Test description</sforce:description>
</sobjects>
</sforce:create>
</soap-env:body>
</soap-env:envelope>
And its equivalent in JSON-RPC:
{ "method": "create"
,"params": [
{ "SessionHeader": { "sessionId": "..." } }
,{ "sObjects": [
{ "type": "Event"
,"ShowAs": "Free"
,"ActivityDateTime": "2006-08-21T23:45:05Z"
,"Subject": "Test subject"
,"IsAllDayEvent": false
,"WhoId": "00Q30000000twaoEAA"
,"DurationInMinutes": 10
,"Description": "Test description"
}]
}
]
,"id": 1
}
The readability argument is self-evident.
In terms of byte size, stripped of unnecessary whitespace these messages weigh in at 1306 and 410 bytes respectively. gzip'ing these to simulate HTTP compression brings the counts down to 473 and 335 bytes, so even best-case the JSON message is 70% of the size of the SOAP message.
According to trust.salesforce.com, Salesforce's servers are processing around 130 million transactions per day. According to a November 2006 ZDNet article (http://blogs.zdnet.com/BTL/?p=4005) over 50% of these transactions are API transactions.
While I don't know the total number of bytes shipped around in these transactions, a 30% reduction in bandwidth used across 60+ million transactions would translate to a sizeable cost savings for Salesforce.com.
SalesForce needs better integration with Ruby on Rails
The current ActiveSalesForce Gem does not allow Ruby to make a good connection with SalesForce in the same manner as the pyax library does for Python and this is a huge problem for Ruby on Rails developers. (See also https://launchpad.net/pyax/)
With pyax I am able to process SOQL Statements through SalesForce very quickly (faster than 240 ms per query) however Ruby on Rails is not able to achieve this same level of performance.
Maybe someone needs to port the SalesForce Beatbox to Ruby (http://code.google.com/p/salesforce-beatbox/)
Support for aggregate functions in SOQL
We often need to bring back way more data than we need to and do extra processing on the client because we can't use aggregate functions in SOQL queries. Specifically MIN, MAX, COUNT and SUM would be very very useful. We should be able to group on any field and use these aggregate functions on any other field, eg:
SELECT StageName, SUM(Amount) FROM Opportunity
GROUP BY StageName
Also, to truly make these functions useful, you would need to be able to use them on lookups as well, eg:
SELECT Owner.Name, COUNT(*) FROM Opportunity
GROUP BY Owner.Name
Create AppExchange Toolkit for Visual Studio
Please create an AppExchange Toolkit for Visual Studio. This would enable developers who are familiar with Visual Studio to have a consistent UI when developing APEX applications.
Allow Apex Triggers to call External Web Services
Allow triggers coded in Apex to call external web services, not just the Salesforce API.
We understand that there are issues that must be considered, particularly security concerns and the need for resource governors, but it should be possible to provide a reasonable level of support for this.
Access Personal Tags using the Salesforce API
The new Personal Tags feature in Spring '08 is great... now I'd like to access the values my users enter from my own applications.
It would be great to be able to access the tagging information via the API.
Personal Tags Enhancements
Would be nice to be able to search on personal tags and/or make them available via the API
Subscribe
POST IDEA
TOP USERS