Salesforce IdeaExchange
Mini-Profiles for Applications
Have you ever been challenged with installing and upgrading packages? Have you ever needed a more granular set of controls and permissions for users on a per package or application basis? When downloading applications from the AppExchange, have you ever wanted to delegate your administrative capabilities over just that one package to a user or group of users?
If you've ever answered yes to any of these questions, you may be interested in reading further. Access to package contents is currently the the domain of a profile. When you install a package into an org, you must specify either a full or no access model on a profile basis. Of course, there may be times when you want to provide more granular control of which user's get access to which portions of package functionality. For instance, a designated SFA user may also need to be an administrator for a set of dashboards that have been downloaded from the Appexchange. Or a Support manager may need to also be a hiring manager for a recruiting application. Or an HR business partner may need to submit their own PTO requests through the Time Off Manager application and, at the same time, perform data administration tasks such as managing the Holiday schedule. In all three use cases, it's impossible to increase or decrease access without affecting all of the users who share the same profile.
Access Controls for packages would allow you to better associate the sets of permissions and access that are necessary when distributing new applications and application components within an organization. Each new set of controls could be packaged and distributed throughout an organization. And each set of controls, which may resemble a subset of profile controls, would allow for better scoping of permissions on a per package or application basis. In addition, each package might have multiple levels of access including, but not exhaustive of, a package administrator, manager, end-user, or really any different set of responsibilities that a user might need to have.
Add Eclipse 3.4 compatibility to Force.com IDE
According to http://wiki.apexdevnet.com/index.php/Force.com_IDE#Installation, "Note: The Force.com IDE is not compatible with Eclipse 3.4." Unfortunately Eclipse does not provide downloads for any of their previous releases, only for version 3.4. The Force.com IDE needs to support Eclipse 3.4 as it is widely used by the developer community.
Chat
some area where there is a live chat room where people can go and connect and maybe get quick questions answered.
Use VisualForce email templates in Mass Emails and in Apex Outbound email method
Visualforce email teamplates are awesome, but we can't use them in mass emails or from Apex code. Please allow that in a future release!
Enable Mobile user fields for reporting
Need the ability to write a report to show Mobile user data - like last registration date, mobile configuration, device address, Device OS, etc. I can create the details in a View in Mobile Users & Devices under Setup, but can only get it into Excel by copy/pasting it from the view.
Pre-release improvements
The current pre-release process is broken in a few ways
1. No code freeze
The pre-release environment is very different from the eventual release. When we find a bug in pre-release, we're never certain if it's an artifact of pre-release or if it's actually a new bug.
Conversely - and much, much worse - things that work perfectly in pre-release suddenly break when the new release actually goes live because salesforce's developers are adding new features & new code long after pre-release is available.
2. Namespace changes
Changing the namespace of our code makes it much more difficult to actually develop or bugfix on pre-release. We would have to fork our existing code with the new namespace, and then eventually merge changes back into the mainline while being careful not to bring the mangled namespace back with.
3. Inability to test packaging
I want to be able to build a package in pre-release, upload it to a private AppExchange package, and then install it onto a separate org (maybe sandbox?) to test that entire cycle.
The Winter09 release in particular has shown just how important each of these items is, as many partners and ISVs have had to deal with a two week period of breakage since the release.
These past two weeks have entailed a lot of late nights for partners and for salesforce's own developers; this could have been avoided with a better pre-release process.
IdeaExchange Posting Guidelines
An informative Community Guidelines document/alert/post should be made available. Upon joining a forum, new members should receive the guidelines and some incentive should be in place for them to review the guidelines.
I was a member of a very successful blog that put such an item in place and it was VERY beneficial to the overall quality of the community.
The guidelines should emphasize basic guidelines in a concise manner.
Ex:
1) Is the idea necessary? - If you are not reasonably sure your issue is not currently available in SFDC, perhaps you should review discussion forums or "Help & Training". If you do not have time, clearly state that this COULD be a current function and you do not have time determine so.
2) Search for your Idea pre-post - keep our community clean and productive by searching before you post. Make a concerted effort to locate similar ideas and, if they are located, comment on them or suggests merges. If you post, be sure to review the similar ideas suggestions.. ...some SFDC developer will be happy your using their code and you might just find something you missed at first.
3) Make titles meaningful - Titles like "reporting" offer other members little idea of what your Idea is about. Include Object names, specific functions/features as well as a brief notion of the issue/limitation.
4) Be clear and concise - When posting and idea, put other members in the best position to judge and respond to them.. ...Clearly state the specific issue your idea recommends addressing/enhancing. At the same time, make your post reader-friendly by keeping your idea to a few post.
5) If possible, picture it - Everybody loves colors! Make pretty pictures if you have the time. Conveying your idea visually allows community members to better envision your proposal and will lead to more promotions.
6) Be respectful - A successful community is built upon an open flow of dialogue. It is just as important to critique suggestions as it is to promote them. However, remember that we all seek a stronger more robust SFDC and demeaning, insulting activity only serves to impede that effort. Always keep in mind, it's about Salesforce, not about yourself.
Need to report on Objects with no activities. Specifically objects that have never had an activity associated with them
You can report on closed activities, open activities, late activities, etc. However, the one thing you cannot report on is whether an object (in my case, a contact or an account) has never in its existence had an activity associated with it. This would be SO helpful to my org in determining an unserviced client.
Subscribe to Ideas - RSS Feeds and/or Idea Watch List
Allow users to subscribe to and/or create personal tags/favorites for the Ideas they care about the most, above and beyond merely voting for an Idea.
Often we vote for hundreds of Ideas that we like, but there may only be a handful that we really, really care about. Users need to be able to create a "Watch List" of those Ideas so that they can keep track of their status, and/or subscribe to an RSS feed that might alert them when an Idea changes status to "under review" and "released".
Users should be able to see their Watch List/Subscribed Ideas in a list or tab, as they currently can with "Ideas Submitted" and "Ideas Voted On".
Salesforce to Salesforce - Include the ability to share formula fields
Is it on the roadmap to share formula fields with SF 2 Sf?
Mobile Device Security and Control
Introduce an Org Settings page for Mobile to do 2 things:
1) Restrict the device types that can connect to Salesforce.
2) 'Lock' users to the device that is registered until the Admin deletes the device.
The two parts of this feature would allow fine grained control over who can use what device with Salesforce Mobile and still not be an overwhelming Administration burden.
Global "Filter Profiles"
I would like have the ability to apply "filter profiles" to reports, custom list views that are saved for continuous use. More often than not, I'm looking for the same type of information but in a report, in a list or in a search. I don't like having to constantly pull the same drop downs, pick the same operator and write the same advanced formula. Wouldn't it be nice to "apply" a filter-set on various items at various times.
The programming should be sophisticated enough to substitute object-specific field names. If I'm viewing a contacts page, then a formula originally written for an account filter, would be automatically converted to a contact filter. Account.name would become Contact.name, etc.
Say I create a list view for all contacts owned by Matthew McKinney in the state of Ohio. I want them all to have been created after the first of the year. ... Now I want to see all of the accounts that meet the same basic criteria. The only difference is the Contact name field (typically). As I create my account custom list view I can "paste" these filters across objects and into setup functionality.
Not necessarily a user-feature, but more so an admin-feature.
Subscribe
POST IDEA