Yes, it’s true! You can now get 100 Free Force.com user licenses added to your existing Salesforce account.

Here’s mine as proof:

You can obtain these licenses via Force.com Checkout (at the bottom of your setup menu). See details of how to add 100 Free Force.com licenses to your account .

What’s Included?

If you study the Force.com edition chart, you’ll notice that the ‘Free’ edition:

• Excludes access to Standard Objects (eg Contact, Account, Opportunity)
• Has rules limiting access to objects (soft limitations, enforced in the license but not in the actual system)
• Can access only one App in the pull-down in the top-right (and it can’t be a Standard app)
• Has a reduced permission set

So, it’s only useful for using Custom Objects. However, that’s fantastic for replacing all those silly databases that people keep in spreadsheets or (gasp!) Access databases.

In my case, I’m hoping to use it to create some HR-type databases applicable to the whole company. It’s not worth buying everyone a CRM license, nor necessarily a Platform license, since they might only access the system once every couple of months. With these free licenses, combined with some Portal licenses, I should have something cost-effective.

So, go out and get your free licenses today!

The Bottom Line

• 100 Free Force.com licenses are available for normal Salesforce accounts
• There are restrictions on the licenses, so they’re not a replacement for CRM licenses

Phew, I figured it out!

For a while now, one of our Dashboard graphs started displaying information in “hundreds”. For example, “223″ would be rounded to “2″.

That’s fine when you’re working with thousands, but not great for hundreds.

I searched high and low for a way to fix this, and eventually found it in the Dashboard Edit Component screen — that’s the one one after you Edit the Dashboard and then Edit the individual component.

For some reason, the Auto setting decided to flip to Hundreds, so I just changed it to Whole Units.

The result… Happy users!

The Bottom Line

• Some settings can be hard to find
• You’ll probably forget to set this on initial creation of a Dashboard when there isn’t much data, so make a habit of setting it to Whole Units upon creation

I had a hearty laugh when I first saw ZohoCRM.

On first appearance, it looks a lot like Salesforce.com — they’ve copied User Interface elements such as Recent Items, object names, tabs and even the Drag & Drop Page Layouts.

All pretty good for a quarter the price of Salesforce.com.

Then, however, I started looking a bit closer and found several things missing:

• There’s no DataLoader, so you have to get your data in & out via the web interface. There is, however, an API so in theory you could write an automated loader.
• You can’t create Custom Objects (but you can add custom fields to existing objects)
• There’s nothing resembling Apex or Visualforce, so don’t even dream of customising anything (aside from Workflow rules)

I’m sure there’s a myriad other differences, but these alone mean that it won’t be used as a serious system in established businesses. While it will improve over time, so will Salesforce.com and I don’t expect it to catch up.

The Bottom Line

• It’s fine if you’re a small business or you’re managing a social club
• For anything else, don’t waste your time

Salesforce.com does a great job of handling languages and international date formats (and fairly well at currencies). But the one thing that makes me shudder is their release naming scheme which is based on seasons in the Northern Hemisphere.

For example, when is Winter ‘08? Is it the Winter at the start of 2008, or the Winter at the end of 2008? Meanwhile, it’s actually summer here in the Southern Hemisphere.

Perhaps they need to look at the world differently:

The only problem is… I can’t think of anything better. Can you?

The Bottom Line

• Seasons aren’t a great naming convention
• Global warming may provide a solution

Dreamforce 2008, the annual Salesforce.com conference, is on again in November 2008 in San Francisco.

I have not yet attended a Dreamforce but I do love presenting, so I’ve submitted an Idea for a presentation entitled Case Study: Automating Integration with the Data Loader. It’ll be a chance to pass on my learnings from my Salesforce.com implementation at Atlassian.

Want to help my chance at stardom? Then please vote for my idea — just click the Promote button on the topic page. You’ll need to login with the Salesforce ID that you use to use a normal Salesforce.com or Developer account. C’mon — it’ll raise the profile of Australians at Dreamforce, too!

The Bottom Line

• Vote early, vote often!

Okay, this post isn’t quite about Salesforce.com today, but I think it’s a tidbit worth publishing…

I learned something about SQL today!

I love SQL — It’s the only programming language that I learnt back in my University days that is still useful. (Remember Pascal? Ha!) I especially love PostgreSQL. I did some neat procedural stuff with it earlier this year that was especially pleasing.

Anyway, today we were burdened with an overly complex query doing funky stuff with sales data. We were trying to join together two sets of data using the good old UNION statement. Result set A had 20 rows and result set B had 24 rows. When combined with UNION, the result had… not 44 rows, but 24 rows! This was a real head-scratcher until I found this in the PostgreSQL manual:

UNION effectively appends the result of query2 to the result of query1 (although there is no guarantee that this is the order in which the rows are actually returned). Furthermore, it eliminates duplicate rows from its result, in the same way as DISTINCT, unless UNION ALL is used.

The kicker is that last sentence — duplicate rows are removed unless UNION ALL is used. Sure enough, we stuck in that ALL word and everything was fine.

The Bottom Line

• You learn something every year
• PostgreSQL rocks!