External Sharing Model – Pilot

An interesting addition to the Summer ’12 release is the pilot of separate OWD settings on custom objects for external users. For example, a custom object may have public read-write sharing for internal users and private sharing for external users. In many cases this will simplify the sharing model significantly as the rules below have historically applied to all users including portal users and guest users.

Is there a user who can’t see all records == private
Is there a user who can’t edit all records == public read-only
else == public read-write

Applying the above OWD rules across internal and external users typically results in an overly private model for internal users and a resultant proliferation of performance-expensive sharing rules. The new separation of concerns here is a great improvement for custom objects, but not standard objects (hopefully this is on the roadmap).

Seemingly simple, yet powerful functional enhancements such as this that reduce the amount of custom configuration applied to an org are to be applauded.

Summer ’12 Lookup Relationships

The Summer ’12 release introduces some fundamental changes to the functionality of lookup relationships. In summary:

1. Optionality. Lookup relationships can now be set as mandatory (Required Attribute). This is great news in that the usual validation rule enforcement can now be forgotten.

2. Referential integrity. Prior to Summer ’12, the parent record could be deleted without regard to related child records, which would have their lookup fields nulled. This remains the default behaviour. You can however specify one of the following behaviours in the optional case, for mandatory lookups only 2 and 3 are possible. I’m using the terms parent and child here in the loosest sense for convenience, the nature of the relationship is associative.

2.1 Clear the child field value – default
2.2 Prevent the parent being deleted (Don’t allow deletion of the lookup record that’s part of a lookup relationship)
2.3 Cascade delete (Delete this record also) – This one requires activation via salesforce support, and ignores the sharing model, meaning if a user has record access to the parent, they can delete it and related children without requiring permissions at the child level. This option is restricted to cases where the child is a custom object.

The above enhancements to the lookup relationship type start to blur the lines between lookup and master-detail, however the key differentiation remains in terms of ownership versus association.

Reflection in Apex

For experienced developers, the lack of reflection capabilities in the Apex language can be a limitation in the type of patterns that can be ported from other languages (Java, C# etc.). With Summer 12, the Type class now supports the newInstance method, enabling instantiation via the class name as a string. Sounds simple, but this method opens the door to a number of typical reflection use cases. Excellent news.

This developer force post provides an excellent intro.