Salesforce IdeaExchange
Record types should be included as 18 chars in backup
All ID fields in the backup are in 18 character form, except the record type field in each csv file, which is 15 chars long. However, the ID field in RecordTypes.csv itself is 18 chars.
Perhaps it's not a big issue, but if you try to join the CSV information together (eg external analysis, or data synthesis) then you have to REMEMBER to trim the ID of the record type records.
It's just inconsistent - surely there's no reason for this.....
API only user
We have several external application, from Drupal modules to 3rd party applications that post/submit information to SF.
The biggest hurdle is to assign a user name for the API access. I don't want to provide such an application with a standard account, but instead, I would like to have some kind of a API only (no gui access) type of account.
This way, I could assign for my API access a different user , and could know whic of them is doing what. I can control them, have reports etc.
I think that such an account would have to cost a lot less than a regular account also.
Apex Data Loader: "Dry Run" test mode
When running an Insert, Update, or Upsert it would be nice to be able to run the batch but not actually have it do anything but validate the data - sort of a "what if" mode. Then you could see any errors or problems ahead of a real operation, instead of having to go back through the "error*" CSV log file to figure out which records need to be repaired and retried.
Apex Data Loader: Unlocked "System" Fields
The option to set the System Fields (CreatedByID / CreatedDate / LastModifiedByID / LastModifiedDate) upon initial import is appreciated, but sometimes these need to be updated later on, and should be accessible for updates and upserts as well. Even if it is an option that needs to be externally enabled via account manager - such as the ability to insert into them in the first place - some companies and workflows would benefit from this immensely.
Apex Data Loader: Allow access to fields not visible on Layout
In order to import, update, upsert, or export any data from and object in ADL, the field(s) you want to access must be visible on the page layout for the object you are working with. Some data is not useful except for administrative or programmatic uses, and therefore should never be visible to users, yet it should still be completely manageable via ADL.
It just does not make any sense (to a programmer or DBA) that a field exists in the database ("objects") behind the front-end ("layout") and it not be accessible using the tools that directly modify an aspect of the database ("objects") just because it is not available to users on the front-end ("layout").
Apex Data Loader: Allow for "silent" updates
In cases where an administrator/programmer needs to mass update records, such as importing content for a new custom field or re-importing a single incorrectly mapped field from another source during a migration (without mass-delete and then re-import), Apex Data Loader should allow for a silent or stealth update mode which does not change the "LastModifiedByID" and "LastModifiedDate". It should be up to the administrative user whether or not they want the LastModified info to be destroyed by their update. Some workflows depend on knowing who last touched the record and when, and replacing it with an administrator/programmer ID just because they were doing something otherwise innocuous really screws everything up.
This could either be a keyword in the LastModified field(s) to signify "no update stamp" on a per-record basis, or a checkbox in the settings such as the "insert nulls" option, applicable on a per-batch basis.
Support Polymorphic keys in semi/anti joins subquery
In Winter 09 support was added for semi/anti joins between objects. What this allows you to do is write a SOQL relationship query that returns just records that have a parent/child record or just records that don't have a parent/child record. Essentially an inner join in SQL. Unfortunately, this does not work with polymorphic keys. So you can't write a query that returns just the custom objects that have attachments. The following query as it is today will function as an outerjoin thus returning all of the custom objects for the specified account whether they have an attachment or not.
Select c.name, c.id, c.recordtype.name, (select a.name, a.createddate from attachments a)
from custom_object__c c
where c.accountid = 'xxxxxxxxxxxxxxx'
order by c.createddate desc
The Winter 09 functionality would make the query look like this but currently it doesn't work with the polymorphic relationship between attachments and their parent object.
Select c.name, c.id, c.recordtype.name, (select a.name, a.createddate from attachments a)
from custom_object__c c
where c.accountid = 'xxxxxxxxxxxxxxx'
and c.id in (select parentid from attachment)
order by c.createddate desc
Option to remove the need to use __c when refering to custom objects and fields
Currently when writing Apex code it's looks quite messy when you have to write:
Person__c person = [SELECT FirstName__c, LastName__c FROM Person__c WHERE Location__c = 'USA'];
It would be so much more readable and nicer to write this:
Person person = [SELECT FirstName, LastName from Person WHERE Location = 'USA'];
If the idea is to promote Force.com as a development platform for more than just CRM add-ons, then we'll assume there will be many customers/vendors writing code that will never use any of the Opportunity/Account/Contact standard objects and thus _everything_ is a custom object. It would be nice to treat these as a little more "native" by getting rid of the need for __c. Perhaps this could be a configuration option whereby Apex could insert the __c behind the scenes for the user upon compilation.
Enable Access to Raw Post Data in Visualforce Pages
It would be great if we could access the raw post data sent to a visualforce page (exposed through Salesforce Sites) ...
e.g.
postData = ApexPages.currentPage().getRawPostData();
This would enable us to process XML from a variety of outside services (such as Google Checkout).
Exportable Field Lists or Pick list values to Excel
It would be useul if Admins could export the list of fields or a list of pick list values by object into excel. Often times we need to do some extrapolating of data outside of the system using lists of fields or values within pick lists. Right now, all we can do is copy the HTML content, paste into excel and then copy and paste the values. It would be much easier if these lists were exportable just like report results.
Thanks!
Platform Support for I/O Streams
Now that we have the ability upload/download files on the platform, we would like the power to be able to manipulate files. For instance, the ability to do the following:
-- Parse text files uploaded to the platform.
-- Manipulate data and generate output files for download.
This functionality currently requires development on an externally hosted server (i.e., bringing infrastructure back into the system).
Provide Coradiant experience (network performance) analytics to end users
We heard at Dreamforce that Salesforce uses Coradiant to analyze their network traffic to identify where bottlenecks are in the networks that are delivering their service to end users.
I've encountered multiple circumstances where I'm supporting Salesforce end users (different customers, we're a consulting partner), and they are complaining of poor performance (or I'm experiencing incredibly poor performance from their network). I can go to trust.salesforce.com to make sure that there aren't any service problems, but that still doesn't help me understand exactly where & why we're experiencing a performance issue. It would be very helpful to have this network performance data available to end users to help them (and especially their organizations) understand why they are experiencing poor performance when using Salesforce.com.
Subscribe
POST IDEA