Friday, March 5, 2010

Three Reasons Why You Should Do Away From Sites!

Working on several large projects in the past to address community needs in the CRM arena, Sites seems to be an attractive and suitable choice which directly integrates with your CRM application. You can open up and share your CRM tabs, objects and data to your target community on the web and it's all fully secure.

The basic customer portal theme seem to be a bit tasteless if you are to use the standard Visualforce components however utilizing them has two benefits, first and the most important is speed in delivery of the project, secondly if you are to add your ideas or solutions, as is, then all your tabs and pages would enjoy the same look and feel.

However, there are some major issues that still needs to address before this platform is fully ready for large scale projects.

Here are some of those, I came across:

1) Stability 
Since the technology is fairly new and is rapidly trying to introduce new ones and get ahead of the competition, it seems that they inevitably had to make some sacrifices. In many cases I encountered bugs that could have been easily caught and removed from the system.
One example of which is the sign up process in force.con customer portals, when a new user registers, two records will be created, a Contact record and Portal User record. The Contact record should be linked to an Account record as well.
The problem is that if you created an account at the sign-up time and then tried to link the new Contact to that Account, because the Guest user in does not have a role and therefore can not be the owner of an account in Salesforce then the whole process would fail (so why allowing the guest user to create an Account in the security profile!). Furthermore, if the Account owner is a deactivated-user, the same error would be thrown!

In many other cases I encountered styling issues, where, in ajax calls the portal styles would go nuts or I heard some user complains from that the pages were not behaving/rendering the same way in different browsers.

Funny thing is that even if you turn off standard styling in your visualforce page, still includes them in your pages, causeing conflicts and a lot of headache!

2) Diagnostics
There are no system diagnostics provided to you out-of-the-box. You are on your own to implement one to be able to find out what's going on with the internet users trying to sign up, login and use your customer portal!

The thing that makes the sites de-bug and diagnostic process very hard is that it runs your visualforce pages on a different security model (two different profiles compare to standard profiles in Salesforce) which you can not mimic in your own environment.So you are forced to create sample portal users and browse it like any other user and see/test it for yourself. The downside to this is that the errors are not really shown to you properly when you are logged in as a Guest user or Customer portal User.

In many cases, I saw as a result of an Apex exception the user sees the "under construction" page!!
Even though you have specifically configured your site to show your own custom error page! Also if the user browses a page URL that does not exists.... they do not necessarily always see your 404 error page but rather the one and only "under construction" page again!!

All for you to rely on is the famous Apex error notification email which potentially can indicate something went wrong for a user. The other problem is that only the last person who has deployed the code receives these emails. In larger projects were a group of developers are working on the tasks, this does not seem to be a practical solution to provide diagnostics.

3) Profile Limitations
Salesforce is imposing several security limitations on sites and customer portals that do not exist with API integrations. So folks who are using an external application as their community portal and integrate with Salesforce enjoy more freedom than others who want to utilize sites!

One example of which is that the customer portal profile can not update Contact records. This is all nice if you want to protect your business data and separate them from user's profile data. However, in many business cases your requirement may be to add a few custom fields on the contact record and make them available to the portal (as a self-service data management type of business operations, where possible you'd rather have the customer manage their own data).

I have seen people adding that to the ideas site, but this is a practical need which is not available at the moment in sites.