Perspectives on Salesforce.com

If you build a number of s-controls that provide custom web UIs to the users, you are probably using styles for formatting the page. This is usually done within a < style > tag inside the s-control. If you have a number of s-controls that produce a similar look and feel, then you are probably copying the styles to each s-control. To change the design, you end up making changes in each s-control.

I was doing some s-control development recently and I got to thinking whether I could maintain my styles in a separate s-control and then reference that s-control like I would a CSS file. It worked! This is synonymous with maintaining a separate CSS file on your web server rather than embedding the styles within a < style > tag. This will allow you to change the styles of all of your s-controls from a single location.

An example of referencing an s-control as a CSS file is below. To reference an s-control containing your styles, simply use the the following code.

< link href="/servlet/servlet.Integration?lid={ID_OF_YOUR_CSS_S-CONTROL}” type=”text/css” rel=”stylesheet” >

Depending upon the amount of s-control development you do, this may or may not be necesary. But it’s a cool trick to know if you need it.

If you are developing something to upload to AppExchange for others to use, be careful going this route because the ID of the s-control you reference will be different in each Org your package gets downloaded to.

When you have a new Salesforce Org setup for your company, there are some fields that default to being invisible in the Field Level Security settings. I am not sure why they default this way, but they do. Below is the list of fields that are invisible (even to the System Administrator) by default.

• Assets: Product Code, Product Description, Product Family
• Cases: Asset, Closed by Self-Service User, Closed When Created, Visible in Self-Service Portal
• Contacts: Do Not Call, Fax Opt Out
• Contract: Contract Name
• Events: Visible in Self-Service
• Leads: Do Not Call, Fax Opt Out
• Opportunities: Campaign Source, Private
• Tasks: Type, Visible in Self-Service

You can make these fields visible in your org by editing their Field Level Security settings. If you have questions about the purpose of these fields, check out the Help section of your Salesforce application.

If you have an application on the AppExchange and have setup a test drive, you were supplied 2 usernames: an admin user and a eval user. The admin user allows you to configure the system for your test drive and the eval user is the one that your test drive runs as.

How can you measure important metrics such as:

• How many people have downloaded my application?
• How many people are test driving my application?

I cannot help you with the first question (can Salesforce?), but you can get some information on the second question without asking Salesforce for the information.

To do so, log into Salesforce as the Admin user and navigate to the Setup | Manage Users | Users screen. Click on the Evaluation User record that you use to run the Test Drive as. Scroll down and you have a Login History listed there.

From that list, you have an option of downloading the Login History. One nice thing about this is that the IP address is listed. If you wanted to, you could use this information to append data to the records and report on usage by region. If anyone has suggestions on a good way to append this information en masse, please comment here.

Add a little Excel magic to the downloaded file using a Pivot Chart and you can get a nice graph on the Test Drive usage. Below is a graph of the Test Drive Usage for my User Adoption Dashboard as of today. Once I downloaded the file, it took me about 5-10 minutes to get this chart the way I wanted. This requires some knowledge of Pivot Tables/Charts and Excel formulas.

This only answers the question of how often your application is being Test Driven and is not a complete measure of success. It’s a start. Other uses for this data include.

• Measuring how often the same IP address is test driving the application
• If you are appending region or network name information to your file, you can measure how often members of a specific Network Location are accessing your Test Drive
• Did the number of Test Drives increase in line with various marketing activities you have going on to promote your product/service?

Note:
While writing this post, I received an email from Salesforce about the Lead Service from AppExchange. This answers the questions I raised at the beginning of this post. It provides a mechanism to populate your own Salesforce instance with information on who is performing Test Drives or downloading your app. They do this by having the user (optionally) complete a Web-To-Lead form that maps to your own Org. This is great news and is the best way to report on Test Drive and Download usage. I just learned about this and have not enabled this on my Test Drives. It does not appear that they will be passing IP Address, Browser or Platform information in this service. That is only available in the Login History.

back to top

Although Salesforce does not fully support dynamically required fields, you can use the dependent picklist feature from the Winter ’06 release to implement this functionality when the field to be required is a picklist field and it’s requirement-rule is based upon another single picklist (or checkbox) field. To illustrate, the following requirement is common for many sales organizations and can use dependent picklists to fulfill it.

Require the end user to select a Reason Lost when the Opportunity Stage is set to ‘Closed Lost’

The steps to accomplish this are:

1. Create a custom picklist field called ‘Reason Lost’ on the Opportunity Object.
2. After creating the field, add a Field Dependency with the Stage as the controlling field.



3. Associate all of the Reason Lost values with the Closed Lost controlling value.



4. Add the Reason Lost field to the Page Layout and require that field.
5. You are already finished!

Here it is in action. While the Stage is set to values with no corresponding Reason Lost values, the Reason Lost field is read-only and is not required. Once the Stage is changed to Closed Lost, the Reason Lost field becomes read-write and is required.

Salesforce.com just announced 2 new developer toolkits for PHP & Ruby on Rails.

Ruby on Rails project page.
Ruby on Rails quick start.
RoR toolkit is also a gem: % gem install activesalesforce

The PHP Toolkit is located here. It is included with very helpful documentation to get you started. From what I can tell, it has to be run on PHP5 because it relies on some SOAP extensions in PHP5. Does anyone know if there is a workaround for PHP4 for this toolkit? My ISP is still on PHP4.