gokubi.com

In Winter ‘07 Salesforce.com had a major rev, and we got a lot of things that are really helpful. A couple stand outs:

• The ability to use includes in SControl (custom code) development
• Sharing custom fields on standard objects via the Appexchange
• Creating full-fledged UI buttons

I’ve been loving these new features since I got them, doing all sorts of new things which have significantly improved the user experience inside the databases I’m building.

But I’ve come to realize that some low-profile Winter ‘07 functionality is having a big effect on how I work. It’s making it much more difficult to do Salesforce.com SControl sharing via the Appexchange. I’m talking about Appexchange package validation.

When you package up a UI button for sharing, Salesforce.com is smart and realizes that the Button requires the SControl, which may require an SControl snippet (included library) and may make queries that call a custom field on a standard object. All these items are added to the package as required, and can’t be removed unless the Button is removed. They are treated as dependencies.

But when you go to install an Appexhange package, it tries to install these dependencies even if you already have them. And if you already have them, the install fails. You can’t install the package.

Here is why this is a problem. First, by using includes, I can reference existing SControl libraries. I have a Utilities library that is included in most of my custom code. If I want to package 3 different pieces of my app in different packages, they will all require the Utilities library, and won’t install because of conflict.

Second, we’ve gotten together in the nonprofit community and worked with the Salesforce.com Foundation to identify a set of objects and fields that are common to nonprofits using Salesforce. So a lot of the people I want to share code with already have a Fund field on their Opportunity object. This is great–the commonality helps us share. But in this case the commonality causes the Appexchange installs to fail. They already have the fields that are required for my code, but the install fails because they already have the fields that are required for my code. Arg!

Third, Salesforce.com uses record types on objects as a really cool way to extend customization ability. I use it a lot, especially for Opportunities. The new package validation inspects your code for references to record types. It appears to even find Salesforce.com GUIDS in hard coded variable definitions. And when it finds them, it won’t include the code in a package because record types can’t currently be Appexchanged. So any code that references record types can’t be appexhanged at all.

Sharing of code from one instance to another is now back to way I did it before Winter ‘06–copy and paste text files. There are very few things I can Appexchange without problems. It makes doing consulting on the platform more expensive, and it makes sharing with colleagues and the broader community more difficult.

To fix the situation, a couple of things need to happen. I’m all for a package containing everything it needs to work, but the installer has to be smarter. If a field that is part of the package already exists in the install destination, warn the user and then install the package. Maybe even check to make sure the field is the right type.

Next, the code library situation has to be figured out. How can you code with libraries and share them modularly? I don’t know. Perhaps on the fly renaming of snippets that run into naming conflicts? That would at least get the package installed, and redundancy could be cleaned up later.

Finally, record types should be ignored by the validator until there is a good way to handle them gracefully. I need to be able to refer to record type Id’s for my custom code to do anything helpful. If I can eventually Appexchange full record types, that’s great, but they have to gracefully abort if they already exist in the destination databass.

Maybe Spring ‘07 will fix some of these validation issues. I can imagine that Salesforce.com has some unhappy customers, especially if this behavior is being seen in their Sandbox product. People are paying money for that service which is supposed to make testing and installing code easier. I would be upset if I were paying for a product that lost functionality unannounced.

I have faith they will be fixed. I’ve been continually impressed with how Salesforce.com is moving the platform forward as the complexity continues to increase. All in all, Winter ‘07 is still way on the positive side of the scale for me, and would be off the charts if these problems hadn’t been introduced.

This entry was posted on Tuesday, March 6th, 2007 at 9:22 pm and is filed under CRM, Technology. You can leave a response, or trackback from your own site.