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.
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.
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.
Here’s the link to enable the feature. Of course, you may wish to watch a video as well!
And here it is!
It’s interesting that if you have this enabled, certain user interface settings (yes, at Setup | Customize | User Interface) cannot be changed:
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.
Developer Preview Releases for the Google Visualization API
Dreamforce 2008 brought many exciting new features from salesforce.com, both on the CRM/front-end side and the Force.com platform/back-end side. One of the favorites was the announcement that salesforce.com had released a Google Visualization code share project. Google has invited developers to participate in Developer Preview Releases for the Visualization API.
It looks like a pretty cool way to work on RESTful integrations while making some pretty pictures for your users.
For those unfamiliar with the Salesforce/Google Visualization toolkit, developer.force.com has a great introduction.
















