Entries in (21)


Benioff's Brainstorming

I've been doing my best to track and keep up with all of the web buzz in the weeks leading up to Dreamforce 2011, yet between all of the excitement on Twitter and a ton of really insightful blog posting I simply haven't been able to take it all in. (Aside: I wouldn't want it any other way! This just goes to show how much enthusiasm the entire Salesforce community is harboring for the event of the year.) Anyway, I wanted to take a step away from the Dreamforce train for just a couple of hours and talk for a minute about the implications of a Marc Benioff quote I found on in a Cloud9 Article.

"We're looking at new ways to be more deeply monetise…the way we charge for is, it's on a per user basis, and then you can get all the apps you can eat. I think that we would really like to move more to a per app model on That was certainly a great way to get going with the product, but wow, we have seen companies, so many companies build so many apps on that I think we're ready to start talking about per app pricing, not just per user pricing."

Right now,'s most popular package is $50 per user, per month. This deal gets you all of the basic features, plus access to 10 apps, 200 database objects, full use of account and contact objects, mobile access, and integration with 900 AppExchange apps. By switching around the service to charge on a per app basis rather than a per user basis, I think Benioff's idea is to make it more affordable for companies to dabble in Salesforce, while making it more expensive for companies that really make a waist-deep investment. I see where he's going with it, I think it makes business sense, but I don't really like it. Salesforce has a loyal customer base and an extremely loyal developer core. They should be encouraging companies to make the plunge and really invest in Salesforce technology rather than jacking up the price just to make a larger profit off of those that have been with them the longest.

Moreover, Benioff would do well to remember that there are a lot of other CRM solutions out there. Some charge per app, some per user, and others even allow you to purchase the platform itself and form it perfectly to your business model. While Salesforce is undisputedly on top right now, Benioff might think he has more room to work with than he actually does.


Usable UI

As a developer, I love to get into the intricacies of the code.  I love flow charts, thinking about how to solve a problem, untying a knot with code into a smooth working system that solves a problem.

But loving code, and the challenge of solving a problem from a technical standpoint, is only half the equation.  If your code lacks usability, users won’t use it, and ultimately, no problem is solved at all.

I was recently reading some literature on UI design.  What it boils down to is “keep it simple.”  Unless you’re writing for tech geeks, most users want a simple and clean interface.  Dummy proof the interaction that’s needed.  Think of Google.  There are all sorts of best practices lists when it comes to UI design.  I’ll let you go find those on your own.  But I do want to emphasize the value in keeping things as simple and clean as possible from a user’s perspective.  Keep the complex and beautiful intricacies of the code in the background—like a secret to be shared among developers.

In a conversation I was having with a Salesforce consultant, the consultant was singing the praises of an app that had been developed by a third-party vendor.  The app was pretty sophisticated, did a lot of different things, and helped to solve an important problem.  BUT, my consultant friend also commented on how the UI was almost incomprehensible.  There was nothing intuitive, and even after some training, she still found herself lost when confronted with how to make the software do its magic.  Not a good outcome after having worked so hard to make a great piece of software.

I will make one recommendation and that’s to do some split testing of your UI designs with beta customers before settling on the final look and feel.  As a bunch of developers, one of the worst things we can do is try to anticipate how our users will use our products and what they’ll be thinking.  We need to talk to them directly.  It’s easy to do, and it’s time well worth investing in our development cycles.


Back to the Basics: Workflows

A week ago I posted that I was going to spend some time defining some terms used in Salesforce development and started with a post about the Apex language but managed to get distracted by a few other topics. So now, I am going to step back and look at another piece of the foundation: Workflows. In the simplest view, it is exactly what it sounds like. The order in which business processes move in or out of a business. Automating these processes is about increasing worker productivity and improving consistent results.

Specific to Salesforce development, the definition does not change much. The goal still is to automate and simplify. A workflow is an action that is tied to an object, automatically triggered by a change to a record in the object. That's the goal. A simple way to extend objects with automated responses. Examples would include sending an email alert, communicating messages to other applicaitons, assigning a new owner to a record.

The workflow designer allows for developers or nondevelopers alike to put these workflows in place without writing code. Simplify is the key.


Salesforce Chatter API Help

Developers working with are hearing social, social, social when it comes to customization for their org. My to-do list definitely includes brushing up on Chatter API. I saw where Quinton Wall posted the recorded webinar today that covers Chatter REST API (which I missed, so I will be headed to to watch.

I will make time to listen start to finish but in my rushed schedule today, I was able to move through the Tips and Best Practices page to find exactly what I needed quickly. I had a question come up about URLs and found that there are two classes of URLs in payloads. Their quick summary on the topic says:

Static assets URLs like profile photo thumbnails are returned as fully qualified URLs. All other URLs are relative to the context user’s instance. An instance is a subdomain in the URL, such as The user’s instance URL is returned along with the access token at the end of the Oauth process. Append relative URLs received from the API to the instance URL before sending to a browser. Note that a user’s instance URL can change over time. Changes are rare, but generally you should avoid caching the API’s output for long periods of time because when representing a dynamic feed, resources may be updated or deleted at any time.

Other topics on the FAQ page are:

  • ·         Authenticated user can only see and post to their own news and to feeds
  • ·         Group Feeds
  • ·         Rate Limits
  • ·         Renewal Token

Here's a link to the recorded webinar for your viewing pleasure!


Apex Code for

In keeping with my recent theme of defining some key terms when it comes to Salesforce development, I want to look at Apex today.

Apex is the native programming language of the development platform.  It is an object-oriented programming language that enables calls to the API with execution of flow and transaction statements.  Apex allows developers to add various kinds of business logic to most actions taken within the Salesforce org like updates and clicks.  Apex syntax resembles Java, and acts like database stored procedures.  Scripts written in Apex are kicked off by web service calls and from triggers on objects.

One of the leading benefits of developing in Apex is that Apex offers flexibility while also reducing the number of calls between the server and the client.  While any Apex-developed app needs to communicate with the Salesforce servers each time it accesses data, such apps (those developed with Apex) handle such transactions natively.  Client-server communication is only required when receiving and presenting user input.


Salesforce S-Controls

Recently, a client was asking me about S-Controls in Salesforce.  He’d been to a user’s group meeting and heard the term tossed around, but had no idea what it meant.  I explained to him what S-Controls are, and informed him that they are now, fairly recently, somewhat antiquated.  But given that they are still widely in use in a lot of Salesforce orgs, I suppose it makes sense to define them here.

S-Controls allow Salesforce developers to leverage HTML and Javascript to create custom pages and UI components.  These customizations are used when an admin needs to work with a small set of records or fields, or if he or she needs to link to an external server.

S-Controls enable developers to add their own functionality to a Salesforce org.  Among some of the possibilities, you can integrate hosted apps, or extend the Salesforce UI. 

Custom S-Controls can contain any type f content that can be displayed in a browser, whether it be a Java applet, an Active-X control, or an HTML web registration form.  The custom S-Control library is where you store and upload the content that you want to use within your org.

S-Controls have essentially been replaced by Visualforce pages.  If you currently have S-Controls in place, they will remain active and can be modified.  But any org that has not created an S-Control before March 2010 or any new orgs will be prevented from using S-Controls in favor of Visualforce pages.


Unit Tests on the Salesforce Development Platform,

The Salesforce development platform,, requires that at least 75% of Apex code in an org be executed in unit tests before the code can be deployed in a production environment.  These tests are important because they allow you to ensure that your code works as expected and planned, and enable you to build a functioning foundation and grow from there.  Such tests also help to keep your code clean as you continue developing it, and they can provide you with a history of that development process should you need it for other tasks or purposes.

When writing your unit test, be sure that they create their own data to execute against.  Doing so will ensure that your tests can be run time and time again and that they aren’t dependent on a particular configuration and setup.  Moving beyond such a setup can lead to failure.

When writing your unit tests, be sure they are thorough.  The 75% coverage is a minimum set by Salesforce, but best practices dictate that you should always strive for the highest possible coverage.  Your guide should be your own level of confidence that your unit tests fully verify that your code works as it is supposed and that you can convey that confidence to any users.

Like the scientific method whereby experiments and their results should be repeatable, your unit tests and their results should always be consistent and repeatable.  Once you’re confident that your tests can be run with consistency, you can trust that if they fail, they’ve found true bugs that need your attention.   Salesforce reports that some common mistakes that can stop unit tests from being repeated are relying on hardcoded URLs (unit tests are written in dev or sandbox orgs, which will have different URLs than production orgs), and relying on hardcoded records IDs (records IDs are specific to the org the records resides in).

Lastly, unit tests should be laser-focused on a specific and single aspect of your code.  Each test needs to be independent from all other tests that are run in your code.

I’ve learned to follow these steps in developing my code, and they’ve served me well. 


Adapting to the Cloud

When I saw the title “12 Ways the Cloud Changes Everything,” I knew I had to read it and when I read it I knew I needed to share and comment.  No promises that you will learn anything revolutionary but when someone has the ability to take a very complex subject and simplify it into digestible pieces I think it’s a worthy read. It's an overview, for sure, but the following list of 12 Ways may be valuable when thinking through future discussions like how your licensing will change or in what ways your IT departments will need to adapt.  This article discusses cloud computing and the future of applications being written for the cloud. Even though cloud computing has been around now for years, it is still a divisive topic. For some yet those who have adopted it fully are feeling very progressive and are even ready for the next wave of innovation but many are still considering whether to adopt the principles of cloud computing and how to deal with legacy systems that have been in place and successful in the past.  The article is titled “12 Ways the Cloud Changes Everything” and the author puts together thoughts and tips from 4 analysts on how enterprise can best be prepared for cloud computing.  The 4 were together as a panel at the recent Cloud Leadership Forum in Santa Clara, CA. She quotes analyst Frank Gens as saying that:

“Some 80% of new enterprise apps will be developed for the cloud in 2011 and, in the past year, adoption has moved into the “early majority” phase."

The author put together the following 12 observations from the panel. I have summarized each of the 12 points and have provided a link at the bottom to view the post in its entirety.

  1. The cloud is the third platform.  First came Mainframe, where applications numbered around 2,000, then client/server came next leading us into the PC revolution. In this period, the number of applications moved into the tens of thousands. Today the cloud has enable the work-anywhere mentality and we are looking at the number of applications moving into the tens of millions. There is a shift to mobile apps, social apps and the analytics/big data that come with that.
  2. Infrastructure vendors will create a fourth leg known as “shared cache” extending beyond servers, storage, and networks. Rick Villers is quoted as saying “The impact of server virtualization is just beginning.”  As IT looks toward ridding itself of silos and moving toward converged IT, virtualization will be an important step in the architecture but must start thinking bigger. There will soon come a day when IT is designing for a hundred VMs instead of the current 8-20. Then you must think about recovery of that much data which leads to data centers needing to have the shared cache space.
  3. Bring your own license. Panel member Robert Mahowald expresses that the enterprise software companies that survive the transition to cloud computing will adapt their licenses so that software can be accessed from multiple locations at a single cost to users. Microsoft is allowing for what they call “license mobility” when a customer moves server applications from internal data centers to cloud computing services.  Other panelists applauded Microsoft for making room for the transition.
  4. The business will view IT’s role as the “internal app store.” IT departments may evolve into an IT services concept which would require a major shift to offering a smorgasbord of services available on many types of devices and within private or public clouds.
  5. Public clouds will become more important than private clouds, says Gens.  Clouds developed within a company’s own data center is missing out on the advantages of the new 3rd platform and all it offers.
  6. Clouds are a big source for big data. This data in storage is creating analytics about customers like never before. Looking inward, this is a grand opportunity to do research on your customers preferences and habits. On the outside there are compliance issues and concerns to be dealt with.
  7. IT organizations will become cloud services brokers. Picture the future of IT as the master of all cloud services agreements. The will be the infrastructure needed to service the business.
  8. The cloud disrupts and potentially scares off the traditional IT workforce.  Where there is change, there is fear but ideally there would be preparation of students entering IT careers. To avoid outsourcing, we need to anticipate the changes coming and avoid a gap in skills.
  9. One-third of your key vendors will become “wiki-trivia,” says Gens. Right now there are vendors embracing the cloud and the services and licensing changes required. Those who choose to hold on to the “way we have always done it” will find themselves a statistic in the long run for failing to adapt.
  10. When it comes to the cloud, vertical specialization will prevail. Customers will seek out companies who have moved their services to the cloud.
  11. You can’t avoid the personal cloud. Much like the PC revolution, the people most successful at this next-generation, cloud-based IT will be the ones who know how to balance the enterprises’ needs with the users’ work styles. End users already have built their own personal clouds on their mobile devices, says Mahowald. These clouds build their personal experience with the cloud and model the enterprise applications they will want to work with.
  12. Cloud services foster innovation. This is by far the most exciting element of the new wave. Rapid adoption of the cloud is ahead, with opportunity for the IT team along with executives to lead the charge toward more efficient and economical IT tools.




Salesforce Summer '11 Training 

Five online training modules on centered around the Summer '11 Release features make it easy to get up to speed and quickly focus on what is going to be helpful in your own Salesforce environment. Of course, Salesforce wants you to watch all 5 modules, which is not a bad idea since they are a pretty concise overview of what updates are available and much easier than reading release notes!

  • Chatter
  • Sales Cloud
  • Service Cloud
  • Jigsaw

You can find the modules in the Learning Center or just click here.