Please Login with your Salesforce ID to post, promote or comment.
Salesforce IdeaExchange
FAQs | Terms of Use8060 Ideas; Promoted 170158 Times; 16384 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
AppExchange Directory Ideas
Subscribe
- Recent Votes
- Recent Articles
Adding apps using the AppExchange drop-down in the app shouldn't make me re-authenticate
If I try to add a new application from the AppExchange by navigating from my Salesforce instance, via the AppExchange drop-down in the top-right corner (clicking "Add Apps..."), the AppExchange shouldn't prompt me for my username and password again, as I've already logged in to the application.
Clean up the "OTHER LISTINGS BY ..." section on the Publisher tab on an AppExchange listing
The OTHER LISTINGS BY ... section on an AppExchange publisher page is really hard to follow. Especially for a publisher like Salesforce Labs who has a lot of items.
I'd like to request that this section UI be updated to provide more information. The picture above shows the beginnings of the search results I get when I search for Salesforce Labs.
Something along these lines would be more readable. It would also provide a more professional look to a publisher's AppExchange page.
Make managed packages less restrictive / more intelligent
Making an application "managed" is a big step. Immediately several items become frozen and fixed for all time. Although many of these make sense to permit upgrades, many are unreasonably restricting and do not allow for "normal" evolution of an application over several versions.
Take one example: the text comments in a help popop on a custom object field. They can't be altered after going managed. If user feedback says that the comments aren't helpful enough - tough luck. If the use of a field changes - again tough.
This example is one where the AppExchange system could permit the developer to make the change in the package - and then all future installations of that package have the new text. Anybody that has already installed that app and customised the popup help text would keep that customisation. The change to the managed package would only affect new installs.
There are several examples of the above intelligent approach to managed package upgrades.
Another big example is to permit items to be depreciated. This includes custom objects, fields and scontrol. These would be flagged as "no longer used". Or better still, not included in new installs of the package. Like the previous example older installations would not have the depreciated item automatically removed (although they could be given to option too if they wish).
User review responses
As a partner we realize that we will get negative reviews but currently there is no way to respond to these reviews in a constructive way without compromising the trust of the community. It would be great if a partner could respond to a certain user review on their listing page so the larger community could benefit from the exchange and get a taste of the partner's customer service chops. Ideally it would be more of a discussion board for the particular product.
Allow users to install AppExchange packages with dashboards and reports as personal items
When a package contains only reports and dashboards, any user should be able to install it.
It should create personal dashboards and personal reports so that any user that wants to try these reports and dashboards should be able to install them.
AppExchange standardized packaging of App config/properties
It would be nice if we could provide a (free as in edition limits wise) special custom object per AppExchange app installed for configuration properties of the application.
Giving developers the ability to store Application configuration as custom fields on this object using any or a subset of the available field types.
The record type (a singleton enforced by a trigger) for org wide configuration, the second record type for user specific configuration, so values from this are both available as global merge fields for the developer. And can be easy configured/adjusted by the admin, having an consistent ui/interface to this objects edit view via the setup admin area as well as audit trail of changes made.
Many apps implement the org wide config with a custom object storing key/value pairs and a custom scontrol ui, and then user specific config as custom fields on the user record which is fine, it would just be nice if we acknowledged this need for storing application preferences/properties and provided a more standardized way of achieving this.
Being able to set default values when packaging applications would be a logical enhancement to this functionality as well.
The object names could be easily generate e.g.
config_namespace__appname__c
As well as the global merge fields:
{!$Appname.Property}
Perhaps just making this another benefit of managed packages initally would be the right approach.
Ability to package custom record types on standard objects
For AppExchange Packages to allow packaging of custom record types on standard objects
The AppExchange should recommend apps just like Amazon.com
When I go to The AppExchange it should remember me, know what Apps I've used in the past, know if I'm a customer, and recommend Apps that are suitable for my profile and what customers like me have done in the past.
This is exactly how Amazon works and it leads me to be a much more successful buyer. The amazing thing about the AppExchange is that it knows more about me than Amazon. The AppExchange knows if I have actually USED an App that I downloaded and how I've used it. Amazon has no idea if I read the books that I buy.
The AppExchange should be able to provide even better recommendations than Amazon because it's a multi-tenant system.
Package Record Types
It would be great if AppExchange packages included record types.
Add Time Trigger Workflows to AppExchange packaging
Add workflow with time triggers to the items that can be packaged into AppExchange. Currently you can add them to the package but then you get "Workflow rules with Time Triggers cannot be uploaded to the AppExchange" after pressing "upload".
All other workflow can.
I was hoping this was coming in Spring 08 but it is still not there.
It would be OK if they installed in the deactivated state for security reasons. Just a real pain to have to click/type them in on every install.
Workflow is an important part of many apps.
Repository for S-Controls
Repository in the AppExchange strictly for S-Controls that may be conducive to re-use.
Mozilla Firefox to be included in AppExchange
This browser is faster and sales people like this browser a lot. Including this can be helpful, particularly mailmerging is not supported the opportunities page.
Subscribe
POST IDEA
TOP USERS