Audit9 Blog

The Winter 13 release (v26.0 in API terms) will be with us shortly, yes the summer is officially over. Sandboxes updates start on the 7th September. For architects and developers this release brings some great new features, the Top 10 below is in order of my own personal interest.

1. Canvas Framework – Pilot. The Canvas framework provides a means to stitch external applications into the Salesforce UI with a much greater degree of control and depth of integration than through mashups via frames. Authentication and cross-domain issues are handled by the Canvas SDK. This topic is massive and I’ll come back to this in more depth in a future post. For now it’s sufficient to understand the potential, which is deep integration of off-platform apps – namely those built on Heroku.

Canvas Framework Developers Guide (html) is here

2. Testing Apex Callouts. Writing test code for functionality which invokes callouts has historically been a problem, in short the test context proceeds to make the callout which is prohibited so it fails the test. Great. The answer has typically been the application of a pattern where the execute and response processing code are separated into virtual methods, the callout class is subclassed, with the subclass overriding the virtuals (which don’t make the callout and return prefabricated responses) – the test code instantiates the subclass not the base class etc.. With Winter 13, this behaviour is nicely tidied up using the HttpCalloutMock interface and the Test.setMock() method. Responses can be dynamically generated or loaded from static resources, in the latter cases endpoint specific responses can be mapped from multiple static resources. This is number 2 on my list as this is a real-world problem given a comprehensive platform solution.

3. Test Data from Static Resources. The new Test.loadData(‘sobject’, ‘resource’) method does what it says, and will be extremely useful in creating richer data sets for unit testing. The typical for..loop creating Account 1..200 etc. can now be replaced with the loading of a file of better quality test data, which should be helpful in identifying code issues sometimes encountered only when code runs against real data. Note, ideally this method of test data creation should run outside of the governor limits applied to the test execution context, thereby enabling larger data sets to be created. I’m certain this isn’t the case, but I’d be very happy to be corrected..

4. Visualforce Charting. Now GA with additional chart types. I really like the ability to add charts into Visualforce pages without round-tripping data to external sources such as Google Charts, or embedding flash objects (although fun to write). Easy to use and flexible components.

5. Geolocation Custom Field – Beta. In an increasingly location-aware world, storing geolocation data and supporting proximity calculations is imperative to many mobile use cases. The beta introduction of a custom field type for geolocaton data looks interesting but requires special consideration in terms of support across the Salesforce platform.

6. Developer Console Enhancements. Now with added test execution and query editor. I’ll drill into the new Developer Console in a future blog post – for now it’s good news that the previous investments in the console are being extended – not sure the potential of the console is fully exploited by platform developers as yet.

7. Custom Object Truncation. No more bulk deletions of test data. Instead custom objects can be truncated – an unlogged operation which efficiently flushes all records from the object – a common practice with traditional RDBMS.

8. SOQL Polymorphism – Developer Preview. The new TYPE OF expression enables a different select clause based on the actual type of polymorphic field, i.e. if the Who field is actually a Lead, then select one set of fields, if its a Contact select another.

9. Salesforce Touch – Beta. Limited to Apple iPad and still at beta status, however Touch really does deliver a great user-experience. With Winter 13 a hybrid app can be downloaded from the App Store – delivery convenience and a persistent session. At some point the app will presumably provide local on-device data and functional integration – beyond what can be achieved within the browser.

10. Environment Hub – Pilot. Down at 10 simply because the feature is pilot only with Winter 13. Basically, the Environment Hub will provide a centralised view of all orgs in use – with auto-detect of sandboxes and a basic tagging model. In a world where multi-org strategies are commonplace and development projects are rapidly evolving toward complex environment configurations – this new feature will help understand the scale and state of the org estate.

Note the full Winter 13 release notes are available right here

On occasion I come across platform behaviour that simply doesn’t make sense. A recent case in point being a v25.0 VF bug where bottom buttons in a pageBlock component ignore the edit and show button directives related to inline editing. In such cases I find it useful to check the Known Issues List in addition to the usual developer forums on developer.force.com. An obvious reference, but infrequently used in my experience.

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.

This post is the second in a series exploring record access considerations with the different portal user license types. This post covers the Customer Portal Enterprise Admin type.

By way of reminder, the decision tree below should be used when making the high-level decision on the appropriate license type for the different user populations within your portal.

Customer Portal Enterprise Admin
The Customer Portal Enterprise Admin (CPEA) user license type relates to the Customer Portal Manager Custom license type (as displayed within Salesforce). Note, the Customer Portal Manager Standard license type is obsolete in the sense that it is not available to new customers. The CPEA user license provides coverage for use cases such as B2B empowerment to manage portal users (Delegated Portal User Admin), extended standard object permissions and non-trivial record access requirements (beyond those applicable to HVPU).

CRUD permissions :
Create, Read and Update on Account, Asset, Case, Contact
All on Custom Objects
Create and Read on Idea
Read on Article, Price Book, Product, Solution, Answers (Question, Reply)

Default record access :
CPEA users are placed in the role hierarchy as below, as descendant roles of the Account Owner’s role.

So for each account where a CPEA user is activated (Acme in the case above), a set of 3 roles is created under whichever role the account owner has allocated. Executive users can view manager owned records and so on. The number of roles created can be set between 1 to 3, giving control over user sharing granularity versus proliferation of user roles (and consequential impact on performance).

Sharing options :
Role-based and criteria-based (CBS) sharing rules, manual sharing, Apex Sharing, Apex Managed Sharing.
Case teams.
Can have the “Super User” permission – this provides Read and Update on cases submitted by all users related to the same account (includes case comments and attachments).

Other considerations :
The CPEA user license is significantly more expensive than the HVPU license types – for good reason, and should be used only when the additional functionality is necessary – perhaps in a complementary model. It always makes sense to perform a full upfront analysis of the access model requirements for a portal solution – retrospectively addressing functional issues incurred through the wrong license type selection can be costly and entail inelegant design compromise.

Note. This page on the Salesforce help site provides an excellent reference for further information.

Interesting new book covering advanced Apex topics such as execution context, asynchronous programming, robust design patterns and so on.. Excellent addition to the Force.com Developer’s arsenal!

Advanced Apex Programming – Author: Dan Appleman
Table of Contents

Update (2012-09-10)
I now have my hands on this book and have to say I’m really impressed. So often I work on projects where the principles of Thinking in Apex have been overlooked and basic mistakes made – now there’s an alternative to having to infer the right mindset to bring to Force.com development from the technical documentation. Well documented design patterns that address real world concerns can only help raise the quality bar.

When designing portal solutions on the Force.com platform it is imperative to understand the sharing model implications of the user licenses and related base user profiles in play. In this post I’ll outline the key considerations in respect to record access for high-volume portal user license types; Authenticated Sites (aka Platform Portal) and Service Cloud Portal. In both cases users do not have roles and can’t be added to teams, groups or sharing rules. So how do you provide record access?

Note, this topic (and complex sharing models in general) is fundamental to understand if you’re considering the Salesforce Certified Technical Architect certification.

So to start with, the decision tree below should be used when making the high-level decision on the appropriate license type for the different user populations within your portal.

The following items examine each of the HVPU license types in turn with a view to clarifying how record access is achieved and the constraints to consider.

Applicable to all user license types are the following record access rules, which should be considered carefully if a public sharing model is in place and a portal is added:
Read on all records where the object org-wide default is public read-only
Read-write on all records where the object org-wide default is public read-write

HVPU License Types:

Authenticated Sites
The Authenticated Sites, or Platform Portal User, license is intended for high-volume scenarios (up to millions of users) where access to Standard Objects is not necessary and record access requirements are simplistic.

CRUD permissions :
Read on Document, Price Book, Product, Account, Asset
Read and Create on Idea
Full access to Custom Objects

Default record access :
Custom object records owned by the user
Read on Account related to the portal user
Read and Update on Contact related to the portal user
Master records where the user has access to the detail record and vice-versa

Sharing options :
Sharing Sets – provides sharing to records (account, case or custom object) related to the portal user’s contact or parent account (via lookup field). Access level can be read-only or read-write but can’t be more restrictive than the OWD for the object. Sharing Sets are at the user profile level, not per-portal and each user profile can be associated with only one sharing set. For example – you can provide write access to the portal users related account via a sharing set, or provide full access to all custom object records in a private OWD object which are related to the same account as the portal user.

Other considerations :
A Share Group defined at the portal level provides access to records owned by HVPU to other users, via Public Group, Role, Role and Subordinates and Users.

Use case :
A reasonable exemplar use case for this license type would be event attendees registering for an event within an event management portal. In such a case the attendee may need to login after registration to provide further details, make payment, book a session etc. The attendee needs access to their own records held in custom objects and update permission on their Contact record. The attendee may also require visibility as to who else from their company is attending. Basically this license type is for external user Force.com solutions underpinned by custom objects.

Service Cloud Portal
Relates to the High Volume Customer Portal User License and is intended for high-volume scenarios (up to millions of users) where access to Standard Objects (cases etc.) is a definite requirement but record access requirements are simplistic.

CRUD permissions :
Read and Update on Account
Create and Read and Update on Asset, Contact, Case
Read on Document, Price Book, Product
Create and Read on Idea
Full access to Custom Objects

Default record access :
Records owned by the user
Read and Update on Account and Contact related to the portal user
Master records where the user has access to the detail record and vice versa.

Sharing options :
Sharing Sets – see above.

Other considerations :
Share Groups – see above.

Use case :
The typical use case for Service Cloud Portal licensing is mass B2C self-service support scenarios – offering case logging, idea creation etc.

In the next post I’ll extend coverage to the Customer Portal Enterprise Admin and Partner Portal license types.

Note. This page on the Salesforce help site provides an excellent reference for further information.

In certain cases it may be desirable to have some users authenticate in the standard Salesforce manner, whilst another user population authenticates via single sign-on (SSO). This mixed authentication scheme scenario may result from rollouts to new departments etc. What are the considerations?

The first concern is whether Delegated or Federated Authentication will be used for the SSO population.

With Delegated Authentication (DA), a mixed scheme is straightforward as the SSO configuration is applied through a User Profile setting, enabling a subset of users to have their authentication request routed to the DA on-premise authentication web service. The remaining users will simply login in the standard Salesforce manner.

With Federated Authentication (FA) via SAML 2.0, a mixed scheme is not so trivial. There is no User Profile setting or indeed any user-level setting controlling whether a user is SSO-enabled or not. Instead SSO is inferred from the manner by which the authentication is approached. If the user accesses https://login.salesforce.com and attempts to sign-in they will be authenticated as a Salesforce user, no SSO. With the identity provider initiated SAML flow, the user is handed-across from the IdP in a pseudo-authenticated state, if the service provider (i.e. Salesforce) can validate the SAML assertion and map the user to an active Salesforce user (via username or Federation Id) then authentication takes place. So the IdP initiated flow poses no problems in a mixed scheme, standard Salesforce users authenticate as normal, SSO users authenticate via the IdP (intranet link etc.).

So far so good. But what if the client also needs to support the service provider initiated SAML flow in a mixed scheme? Perhaps Chatter Desktop or Mobile is being rolled out.

The service provider initiated flow requires a My Domain to be configured in the Salesforce org e.g. https://force365.my.salesforce.com, this enables anonymous authentication attempts using the My Domain to be mapped to the correct SSO configuration and routed to the IdP. Which works perfectly for SAML enabled clients and deep-links. For the standard users in the org we now have a problem – all unauthenticated references to resources based on the My Domain will take the user to the IdP to authenticate. So sharing of links via email etc. will require the standard user to have pre-existing session, otherwise they will be presented with an unfamiliar login challenge (Active Directory Forms Authentication perhaps) or worse a login failure in the integrated case. In theory this could be resolved by ensuring the standard users are correctly configured for authentication both at the IdP and Salesforce, enabling SSO authentication to occur where required.