Salesforce Summer 15 Platform Highlights

Once again a new release is almost upon us – this time it’s Summer ’15 with its suitably summery ice cream van logo. The rollout starts on May 8th for sandbox instances, followed by NA production instances on May 22nd. EU instances will be upgraded on June 13th. If you can’t wait until then, Summer ’15 pre-release access is available via this link.

The preview Summer ’15 Release Notes can be found here. Note, to keep up-to-date with updates to the release notes follow @salesforcedocs

This post briefly outlines selected highlights related to the platform (in no order of significance).

– features are GA if not indicated otherwise

Data Loader for Mac
At long last there is now a supported data loader for the Mac. This is great news for longtime lexiloader users. The new data loader is accessible from the setup menu – see below. Note, the CLI/batch mode is only supported on the Windows platform.

Data Loader for Mac

Lightning App Builder
Now GA the Lighting App Builder enables the point-and-click definition of custom app pages for Salesforce1. The development model is declarative application composition using standard, custom or third-party components developed using the Lighting Component Framework (Aura).

Lightning App Builder - Setup

Lightning App Builder 1

Lightning App Builder 2

Lightning App Builder 3

Lightning App Builder 4

Omni-channel is a service cloud capability that creates abstract work items from inbound support requests, regardless of channel, and provides intelligent workload management and real-time intelligent routing of work items, including routing back to agents who have previously handled work items for the same customer. This latter point being the highlighted distinction from multi-channel. This functional area looks immense and complex, but very interesting in scenarios where resource management requirements go beyond the the standard capabilities of queues/assignment rules etc.

BigObjects (Pilot)
An interesting new capability for storing large scale datasets on-platform and fully integrated with standard data via relationship fields, SOQL and API access. BigObjects are defined via the metadata API and loaded via API only. The data remains read-only. The absence of a setup UI for this new feature is indicative of an early stage pilot, as is the specific set of use cases targeted for the pilot programme (Customer360, Data Archive, Data Lake, Email Event Ingest).

The release notes make reference to a “BigObject Implementation Guide” which doesn’t appear to be available quite yet. It will be interesting to understand more about the limitations of this feature and cost, and also the impact on exiting platform limits (for example, the SOQL Query Row governor limit).

Chatter – Feed Post and Comment Editing
Editing can now be enabled for standard Salesforce users via permissions. Free, external, partner community and HVCP users are excluded from this new functionality. The edited post or comment is marked to indicate when the edit took place. Note, where @mentions are used, only newly added users are notified following the edit, not users mentiond originally.

Chatter Post Edit

Receive Debug Logs Predictably
Historically it has been difficult to comprehend the factors that influence the log level applied to debug log output. This can be a real pain point for developers especially where the debug log becomes truncated, but a seemingly restrictive setting has been applied yet ignored. Summer 15 applies a clear and predictable precedence logic to log levels, with the Developer Console trace flags first in this predictable order of precedence.

Apex:New Code Coverage Calculation for Multiline Statements
Prior to v34.0 multi-line statements were counted as 1 line, now the count accurately reflects the number of lines in the statement. The impact of this calculation change could be an increase in coverage or a decrease. The latter arising from scenarios where subsequent conditions in the multiple line statement aren’t evaluated. Expect to see a reasonable degree of variation in the coverage % in any class where multiple line statements exist.

ISV Package Streamlining
The list of components that can be deleted from a managed package in release state is extended to cover Custom Settings and Permission Sets. Anyone involved in ISV development will appreciate this increasing capability to remove obsolete components from existing packages.

Platform Encryption
Where data protection/compliance requirements must be addressed, Summer 15 provides a new data encryption layer that ensures data is high-strength (256-bit AES) encrypted at rest. This new capability applies to files (attachments etc.), standard fields and custom fields and supports multiple text-derivative field types, search and the declarative features of the platform. This differs greatly from the classic field encryption mechanism which supported a specific text field type only and could not be searched or referenced in workflow/approvals etc.. Note the new Platform Encryption capability incurs an additional cost.

Spring ’15 Chatter Features

In advance of taking the Spring ’15 certification maintenance exams I’ve been reading the release notes one more time, with a focus on the broader picture, not just the platform elements and headline features that catch the eye during the pre-release phase. I tend to follow this regimen for every release and inevitably the detail of a number of smaller features/announcements are picked up that were simply skimmed on the first review, or indeed added to a later version of the release notes – this happens (so always check you have the latest version). In regard to Spring ’15 the low-key features of interest relate to Chatter and are covered briefly below.

1. Add Records to Chatter Groups
With this feature it’s possible to relate arbitrary records to a Chatter Group via the “Add Record” publisher action on the Group Layout (this needs to be configured). The utility of this feature appears to be twofold; convenience and communication. For example, if we have a collaboration group for a sales campaign, we can now list the targeted account records on the group page and access via a convenient link. It would seem that the relationship is one-way, it doesn’t appear possible to view the groups to which a record is related from the record detail page. Note, feed posts at the record level are not shared with the group.

Group Records 1

Group Records 2

2. Question-to-Case (GA)
Chatter Questions is a great collaboration feature in its own right, enabling expertise across the internal or external community to be brought to bear on posts structured as questions, with specific functions for answers, mark-as-best etc. As the name implies Question-to-Case allows a question to be escalated to a case from within the feed, with the feed post marked visibly as such.




A further extension to this feature, Knowledge Deflection for Chatter Questions is currently in beta. The functionality of this should be evident.

3. Action Links (GA)
Buttons can be added to feed posts that download a file, access a web page or call a 3rd party API. Action links can be grouped within an Action Link Template and packaged for ISV distribution. Action links are functionally very interesting, given the use cases they open-up, however the implementation is non-trivial and warrants a follow-up post.

It’s interesting to see how the Chatter product continues to evolve release-on-release. The direction the product is taking appears sensible, i.e. finer grained control via increased Trigger coverage (custom moderation etc.), richer content previews and extended external integration capability. Top of my wish list incidentally would be an enhancement to Topics to allow post activity from associated records (Topics for Objects) to be automatically shared and pushed out to topic followers via digests. This could be an optional flag that marks the topic as aggregating. With this model, users can simply follow a topic and have content pushed to them proactively that is either directly related (feed post association) or indirectly (feed post against an associated record). Such a feature would really help transition many notification use cases from email/task to Chatter.

Salesforce Manager Groups

A fit-for-purpose sharing architecture is one of the fundamental elements that underpin a secure and performant Salesforce implementation. The sharing architecture defines the record-level visibility model and should be subject to periodic review and refinement to reflect shifting organisational factors. The most efficient sharing models make full use of implicit sharing via the Role Hierarchy, with minimal use of explicit techniques such as Sharing Rules. An implicit model is reliant on a well conceived Role Hierarchy that reflects data access across the organisation, and is therefore not necessarily aligned directly to the organisational structure. This is hard to achieve and requires an approach of continual adjustment throughout an implementation project and beyond. The benefits of this approach are manyfold; control, reporting, maintainability and performance being just examples. In regard to control, implicit access provides the record-owner level of access, which can’t be achieved via explicit means. With reporting, the dynamic filters “My Team’s Accounts” etc. are based on the Role Hierarchy, i.e. users in roles below the current users’ role etc. in addition with some reports the Role Hierarchy can be used to filter the output at runtime. In regard to maintainability, the proliferation of sharing rules often introduced to compensate for a substandard Role Hierarchy design is avoided. Finally, in the performance case, although sharing data (AccountShare etc.) is persisted at the time of configuration, and not calculated fully at the time of record access, there is still a performance consideration with complex sharing models. So in short, a sharing model that is predominantly implicit is better than an explicit model. Irrespective of whichever model is implemented, a comprehensive understanding of the explicit techniques and their primary use cases is important to ensure the sharing model is appropriately secure and maintainable.

For the first time in a number of releases, the Spring ’15 release introduces a new sharing model feature “Manager Groups”. This feature extends the capability of explicit sharing techniques (Manual Share, Sharing Rule and Apex Managed Sharing) enabling direct use of the management hierarchy, as defined by the Manager field on the user record. Manager Groups are system defined, per-user, and can be utilised in the same way Public Groups are used in the same contexts. For each user 2 Manager Groups are provided; “Managers Group” – immediate managers and their manager and so on (up the management hierarchy) and “Manager Subordinates Group” – the user’s direct reports and their reports and so on (down the management hierarchy). Unlike Role Hierarchy based sharing, Manager Groups share directly to each user in the hierarchy chain, not all users with the parent role.

Note, the Manager Groups feature was initially introduced in the Winter ’14 release and made available upon request. Spring ’15 makes the feature automatically available in all orgs.

Prior to the introduction of Manager Groups, sharing based on the management hierarchy relied upon the Role Hierarchy reflecting the management hierarchy, or elaborate explicit means. The Manager Groups feature now provides an efficient means to share data up and down the management hierarchy, leaving the Role Hierarchy to strongly model the data access requirements for the organisation.

Enable via Sharing Settings page

Manager Group Sharing - Settings

Manual Share

Manager Group Sharing - Manual Share

Sharing Rule Definition

Manager Group Sharing - Sharing Rule

Sharing Records with Manager Groups
A Guide to Sharing Architecture
Designing Record Access for Enterprise Scale
Record-Level Access: Under the Hood

Implementation Guiding Principles

In most cases software implementation projects start off with a clear vision of the various macro-level influences, constraints and directives that define the shape of the project at the outset. During the initiation stage the clear, consensus view on the project principles influences fully the micro-level decisions taken in terms of architecture, solution design, resourcing, scope, prioritisation, schedule and so on. The challenge for many projects is maintaining the purity of the vision across the course of the project in light of variations in uncontrollable factors such as the business context, risks becoming reality, project resources and so forth.

An effective tool to mitigate this loss of identity and direction, and the consequential impact this can have on confidence and productivity, is the definition of an unambiguous, concise set of guiding principles that are communicated early and frequently. Additional to the benefits related to a clear and strongly defined direction, principles support increased productivity through empowerment; if low level decisions align with the principles then action can be taken without time-expensive consultation.

Corporates do this, why not projects?
This approach is well established in business, with many corporates defining an aspirational, future state vision and set of guiding principles that underpin the delivery of the vision through applied influence to all activities undertaken and decisions made. Guiding principles can be very effective particularly where a culture is established that prioritises all actions taken in relation to their conformance to the principles. This level of application requires absolute confidence across the business that the principles are current, meaningful, complete and beneficial to all parties. The value of this approach at a business level can apply equally to a project.

Key Points
No more than 7. The primary value of guiding principles is the strength of the message, achieved through brevity. Telephone numbers were originally set at 7 digits as this was believed to be the most people could be expected to remember. 7 therefore seems a reasonable limit in this context.

Revisit during retrospectives. Stale principles will damage the integrity of the approach. Agility should be paramount such that principles are current and enable changes in the direction of travel whilst the project is in flight (excuse the metaphors here).

Communicate frequently. All project artefact (slides, documents etc.) should state the guiding principles and relate the content to the relevant principles, noting deviations.

All design decisions should relate to one or more principles. See above point.

Prioritisation. A simple prioritisation scheme (high, medium, low; 1,2,3 .. n) can be effective in resolving conflicts between principles.

Buy in. All project stakeholders must approve the principles and accept the impact. Without complete buy in the integrity of the approach is diminished.

Principles can be goals. Principles are often directive in nature, goals are an interesting extension to this.

Use The Goals functionality of can provide a useful tool to manage, communicate, collaborate and report on the principles. This functionality also enables user-level goals to be mapped to the higher level goals.

Vision statements can be difficult to articulate, particularly where there are multiple unconnected concerns.

Project charters can be too cumbersome to be a realistic communication tool. It’s human nature to read once and subsequently ignore any project documentation that requires a time investment.

In both cases above, guiding principles can provide a complementary abbreviated formatting.

Maintainability of the solution by client administrator.

Future extensibility without technical resource.

Sales productivity improvement is the key objective.

Declarative build over technical solution options.

Quality over expediency.

Technical excellence.

Buy over build.

Alpha 1 bug count must be less than 100.

The solution will be productised internationally.

The project delivery date must be achieved.

Release early and iterate.

Business utility to be delivered every 2 weeks.

Only user-accepted features to be released.

User stories estimated at 5 days or more to be split.

Salesforce Spring 15 Platform Highlights

With Christmas a distant memory (well almost) it’s time to turn our attention to the next big event on the calendar, and no not New Year, I mean the Spring ’15 release of course.

The key dates for the Spring ’15 release are outlined here, the detailed rollout schedule can be found in the usual place.

The preview Spring ’15 Release Notes are here. Note, to keep up-to-date with updates to the release notes follow @salesforcedocs

This post outlines selected highlights related to the platform (in no order of significance).

– features are GA if not indicated otherwise

Salesforce1 Reporting Notifications
On the “Report Run” page a Subscribe button now appears that enables end users to subscribe to notifications relating to the metrics provided by the report, i.e. KPI1 greater than 100, send an email etc. Notifications can be scheduled in a flexible, recurring manner with the resultant action set to a Salesforce1 Notification (via the mobile app), Chatter post, email notification or Custom Action. In the latter case an Apex Class can be introduced which implements the Reports.NotificationAction interface.

public class myReportAction implements Reports.NotificationAction {
    public void execute(Reports.NotificationActionContext ctx){
        // perform action.

The class above appears as an option for the “Execute a Custom Action” selection on the “Subscribe to..” page.

Report Subscribe

@testSetup Method Annotation
Test setup methods create test data for the test class as a whole. Annotated methods are executed first during test execution to create the test records – each constituent test method gets access to the same original set of records regardless of the DML operations of preceding test methods. This approach removes the test data creation and rollback operations from individual test methods, thereby reducing test execution time and removing the consumption of governor limits within test methods due to test data creation.

Standard address fields now support inline map presentation. This is configurable and limited to Google as a map service provider.

Mapping - Standard Address Field

New Visualforce mapping components (apex:) make use of this capability to enable the simple addition of interactive JavaScript maps to Visualforce pages.

Lightning Process Builder
The Lightning Process Builder is unavailable during the pre-release programme, however the product will be GA on release. My general interpretation of the positioning of the 3 platform workflow capabilities is provided below for information only.

– Workflow: single-object centric collection of ungrouped rules and actions, auto-invoked via data modifications.
– Visual Workflow ( Flow): multiple-object business process orchestration involving user interface elements for data capture and manual-invocation of logic*.
– Lightning Process Builder: single-object centric, visual composition of multi-step processes, auto-invoked via data modifications. Records can be created and cross-object updates applied to any related records not just the parent in a master-detail relationship.

(* I’m ignoring Flow Trigger Workflow Actions here; the pilot for which has been superseded by Lightning Process Builder.)

Note, there are differences between the beta version of Process Builder and the GA release. For example, Apex code can now be called directly from a Process, and Processes can be versioned for change tracking purposes (up to 50 versions, but only 1 can be active).

Login Forensics (Pilot)
Two new standard objects LoginEvent and PlatformEventMetrics enable identification of suspicious login patterns, such as unusual login times, IP ranges, above-average login behaviour etc. To avoid fraudulent activity a Salesforce security plan should be proactive in auditing login patterns over time.

Named Credentials
Named credentials bundle together the configuration details for an authenticated Apex callout; endpoint, authentication type and credentials are stored together as a single configuration record that is maintainable via the setup menu. This replaces a common use of Custom Settings and usefully decouples the authentication coding, which is handled by the platform.

Queueable Job Chaining
Asynchronous tasks submitted via Queueable Apex can now be chained an unlimited number of times; previously the limit on the chain size was 2. This sounds useful in terms of incremental processing of large data sets, but if your technical solution design requires a significant chain size this may indicate a flawed approach. Note, the release notes suggest that DE and trial orgs are limited to a chain size of 5.

New Lightning Components
New components and events have been added to the Lightning Component Framework, the restrictions in regard to authoring of components in a Developer Edition org with a namespace have also now been removed. With Spring ’15 components can be configured to run within the Lightning App Builder and Lightning Pages, although the former remains in a closed pilot.

Case Feed Macros
Case Feed users can now reduce time performing repetitive tasks by executing, via a single-key click, pre-defined macros. Macros are comprised of instructions such as selecting an email template and sending an email to a customer. In practice a library of useful macros will greatly increase Support Agent productivity whilst ensuring standardised support processes are adhered to. The macro functionality seemed to be missing from my pre-release trial org – I suspect the functionality is related to the Lightning Process Builder which is also omitted.

Indexed Column Added to Lists of Fields in Setup
A very useful additional column on the Fields page for Standard and Custom objects – covers standard and custom fields. An understanding of the indexes applied to an object can be key to troubleshooting reporting performance issues or to ensuring SOQL queries, list view filters etc. are defined with data retrieval performance in mind.

Indexed Column

Salesforce Activity Sharing

This brief post serves to clarify the sharing model related to Activities, i.e. Task and Event. For most implementations a public sharing model for Activity is highly appropriate and a necessary element of the CRM process. In some cases however a private model is required, perhaps where strict visibility rules must be applied in respect to Account and Contact, or where the activity itself is of a confidential nature. In the former example details of the Contact (Name, Title, Account Name) are revealed on the Activity record to assigned users (and those above them in the role hierarchy) who don’t necessarily have record visibility to that Contact or Account. This can be a problem. In the latter example, the interpretation of private OWD for Activity relates to editing of records, not visibility of records (as is the case for other objects) meaning there’s no mechanism to restrict access selectively to Activity records related to a given record. In mitigation, field level security (FLS) can be applied to hide fields from certain users, this approach can be effective but is not ideal. As such the implementation of a fully private sharing model for Activity can be difficult to achieve.

Blog Sketches

Activity Org-wide Default Implications
— Private : Read access to the [Related To] record provides read access to the Activity. Only the Assigned User and users above them in the role hierarchy can edit.

— Controlled by Parent : Read access to the [Related To] record provides read access to the Activity. Edit access is possible for the Assigned User and users above them in the role hierarchy, or requires [Modify All] object level access on the related record object, or the Modify All Data permission.

In considering the OWD settings above, the rules below must also be understood.

1. Activity Visibility. If the Activity is related to a Contact, then View access is required to the Contact, with the exception of the Assigned User (and role hierarchy) who can view the Activity regardless of Contact access. Private contacts can be problematic in this context.

2. Activity Edit. If the Activity is related to a Contact, then Edit access is required to the Contact, with the exception of the Assigned User (and role hierarchy) who can edit the Activity regardless of Contact access.

Help and Training – Access to Activities and Calendars
Idea – Support for fully private (no read or write) activity sharing model

Salesforce Topics

One of the more interesting (but low-key) functional enhancements to arrive on the Salesforce platform over recent releases is Topics.

All Topics Page

A Topic can be viewed as a consolidation of the collective enterprise intelligence around a specific term or theme, across both the collaboration dialogue and the business processes managed within Salesforce. In practical terms this translates to Chatter posts and Object records being assigned one or more new or existing Topics. All assigned records and posts then display on the Topic page – providing the consolidated view of everything happening across the enterprise that pertains to the Topic. This is incredibly powerful in terms of both data categorisation and the insight possible from considering the holistic view of a contextual theme or initiative.

Topic Page - Feed tab

The Topic functionality doesn’t end there; from a Topic page (see screenshot above) it is possible to endorse users as experts on the Topic thereby harnessing knowledge within the enterprise and providing an effective means of channeling communication such as a questions, suggestions and so on. Note, users can elect to remove themselves from the Knowledgeable People list.

Topics can be followed (if feed tracking enabled for Topics) and favourited which enables interested users to be updated proactively. Discussion of Topics is tracked at the Group and User level, the Chatter tab also shows the Trending Topics area which highlights recent activity, this excludes Topic used solely in private Groups or record feeds.

Note, as a point of clarification Topics differ from Groups in that they collect posts from across Chatter and also records.

Primary Use Cases

1. Topics provide a good solution option for any data categorisation or notification requirement relating to enterprise-wide initiatives or themes.
2. Topics map well to Organisational concepts such as departments, virtual teams, projects etc.
3. Topics could provide a useful (albeit elective) notifications model where the Topic feed is used to push notifications to users interested in new transactional records related to the Topic theme, which could represent a reference data type such as a region, product or channel.

Key Considerations

Topics for Object. Once enabled for an object, records can suggest Topics based on the values in selected fields. Whilst a Topic has a feed, record assignment does not generate a post. To mitigate this, Topic assignment can occur via #hastag in a post to the record feed. Additionally, feed activity related to a record is not viewable on assigned Topic pages. The concept relates to grouping and categorisation of records, not consolidation of feed items.

Global Search enabled. Topics appear as a distinct Object within the Record search results.

List Views. Topics can be referenced in List View filter criteria.

Reports. With Winter ’15 the reporting options are limited to those below (to my understanding) via CRT. Reporting on record level assignment isn’t there as yet.
–Topic – list of topics with # talking about statistic
–Topic Assignment – count of assignment per record type (key prefix)

Knowledge Articles. Topics can be added to Knowledge articles enabling end-user categorisation of published articles in addition to pre-defined data categories.

Customisation. Apex triggers can be defined on the Topic and TopicAssignment (assignment of a topic to a FeedItem or a record) objects, which are also API accessible.

Permissions. Profile permissions (or permission set) control who can create, edit, delete and assign topics. Defined topics are public regardless of whether they are solely used in private groups or on records.

Topics for Objects – Screenshots

1. Add a Topic to a Record

Add Topic to Record

2. Topics Assigned to a Record

Record with Topics

3. Topic Page – Records Tab

Topic Page - Records Tab

Salesforce Environment Hub

Environment Hub was announced back in August 2012 and was initially made available as a Pilot feature of the Winter ’13 release. This post follows up (some 2 years later) on my initial interest in understanding the utility Environment Hub delivers in the context of environment/user management.

Environment Hub – What is it?
In simple terms Environment Hub is an org administration tool that enables multiple orgs (of any type) to be associated and accessed from a central location. Each connected org is a termed a Hub Member, with an imposed constraint that each Hub Member org can only be parented by one Hub org. It is therefore imperative that Hub Members are only added where there is no contention over the appropriateness of the parent Hub. Commonality of target production org or packaging org is a good starting point for this consideration, as is the rule that client orgs should never be parented by an ISV or Consultancy Hub org. The parent Hub org should always be the most-accessed org, the credentials for which will become those by which all org access is made.

For larger programmes of work Environment Hub provides a highly useful means to catalogue the org estate and to provide SSO between the constituent orgs. This latter point enables reduced password maintenance, simplified access and centralised user administration in terms of deactivating a user account in one place only and ability to view login history in once place.

Environment Hub Tab

Environment Hub is enabled by Salesforce support who will require confirmation to proceed with the change. From experience, the enablement process can take a few days.

Key Features

Connect Organisation
Connecting Hub Members to the Environment Hub occurs via the entry of an administrator username for the target org and subsequent OAuth authentication and authorisation flow. The User Permission “Connect Organisation to Environment Hub” is required.

Connect Organisation 1

Connect Organisation 2

Connect Organisation 3 - OAuth

Connected Organisation Detail Page

Once an org is connected to the Environment Hub interesting detail such as the Edition, Org Status and Org Expiry date is revealed. It is also possible to add custom name and description attributes to the Hub Member, which I really like, each org in the estate should be justifiable and have a specific purpose – here we can capture this plus accountable contact etc. A very useful means of cataloguing and tracking the org estate.

The Company Detail page in the connected org will now show the Environment Hub Org Id value as below.

Company Information Page

In addition to the “User Added” origin, Hub Members are also auto-discovered using existing org-to-org relationships as below.

Auto-discovery types; sandbox to production, patch orgs to release org, trialforce source org to trialforce management org, release org to LMO

Create Organisation
New development/test/demo orgs can be created directly within the Environment Hub – this replaces the functionality previously exposed via the Salesforce Partner Portal, for partners at least. I’m unclear how the types of org offered are affected by partnership status etc. or perhaps whether the Environment Hub itself is available only to partners.

Create Organisation

Create Organisation 2

Org types offered;
Development = PDE org.
Test/Demo = Pick Edition for a 30 day time expired org.

Useful information of the distinction between different org types can be found here.

Single Sign-on
SSO can be enabled between each Hub Member and the Hub org; in implementation terms this means the Hub org is configured as an Identity Provider with a Service Provider being configured (automatically via the SSO enablement process) in both the Hub Member org and the Hub org. Both IdP initiated (via the Environment Hub tab) and SPI-initiated (via enablement of the Service Provider as a Login Page Authentication Service) SAML flows are supported. The latter point meaning SSO could be enforced as the only authentication means – thereby switching off standard Salesforce authentication entirely. Each Hub Member Org must have a My Domain configured for SSO to function.

Note, enabling SSO creates a Service Provider in the Hub org, default permissions are provided to the Standard User and System Administrator profiles only. It is therefore a requirement to ensure relevant permissions (Profile or Permission Set) are provided.

Connected Organisation Detail Page SSO

Within the Identity Provider, the Hub Member specific Service Provider configuration is set with “Subject Type=User’s ID determined by Environment Hub”, this setting delegates the user mapping to the Environment Hub settings, defined as below.

3 types of SSO User Mapping;
Method 1. Mapped Users – 1 to 1 mapping of user names – per-user.
Method 2. Federation Id – boolean state, yes = attempt to map users on common Federation Identifier values.
Method 3. User Name Formula – formula expression = attempt to map users via formula result.

Where multiple mapping types are enabled the precedence order above applies. For SSO between a sandbox and production org, user mapping is implicit and not configured as above.

Enabling Environment Hub adds the EnvironmentHubMember standard object which is open to the declarative build model; custom fields, page layouts. validation rules, workflow rules, approvals etc.. In addition Apex Triggers can be defined on this object, use cases for which may include notifications relating to status changes etc.

A second standard object EnvironmentHubInvitation is also added, however this object is inaccessible from the Setup menu (although it can be reached via /p/setup/layout/LayoutFieldList?type=EnvironmentHubInvitation&setupid=EnvironmentHubInvitationFields). I’m assuming this object to be either forward looking or a legacy of an invitation-based connection model (as per Salesforce to Salesforce). Regardless, records do seem to be added to this object, the logic for which is unclear.

Related Permissions
Hub Org –
Manage Environment Hub
Environment Hub App and Tab access
EnvironmentHubMember standard object access permissions
Environment Hub Connected App
SSO Service Providers e.g. [00_____0000Cj__] Service Provider Access for SSO (by Profile or Permission Set)

Hub Member Org –
Connect Organisation to Environment Hub

Environment Hub in Practice
For consulting projects Environment Hub offers significant value in terms of management and tracking of the org-estate and centralisation of user administration. In practice this would require all project contributors to access production (Hub) as the primary org and SSO into secondary (Hub Member) orgs as required. In this model, production could be utilised for project collaboration, bug-tracking, project management etc. which is a common approach. The obvious downside being the requirement to license the project team in production – a big challenge on many projects where user licenses aren’t provisioned until a late stage or business use runs parallel to project activity. In such examples, project contributors could be provisioned with low-end user licenses on a temporary basis. Ideally we could do this with a Chatter Plus license as users would only require Chatter, Custom Objects (10 or less) and Environment Hub access.

For ISV projects, the utility of Environment Hub relates more specifically to the ability to catalogue the multitude of environments required for development, test, i11n, packing, release and patch purposes, not to mention TrialForce. Efficiency of access across this estate is also a key factor.

Environment Hub Online Help

Salesforce1 Lightning

Once again the annual Dreamforce event has been and gone leaving most practitioners with an uncomfortable knowledge deficit in terms of the real detail of the wealth of new innovations announced. This autumn period, post-Dreamforce, is often a time for investigation; piecing together information gathered from press releases, blog post, social media and event session replays.

This post provides the output of my own brief investigations into the Salesforce1 Lightning announcement. Note, I may be vague or incorrect in some areas, I have made assumptions (safe I hope).

Salesforce1 Lightning – What is it?
Salesforce1 Lightning is the next generation of the Salesforce1 Platform, it is framed specifically as a platform-as-a-service (PaaS) play and heralded as the world’s number 1. The platform is comprised of a number of new and re-branded technologies that collectively target the rapid delivery of cross-device, responsive applications via clicks-not-code. Responsive in this context relating to dynamic components that adapt their layout to the viewing environment, to provide an optimised viewing experience, regardless of the dimensions (i.e. a single view layer that supports desktop computers, smartphones, tablets and wearables).

Salesforce1 Lightning – Key Features
– Lightning Framework (GA now)
Saleforce developed UI framework for rapid web application development based on the single-page model, loosely coupled components and event-driven programming. The underlying Aura Framework was open-sourced last year and is used internally by Salesforce for the development of Salesforce1 plus recently introduced platform functionality (Opportunity Splits UI etc.). The Lightning Framework represents the availability of a subset of the Aura Framework functionality as a platform service for custom application development.

– Lightning Components (beta now, GA Spring 2015)
In order to build with the Salesforce1 Lightning Framework we need components. Components represent cleanly encapsulated units of functionality from which user interactions are comprised (i.e. apps). Component communication is supported by an event-based-architecture.

Standard Components – e.g. Button, Report Chart, Chatter Feed. Standard Components enable custom applications to be composed that inherit the Lightning UI (meaning the Salesforce1 UI).

Custom Components. Using the Lightning Component Framework, custom components can be developed to deliver any required experience (style, branding, function etc.). Developers build components with predominantly client-side behaviours, Apex can be employed to provide server-side controller functionality.

AppExchange Component. 3rd party commercial components installed from the AppExchange.

– Lightning App Builder (beta Spring 2015)
As the name implies the App Builder enables application composition through the drag-and-drop of components – meaning no-code. The builder provides Desktop, Laptop, Tablet, Phone and Smart Watch views onto which optimal component layouts are configured – the responsive behaviour to the components themselves therefore applies within the device type view – this makes good sense as an optimal laptop experience is not the phone view with proportionally bigger components. This approach is commonplace, for example works this way – i.e. build a generic device type specific view with components that adjust to the device specific viewing environment.

– Lightning Process Builder (GA Spring 2015)
Re-branded Flow / Visual Workflow functionality. In this context the point being that the business process logic is configurable through a drag-and-drop visual tool. Edit: my assumption here in relation to re-branding may well be incorrect, it has been suggested that the tool is in fact a distinct technology from Flow and may coexist. I’ll update this when I understand more – the functional overlap between Flow and Process Builder looks to be significant.

– Lightning Schema Builder (GA now)
Re-branded Schema Builder functionality. In this context the point being that the data schema is open to visual (i.e. drag-and-drop) manipulation.

– Lightning Connect (GA now)
Re-branded Platform Connect, or External Objects. The ability to configure virtual objects that query external data sources in real-time via the OData protocol. Connect underpins the concept of real-time external data access via the Salesforce1 platform and its constituent mobile applications.

– Lightning Community Builder (beta now, GA Spring 2015)
As the name implies a drag-and-drop tool for the configuration of Salesforce Communities plus the content delivered.

Entry Points
Salesforce1 Lightning Components can be accessed in the following ways.

Standalone App – access via /NAMESPACE/
Salesforce1 Mobile App Tabs – create a Tab linked to a Lightning Component and add to the Mobile Navigation Menu.
Salesforce1 Mobile App Extensions – currently in Pilot, a means by which custom components can override standard components.

Future – All Visualforce entry points should ultimately become options for Lightning Components. This one is definitely an assumption. Standard components with which exhibit the standard Salesforce (Aloha) styling would be required for this.

The following list represents some initial thoughts regarding the significance of Salesforce1 Lightning – formed without the insight gained through practical experience.

– Mobile-first.
The design principle is simple, the most effective way to build compelling user experiences across multiple devices is to start with the simplest (or perhaps smallest) case, i.e. the mobile. Note, the introduction of wearables possibly invalidates this slightly. The alternate approach of trying to shoe-horn complex desktop experiences onto smaller viewing environments rarely produces anything worthwhile.

– Rapid Development.
Quickly, faster, speed-of-business plus various other speed-related adverbs litter the press releases for Salesforce1 Lightning. If the name itself isn’t sufficient to highlight this, the platform is all about rapid development. In context rapid is realised by configuration-over-code; assembling apps with pre-fabricated, road-tested components delivers the shortest development cycle. That said, regardless of whatever form development takes a development lifecycle is absolutely necessary – the vision of analysts configuring apps over lunch and releasing immediately to business users is prone to disaster; I don’t believe this to be the message of Salesforce1 Lightning however.

– Technical Barriers versus Organisational Friction.
Removing technical barriers to rapid application development is only one part of the equation, organisations need to be culturally ready to embrace and therefore benefit from such agility. Building an enterprise app in a week makes little sense if it takes 3 months for acceptance, approval and adoption processes to run. The concept of turning IT departments into centres of innovation is an incredibly powerful aspiration, however this relies heavily on empowerment, trust and many other agile principles some organisations struggle with.

– Development model.
The Lightning development model is fully consistent with the age-old Salesforce philosophy of rapid declarative development via pre-fabricated componentry. Application architects, admins, analysts etc. assemble the apps with components supplied by Salesforce, built in-house or procured from the AppExchange. Developers will therefore focus more on building robust and reusable components than actual applications – which makes good sense assuming appropriate skills are applied to component specification and application design. The model requires non-technical resource to adopt a development mindset, this may be problematic for some.

– Developer Skills.
To build with the Salesforce1 Lightning Component Framework developers must be proficient in JavaScript, beyond intermediate level in my view. Lightning is a comprehensive component-based client-server UI framework with an event driven architecture. Developers with previous exposure limited to basic JavaScript augmentations to Visualforce face a learning curve. Anyone still under the false impression that JavaScript programming is simple compared to languages such as Java, C, C++ etc. may want to reconsider this before embarking on a Lightning project.

– Use Cases.
The viability of the proposed development model may ultimately come down to the complexity of the use cases/user experiences that can be supported without reverting to custom component development. By their very nature mobile interactions should be simplistic, but for desktop interactions it will be interesting to understand the scope of the potential for complex applications.

– Adoption.
Salesforce1 Lightning follows a similar paradigm to both and Flow, where historically technically oriented tasks are made possible for non-technical users; drag and drop visual composition of business process realisations and interactive web site development respectively. Both technologies, as innovative and empowering as they are, do not appear to have radically changed the development models to which they pertain. An obvious question therefore is whether the empowering technology alone is enough to drive adoption.

Aura Documentation Site
Lightning Components Developer’s Guide
Lightning QuickStart

Apex Unit Test Best Practice

This post provides some general best practices in regard to Apex Unit Tests. This isn’t a definitive list by any means, as such I’ll update the content over time.

Top 10 Best Practices (in no order)

1. TDD. Follow Test Driven Development practice wherever possible. There is no excuse for writing unit tests after the functional code, such an approach is indicative of a flawed development process or lax standards. It’s never a good idea to estimate or deliver functional code without unit tests – the client won’t appreciate an unexpected phase of work at the point of deployment, not to mention the pressure this approach puts on system testing.

2. Code Quality. Ensure unit tests are written to cover as many logical test cases as possible, code coverage is a welcome by-product but should always be a secondary concern. Developers who view unit tests as a necessary evil, or worse, need to be educated in the value of unit tests (code quality, regression testing, early identification of logical errors etc. etc.).

3. Test Code Structure. For some time now I’ve adopted a Test Suite, Test Helper pattern. A suite class groups tests related to a functional area. A test helper class creates test data for a primary object such as Account (i.e. AccountTestHelper.cls), secondary objects such as price book entry would be created within the product test helper class. The suite concept provides a logical and predictable structure, the helper concept emphasises that test data creation should be centralised.

4. Test Code Structure. Put bulk tests in a separate class e.g. AccountTriggerBulkTestSuite.cls (in addition to AccountTriggerTestSuite.cls). Bulk tests can take a long time to complete – this can be really frustrating when debugging test failures – particularly in production.

5. Test Code Structure. Ensure test classes contain a limited number of test methods. I tend to limit this to 10. As with point 4, this relates to test execution time, individual methods can’t be selectively executed – the smallest unit of execution is the class.

6. SeeAllData. Always use SeeAllData=true by exception and at the test method level only. Legacy test code related to pricebooks that historically required this can now be refactored to use Test.getStandardPricebookId(). Also, set the [Independent Auto-Number Sequence] flag to avoid gaps in auto number sequences through the creation of transient test data.

7. Test Case Types. As the Apex Language reference proposes, write unit tests for the following test case types.

Positive Behaviour – logical tests that ensure the code behaves as expected and provides successful positive outcomes
Negative Behaviour – logical tests for code behaviour where parameters are missing, or records do not adhere to defined criteria – does the code protect the integrity of unaffected records – does the runtime exception handling function as expected
Bulk – trigger related tests primarily – how the code behaves with a batch of 200 records – mix the batch composition to stress the code against governor limits
Restricted User – test relevant combinations of user role and profile – this test case type is prone to failure through sharing model adjustments – triggers should delegate processing to handler classes that have the “with sharing” modifier

8. Debugging. Always use the syntax below for debug statements within code (test and non-test code). An efficient practice is to add sensible outputs whilst writing the code. This approach avoids a code update or re-deployment to add debug statements during error diagnostics. Note – in such cases Checkpoints could be a better approach anyway – particularly in production. The use of the ERROR logging level enables a restrictive log filter to be applied such a clear debug log is produced and max log size truncation is avoided – note, log filters can also have a positive impact on transaction execution time.

System.debug(LoggingLevel.ERROR, 'my message');

9. Commenting. Always comment test methods verbosely to ensure the test case intent is clear and that the test code can be mapped to the related non-test code. Test classes should be fully self documenting and be viewed as the primary enabler for the future maintenance of the non-test code.

10. Maintenance. Test code is highly dependent on the environment state. Any configuration change can require test code to be updated; this could be a new mandatory custom field or a sharing model adjustment. In many cases the resultant unit test failure state is not encountered until the next deployment to production, which can’t proceed until the tests are fixed. This scenario will be familiar to many people. The mitigation requires the local administrator to understand the risk, frequently run the full set of unit tests and to manage the test code update cycle proactively.

Example Test Suite Class

Name: RecordMergeTestSuite.cls
Copyright © 2014  CloudMethods
Test suite covering RecordMerge operations.
Bulk tests are defined in the class RecordMergeBulkTestSuite.cls
Ver. Author        Date        Detail
1.0  Mark Cane&    2014-09-16  Initial development.
public with sharing class RecordMergeTestSuite {
     Test cases:	
        singleTestCase1 - postive code behaviour/expected outcome test case 1.
        negativeTestCase1 - negative outcome test case 1.
        restrictedUserTestCase1 - postive/negative code behaviour in the context of specific user role/profile combinations.
        future test cases to cover : * some coverage provided
        1. tbd.
        2. tbd.
    /* */
	static testMethod void singleTestCase1() {
		// Test case 1 : postive outcome test case 1.

		// Steps - 1. 
		// Logical tests - 1.
    /* */    

    /* */
	static testMethod void negativeTestCase1() {
		// Negative test case 1 : negative outcome test case 1.

		// Steps - 1.
		// Logical tests - 1. 
    /* */    

    /* */
	static testMethod void restrictedUserTestCase1() {
		// Restricted user test case 1 : postive/negative code behaviour in the context of specific user role/profile combinations.		    	    			
		List<User> users;
		System.runAs(new User(Id = Userinfo.getUserId())){ // Avoids MIXED_DML_OPERATION error (when test executes in the Salesforce UI).
			users = UserTestHelper.createStandardUsers(2, 'Sophie', 'Grigson');
			accounts = AccountTestHelper.createAccounts(1, 'Abc Incorporated');
			// Steps - 1. 
			// Logical tests - 1.
    /* */
	// helper methods    
    private static void setup(){
    // end helper methods