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.

Steve at GoKubi.com has posted his wish list items that append to my own.

Last night, I mentioned that NA2 was being setup. As of this morning, all of my accounts are being routed back to NA1. I spoke a little too soon that it was actually being setup last night. It must have been a temporary thing Salesforce was working on in the evening hours.

As was announced on the forums on 4/30, Salesforce is setting up additional logical servers (NA1 will be split out into NA1, NA2, NA3 and NA4).

There seems to be work being done at this moment. All of my Developer Edition accounts now route to NA2. NA2 is not up and running yet, but my Developer Edition logins are being routed that way. I am sure there will be an announcement from Salesforce soon as to what’s taken place.

My client’s accounts still route to their original servers (NA1, EMEA, etc.), so Salesforce seems to be taking it safe on who they move to that server today.

It would have been nice to have had some warning that these accounts would be routed to NA2 today. It’s been somewhat of a disruption this evening. Not a big deal, but it’s nice to know if an account is going down. Even if it’s only a free Developer Edition account.

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.