Facebook
Salesforce
Chatter and the CLM
I love Chatter. I love the way that it is a game-changer. I think that Chatter is a powerful tool. But as Peter Parker's Uncle Ben said, "With great power comes great responsibility," and with the possibility of great rewards from Chatter comes great risks.
First I'll list my conclusions, just so there's no misunderstanding. Then I'll explain some of the possible pitfalls that Chatter presents.
- Chatter is amazing. It lets users share information in ways never seen before.
- Chatter should be enabled in an org as an all-or-nothing switch - as it is now. Allowing it to be disabled for some users goes against its core purpose.
- As a single-opt-in system, the risk of Chatter-Spam is huge, but responsibility falls to each user to self-police, and probably to each company to educate its users in appropriate chatting.
Let's compare Chatter, Facebook, and Twitter in terms of what is necessary for a conversation between two people to appear in my activity stream.
Facebook is a double-double opt-in system. To see a wall post from one person to another in my stream, I must be friends with both of them, and each friendship-connection is a double opt-in, meaning that one person requests and the other approves.
Twitter is a double-single opt-in system. To see one person's reply to another, I must be following both of them. But unless one of them decides to block me, the default is that I will see the entire exchange in my twitter feed.
Chatter
Chatter is a single-single opt-in system. This means that if I post something to anyone in the org, everyone following that person will see. Here's an example: Let's assume that every user at salesforce.com follows Marc Benioff. One user posts a photo of his son's graduation to Marc. Everyone following Marc will see it.
Sounds innocuous, right? Probably. But if a user keeps posting silly things to Marc, and enough people see it, other users could become annoyed.
Take it down a level, and imagine that everyone on a sales team follows each other. A junior AE keeps sending silly stuff to the strongest seller in the group, and all the sales people have to see it. This could clog their streams.
This is called a CLM: A Career-Limiting Move. As great power requires great responsibility, we must ask who should shoulder this responsibility.
- The company: Training for users and a quick eye to bring inappropriate chatters into line.
- Individuals: Just be careful. This is the Facebook public-posting dilemma. Don't forget that you have no control with whom you are connected, so anyone who wants to follow you will see anything you post, and anyone who follows someone you post to will see it as well.
The solution is NOT to turn off Chatter for certain people - Chatter is about the free-flow of data across an org, organized into forms that make it useful information. By putting information at the fingertips of every user, productivity will be increased.
Blocking people is also not a good solution.
Chatter Groups (Safe Harbor Statement!) will help, but will attenuate, not completely remove, the chances that this will happen.
Salesforce CRM should be a "sticky" app - that is, it should provide services in one place so that users see it as their central point of information. The best way to ensure the free-flow of information is to prevent blocking of certain users.
New Opportunity Page Layout – With Highlights Panel!
Yesterday, I enabled the new Opportunity page layout in my Developer Spring ’10 Preview org, and it took a few steps, so I thought I’d share them with you.
Firstly, you’ll need to contact salesforce.com to get this feature enabled.
Then be patient. It takes a minute or two for the update to propagate. Clearly, something was churning in the Force.com platform background!
Now we’ll navigate NOT to the Setup | Customize | User Interface screen (where this should be enabled). Instead, we’ll go to the Opportunity Page Layout screen.
Follow the cool prompts. They make it so easy, a … well, you know what I mean.
Step 1: Enable the Highlights Panel
Opportunity Layout Setup
Step 2: Edit the Page Layout
Choose Fields to Display
Note: You can only show fields in the Highlights Panel if they are in the page layout. (I have a feeling this has to do with Professional Edition or printable layouts, but I’m just guessing.)
Once you’ve done this for each page layout, click on the big button.
Confirmation - You are (mostly) done!
At this point, each user can enable the bar. I have no idea why the admin can’t just force this on all users – or maybe I missed something – but it seems to be an opt-in feature.
Step 3: Enable User Opt-In
Here’s the link to enable the feature. Of course, you may wish to watch a video as well!
The link to enable this setting
And here it is!
The new layout!
Return to top from the bottom of the page
It’s interesting that if you have this enabled, certain user interface settings (yes, at Setup | Customize | User Interface) cannot be changed:
When this is enabled, you cannot turn off two settings
Here’s my prediction: We will start to see two major mistakes during Salesforce demos:
- We will continue to see the link asking if we want more information on inline editing (after more than a year, it’s time to turn that off, people).
- At the top of the Opportunity detail page, we will see this link.
And I will continue to think less of all demonstrators who make these mistakes.
Happy Spring 2010!
New Developer Library Released
Today, Developer Force (http://developer.force.com) released its new library. Here are a few of them. All can be found at http://wiki.developerforce.com/index.php/Documentation.
Workbook
http://www.salesforce.com/us/developer/docs/workbook/index.htm
Fundamentals
http://www.salesforce.com/us/developer/docs/fundamentals/index.htm
Cookbook
http://www.salesforce.com/us/developer/docs/cookbook/index.htm
Apex Advanced Code Example
http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_shopping_cart_example.htm
https://sites.secure.force.com/appexchange/listingDetail?listingId=a0N30000001saDCEAY
And many more to come!
Filtered Lookups, Validation Rules, and Order of Execution
Reading the cheatsheet for Filtered Lookup (beta), I noticed an interesting line:
Lookup filters function similarly to validation rules when you save a record. That is, actions that cause related records to save, such as changes to a roll-up summary fields, also trigger the lookup filters on the related record and block the save.
The implications for this are massive. Let's explore two examples:
Example 1: Filter as Validation Rule from Parent Record
- We create a lookup on a Child object to Parent.
- We filter the lookup to EXCLUDE Parent.Status = 'Closed' (Parent.Status is only Open or Closed.)
- We can edit the Child records as long as the Parent Status is not Closed.
- When Parent.Status is changed to Closed, existing related Child records are not affected...
- BUT if we attempt to edit a Child when the Parent is Closed, Force.com will throw an error (which we can customize) beause that the Lookup is invalid.
- (and clearly we cannot add new Child records either)
Conclusion: Thus, Filtered Lookups act much like Validation Rules. A quick experiment shows that Filtered Lookup errors actually fire before Validation Rules.
Example 2: Filter as Validation Rule on Roll-Up Summary (from Child Record) - what the line above was referencing
- Use the above example, but change the lookup to a master-detail relationship
- Create a Roll-Up Summary field to count all child records
- Prevent saving more than 10 child records for one parent record
Here, we have triggered a filter error without touching a parent record, yet we throw an error based on a value on the parent record.
This second example is significant because we could already prevent more than 10 child records from saving, but doing so required a Roll-Up Summary field on the parent object AND a Validation Rule on the child object. Now we can replace the Validation Rule with the Lookup Filter, though we still need the Roll-Up Summary field. Whether or not this simplifies things is definitely up for debate...
Conclusion
This is a very powerful feature! Thanks to salesforce.com for rolling it out, even in beta form.
Real world example: The above example would be great for Time Sheet Entry and Time Sheet Header objects, as they would create, in effect, a validation rule on the Header record preventing editing of any child records. Awesome!
For further reading, check Salesforce Help's Lookup Filters examples.
Dashboards are Improved AND New in Summer 09
The Summer09 prerelease orgs are here, so get yours now! Upon first look, something cool stood out and merits immediate posting:
Dashboards are improved. The colors are more vivid, there’s detail in the bars and pie chart wedges, and… pie charts can now display the actual and percentage values!
Dashboards are also new. Visualforce pages can now be included as dashboard components, and there’s a new “Color-Blind Palette on Charts” setting for each user. Here are before and after shots.
Salesforce dashboard with regular color scheme
Dashboard with color-blind/alternate color scheme
