Perspectives on Salesforce.com

I switched the email subscription provider from Feedblitz to Feedburner for this blog. Feedburner doesn’t require you to make an account with them and you will receive the full content of the blog post in your email.

If you would like to subscribe to Perspectives on Salesforce.com by email, visit the subscribe page and enter your email address in the form on that page.

Version 1.0.7 of Arrowpointe Maps was just released. You can read about all the improvements on the Change History page. The changes that most impact user experience and the application’s capabilities are:

• Support for relating custom objects to Accounts and/or Contacts. This will allow you to pull fields from those objects including using the addresses there.
• Printing buttons were added to Map Pages and View Generated Maps. Look for the icon.
• Upgraded to the latest version of MapQuest’s API.
• Added a Declutter button to the maps. When pressed, any map points that overlap each other will be separated and a line will be drawn from their original point to their new location. In declutter mode, all map points will be easily clickable.

  

• Each time a map is run, it will display in the width and height used by that user the last time a map was run.
• Added links on the front page to let users open Map Pages in a new window. Sometimes this can result in better usability and printing since the application is not embedded in an IFRAME in Salesforce. Look for the image next to a hyperlink to open that link in a new window.
• Fixed some usability issues in the Admin area where some sections would shift around the screen if the user’s screen was too narrow or in too low of a resolution.
• Re-architected the way maps are generated. This new setup will allow us to allow users to save their maps in an upcoming release.
• Fixed an issue on Campaign Member maps if there are no Campaigns in the system.
• Other Usability, Performance & Security Enhancements

NOTE: If you are using Arrowpointe Maps and are confused by these posts about new versions, just know that these updates are happening automatically for you. You do not need to re-download the AppExchange application. Changes to the AppExchange package will be few and far between and those will be communicated very explicitly.

About Arrowpointe Maps

Arrowpointe Maps is an on-demand mapping platform that facilitates a conversation between Salesforce.com & MapQuest allowing for easy deployment of mapping capabilities in your organization and providing end-users a simple means for mapping their data. Arrowpointe Maps is configurable and can be tailored to your organization, so that your users can work with their information in a meaningful way.

The official location for information on Arrowpointe Maps is its product page at http://www.arrowpointe.com/maps. There, you will find answers to the most frequently asked questions, screencasts and links to its AppExchange page.

Salesforce.com is making security changes on Monday Nov. 26, 2007. (Note that the rollout was pushed back a week from their original communications. It is now Monday Nov. 26, 2007)

There were a couple of webinars today about the changes. The customer-focused webinar will be available at http://www.salesforce.com/security soon. The partner-focused one will be available in the Partner Portal.

Below is my understanding of what was said and a high-level overview of the main impacts. Please add clarifications in the comments.

API Logins

• If you connect via a Session ID passed from a web link/tab, none of these restrictions apply as the user is explicitly providing you with login access to his/her active session.
• To login with a username and password, the IP address you are logging in from needs to be white-listed.
• Salesforce will pre-populate the org’s whitelist with IPs used in the past 4 months.
• Each end-user can generate an API token to replace their password for API logins.
• API logins using the API token do not require their IP to be whitelisted.
• API tokens do not expire. Only 1 is active at a time. It can be replaced by the user generating a new one. This automatically invalidates the old one.
• API tokens cannot be used to login at https://www.salesforce.com/login.jsp.
• Going forward, the best practice would be for end users to provide their API token to any app/service they use other than the main Salesforce.com login page.

Logging in at https://www.salesforce.com/login.jsp

• Username and password will still be the way to access Salesforce.com from the main login page
• A new feature will be added requiring you to confirm that your computer is valid to login using that username.
• The login page will check if you’ve logged in from that computer before (by looking for a browser cookie)
• If not, the email address on the user record will be sent an email to confirm that you are, in fact, the one trying to login now.
• You will click a link in that email “activating” your computer for login with that username
• Unless you delete the cookie or clear your broswer’s cache, you should be good to go for a while without repeating these steps.
• There are no new IP restrictions affecting logins at the main login page. The profile-based IP restrictions that have been around for a long time are still the way to go there.

If you are a consultant, you may fall victim of the new security measure when you try to login as your client (maybe they couldn’t afford another temporary username just for you). On the call, I was told that you can request a temporary one via the Partner Portal or ask your customer to forward you the email to confirm your PC is okay.

My thoughts

I think it is great to see Salesforce taking a step to tighten up the API, especially. I like to think that my old API Authentication List post had something to do with it, but who knows.

The biggest impact to me will be using client’s logins to get into the system from my PC, but I’ll just have to workaround that one. Security and convenience are generally a trade off and overall I’d rather use/subscribe to a service that is tightened down with my business data. If anyone can handle the inconveniences of logging in, it’s developers since we are used to doing hacks/workarounds in the first place.

In case you don’t know about Greasemonkey

Greasemonkey is a Firefox extension that allows you to customize the way webpages look and function. Hundreds of scripts are already available for free. And if you’re the tinkerer sort, you can also write your own.

Someone created a greasemonkey script for Salesforce.com, called the “Salesforce Cold Call Mashup” (for more information). It’s the first of its kind, to my knowledge, and brings up an alternative approach to designing/distributing improvements to the Salesforce.com experience. The ability to utilize a Greasemonkey script is outside of the development tools Salesforce offers and allows you to just overlay new functionality, developed in JavaScript. It is not distributed via the AppExchange and it can be deployed on a user by user basis.

The script just released doesn’t do anything more than you could/should do within your own Salesforce environment. It looks at the Account Name on an Account page and auto-creates links to various search/news sites and puts them in a convenient location on your Account page.

I don’t think this particular script is revolutionary, but it acts as a proof of concept and brings up an interesting way to look at Salesforce development. Pros and cons (imho) of this approach:

PROS:

• Easily distributable on a user by user basis
• Can be turned on/off very easily by the end-user, putting the end-user in control of their experience
• Developed outside the Salesforce framework if that’s your preference
• You can place the output anywhere on the page. You are not limited to it being contained in a Page Layout specific location (see the image above for how they did it).
• Can apply to any Salesforce.com environment vs. needing to configure a solution within each org. Thus, it could be handy for a consultant-type / Salesforce Engineer that jumps from org to org.
• Could tidy up the Salesforce UI in places that need it prior to Salesforce doing this for us. In fact, if a motivated developer started putting out some scripts that really made a difference and gained in popularity, I bet they’d be able to influence future Salesforce.com design in a similar way to a popular idea. For example, people have been using Greasemonkey for several years to add new functionality to apps like gMail, Google Calendar, del.icio.us, Digg and countless others. The good ideas bubble to the top and have been incorporated into these apps.

CONS:

• Limited to Firefox. Most companies are not standardized on that.
• This approach could cause some renegade development and could be a risk to security and user experience within companies. Admins may not like this type of thing getting too popular as they lose control of the app.
• Developed outside the Salesforce framework, so it’s unsupported.
• Would not support the JavaScript/AJAX API to access other Salesforce data. Well, I never tried it, but can’t imagine it would. If it does, then Salesforce should plug that hole, since that would theoretically open up the door to attacks since it would only take a single, random user to open up the door into the database.

Needless to say, I won’t be recommending this approach on my client projects. Visual Force pages will definitely be the way to go for true, supported solutions.

However, I’d like to encourage the developer community to work on some scripts that would be useful to the rest of the developer community. Think of handy things that could be added to the Salesforce GUI that a developer would like to have at their fingertips regardless of the org they are in. It could be as simple as removing links, images and other HTML elements that are not useful in Salesforce (e.g. the “Brought to you by…” image on the sidebar of DE Orgs) or as fancy as anything your creative mind can think of.

Please give your thoughts / suggestions for scripts in the comments.