Salesforce1

There’s no better way to kick-start the New Year than to indulge in a bit of release-note exploration for the upcoming Spring release. This exercise is best performed with the latest release notes to hand, a brand new pre-release org to play with and the previous release certification exams safely completed. The links below are provided for convenience.

Spring ’16 Pre-release Sign-up
Spring ’16 Release Notes

The rollout dates for the primary production instances are the 6th (2nd release weekend), 12th and 13th February (final release weekend); specific instance dates are stated on the trust.salesforce.com site.

As expected the Spring ’16 release is focused on consolidation and enhancement of Lightning Experience; this feature set feels substantially more enterprise-ready as the intermittent performance and stability issues observed previously appear to be addressed and the feature gap from Salesforce Classic has been diminished in key areas such as reporting. A robust Lightning Experience that can be released to business users with confidence can’t come soon enough for many, although with features gaps remaining and Person Account compatibility at Beta status the Summer release may present a more realistic timeline.

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

– features are GA if not indicated otherwise

Developer Sandbox Limits Increase
All editions that include sandbox licenses have significantly increased limits. Enterprise Edition customers now get access to 25 developer sandboxes instead of 1. I had to read this a few times to take the news in. The single sandbox constraint for EE customers has been a challenge for many implementations trying to adopt development lifecycle best-practices or to simply isolate testing from development or UAT or indeed develop multiple projects in parallel. The new limit will provide a significant level of flexibility here and promote a standard-based approach, I hope.

Post Sandbox Copy Script
A new Apex interface (SandboxPostCopy) enables Apex script to be executed automatically post Sandbox copy operation (create or refresh). In a similar fashion to the PostInstallScript interface used by ISV to apply configuration steps and data creation tasks following package installation the new interface should help prepare a sandbox using a standardised, validated and automated approach.

Lightning Experience – Person Account Compatibility (Beta)
Person Account compatibility is highly anticipated by all B2C implementations unable to consider Lighting Experience otherwise. With the Spring ’16 release a beta status compatibility is provided which at least provides an ability to test and explore Lightning Experience in a sandbox setting.

Lightning Experience – UI Enhancements
List View filters can now be edited on-the-fly and record detail pages support inline editing. Both features providing enhancement to the general user experience. The ability to view embedded charts and to manipulate filters on the List View page is a real improvement in this area. Inline editing simply reinstates a capability taken for granted by most. It is also possible to define custom navigation menus and assign by User Profile to deliver a customised view to different users.

Lightning Experience – Reporting
The reporting feature gap between Lighting Experience and Salesforce Classic prior to Spring ’16 made for difficult reading. The new release establishes some degree of feature parity with Dashboard Filters, Dynamic Dashboards, Dashboard table components and the ability to view record details on Matrix Reports all making a welcome return.

Lightning Experience – Detect User Experience
Last point in relation to Lightning Experience; support is now provided for Apex script to reliably detect the current user experience, i.e. Salesforce1, Lightning Experience, Salesforce Classic. New Apex methods are available (User.UITheme and UserInfo.getUiTheme()) that provide a standardised approach that replaces the previous use of the sforce.one JavaScript global (and its unsupported approach caveat).

Files Connect for Box (Pilot)
Files held on the Box cloud are now accessible directly in Salesforce via the Files Connect feature. Given how commonplace it is that Salesforce and Box are used in concert a standardised approach is highly convenient particularly where support extends to on-premise data sources (Sharepoint etc.).

Custom Metadata Types
Custom Metadata Types have been enhanced to support bulk creation scenarios and the upsert operation. Picklist fields are also supported, although this a beta status feature for Spring ’16. CMT provide the basis for a variety of platform-on-a-platform use cases or simply convenient application configuration management. Continued investment in this area is great news for the developer community.

Apex Test Suites
As a long-time advocate of a structured approach to Apex Unit Test classes the new Test Suite features is an excellent introduction. In short Test Classes can be arbitrarily grouped in the context of a parent Test Suite label, the suite itself can then be selected at the time of test execution from the New Suite run option. Test Suite definition and invocation takes place in the Developer Console.

Apex Unit Tests
New developers writing Apex Unit tests have suffered for years with the platform constraint that setup and non-setup objects can’t be created in the same Apex transaction (Mixed DML Operation Error). Typically this is problematic where User records are created in the test context alongside test records such as Accounts etc. With Spring ’16 it is now possible to create the setup object via @future method. A second improvement in context is the ability to change record creation date field values using the System.Test.setCreatedDate method. Where record processing logic is temporal in nature this ability will be helpful in writing tests that correctly validate the code logic.

Lightning Out (Beta)
Lightning Out provides the capability to securely embed Lighting Components into a remote application running on any external platform or container. This YouTube link provides a great introduction to the power and potential of Lightning Out.

Platform Security Health Check
Spring ’16 provides an interesting new security Health Check feature that enables the current org configuration to be compared against a Salesforce recommended baseline. Any feature that highlights security risk or vulnerability is positive addition and should help mitigate against complacency.

With September upon us and Dreamforce 2015 on the near horizon it’s time to dispel thoughts of sunshine and holidays and get focused on the upcoming Winter release. Whilst it’s undoubtedly depressing to be reading the word Winter in early September, there’s plenty in the new release to raise the spirits. It’s also clear that with significant platform changes emerging, i.e. Lighting Experience, this is an important time to be on the front-foot in terms of keeping personal platform expertise up-to-date. For Salesforce professionals or engaged users, the Winter ’16 release presents a great opportunity to reset your knowledge of the platform.

Pre-release sign-up appears to be offline at present, however existing pre-release orgs should be updated and available to explore. A preview set of release notes can be downloaded from here. The rollout window for production instances is between the 25th September and the 17th October, specific instance dates are stated on the trust.salesforce.com site.

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

– features are GA if not indicated otherwise

Lightning Experience
As the marketing literature states; a new, modern, intelligent user experience – or, in other words the new Salesforce.

With Winter ’16 we’re entering a new transitional era for the platform with features migrating from the Salesforce Classic UI (Aloha) across to Salesforce Lightning Experience presumably over the course of a series of releases. This journey starts with a focused Sales Cloud offering. The updated user interface looks like a significant advancement, however many users will need to navigate both interfaces which may degrade the overall user experience. It should be noted that access to the Lighting Experience desktop experience is permission based (profile or permission set) and therefore user access can be selective. The new experience is more than a cosmetic update, a number of object-specific features (e.g. Account Insights, Opportunity Workspace) are introduced that increase the functional richness provided and deliver a more focused view than the generic interaction patterns applied in the Aloha interface.

Lightning Experience – Visualforce Support – Beta
Visualforce support in Salesforce Lighting Experience will be GA in the Spring ’16 release, for Winter ’16 this is desginated a beta status. Support in this context means rendering with the Aloha look and feel, pages will not inherit a Lighting Experience visual style via the container, instead Visualforce pages will need to be redeveloped using Lightning Components and the Lightning Design System to reflect the new visual style. Where investments have been made in Visualforce (ISVs for example) the lack of migration path could represent a significant amount of work. The Lightning Design System (LDS) provides the CSS and design guidelines necessary to develop user interface components that are consistent with the Lightning Experience visual design.

Platform Cache
A new Force.com platform cache has been added that supports both org-level and session-level data caching. The cache can be accessed from Apex via the Cache namespace and provides obvious performance and reliability benefits. A Session cache has been required for Visualforce for some time to help reduce viewstate pressure, the Org cache will remove the need for Custom Setting based solutions for shared/global data. Available cache space can be distributed across partitions to provide control over application-level usage.

Apex Debugger
An extension to the Eclipse based Force.com IDE that provides support for breakpoints. This is a major advancement for Apex development. Step Over, Step Into, Run To… all the usual breakpoint related features are supported. At long last Apex has some degree of basic parity with other languages where this capability is taken for granted. The release notes mention that for some customers the Apex Debugger may incur additional costs, the detail of which is yet to be seen.

Process Builder – Query Bucketing
The Lighting Process Builder is a powerful new platform automation feature – unfortunately to date Processes have not been bulk-safe and have a tendency to throw platform limit exceptions during bulk record operations; typically Soql query limit exceptions. The mitigation for which has been to suppress the batch size to a safe point – a reasonable but not entirely satisfactory resolution. With the Winter ’16 release Soql queries within a transaction are bucketed, meaning combined, to reduce the overall number of queries executed. In principle, this practice enables the limit to be avoided and the transaction to complete. This feels like a temporary resolution to the problem while a more significant re-engineering takes place, I understand that the issues here are not trivial.

Writeable External Objects
An obvious next step for Lighting Connect – the ability to write back to External Objects. Previously External Objects have provided read-only views on the external datasets. The new write support covers OData and custom Apex adapters but not the Salesforce adapter. Record modifications via the UI occur synchronously, while Apex invoked changes are applied via an asynchronous queue.

Extensible Community Templates
Winter ’16 Community Builder templates are now extensible meaning additional Salesforce functionality, content and navigation paths can be configured extending the available features beyond the constraints of the predefined templates. This additional level of configuration takes place directly within the Community Builder, removing the need to use Site.com Studio. Winter ’16 template pages are compatible with Lightning technology meaning Lighting components can be used. This topic is huge but suffice to say the new streamlined development workflow and ability to extend the pre-defined templates to new use cases both represent a significant step forward for Community Templates.

Broadcast Groups – Pilot
Chatter Groups, whether public, private or unlisted can now be configured to allow only the group owner or manager to create posts. Anyone who’s used Chatter groups extensively will recognise the requirement to support one-way, focused communication and to avoid off-topic posts. I can think of a few Salesforce partner community groups that will be implementing this feature asap.

Chatter Questions – Similar Questions and Articles
Chatter Questions now supports the display of Similar Questions and Knowledge Articles inline while typing the question text. An obvious extension, to a highly useful feature, that should reduce the level of duplicate questions and increase the consistency in answers provided, particularly where deflection occurs via knowledge base article.

Restricted Picklists – Pilot
A new “Strictly enforce picklist values” attribute for picklist fields can be used to prevent input of values outside of the defined list via the data APIs. This new feature should be highly beneficial to anyone loading data and avoids the historic silent-error problem where picklist data mismatches go unnoticed.

More Rollup Summary Fields
The new limit is 25 per-object, replacing the old limit of 10. RSF are a great platform feature; incredibly powerful, intuitive for the end-user and quick to implement.

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 Force.com 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.

[code language=”java”]
public class myReportAction implements Reports.NotificationAction {
public void execute(Reports.NotificationActionContext ctx){
// perform action.
}
}
[/code]

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

@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.

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

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 (Force.com 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.

In a typical development process requirements are captured and the information synthesised to form a solution design. The constituent components of the solution design are ultimately translated into physical concepts such as a class, page or sub-page view. This analysis, design, build cycle could be iterative in nature or fixed and may have different degrees of detail emerging at different points, however the applied principle is consistent. In considering the design element of the cycle, interaction design techniques suggest a patterns-based approach where features are mapped to a limited set of well-defined and robust user interface patterns, complemented by policies for concepts that transcend the patterns such as error handling, validation messages, stylistic aspects (fonts, dimensionality etc.). This process delivers efficiency in terms of reusability of code and reduced technical design and testing, but also critically provides a predictable, consistent end-user experience. When building custom applications using the declarative tools, we gain all of these advantages using pre-defined patterns and pre-fabricated building blocks. When building using the programmatic aspects of the platform a similar approach should be taken, meaning follow established patterns and use as much of the pre-fabricated components as possible. I can never fathom the driver to invent bespoke formats for pages that display within the standard UI, the end result is jarring for the end-user and expensive to build and maintain. In addition to delivering a consistent, predicative end-user experience at the component level, the containing application itself should be meaningful and appropriate in type. This point is becoming increasingly more significant as the range of application types grows release-on-release and the expanding platform capabilities introduce relevance to user populations outside of the front-office. The list below covers the application types possible at the time of writing (Spring ’14).

Standard Browser App
Standard Browser App (Custom UI)
Console (Sales, Service, Custom)
Subtab App
Community (Internal, External, Standard or Custom UI)
Salesforce1 Mobile
Custom Mobile App (Native, Hybrid, browser-based)
Site.com Site
Force.com Site

An important skill for Salesforce implementation practitioners is the accurate mapping of required end user interactions to application types within an appropriate license model. This is definitely an area where upfront thinking and a documented set of design principles is necessary to deliver consistency.

By way of illustration, the following exemplar design principles strive to deliver consistency across end user interactions.

1. Where the interaction is simple, confined to a single User, the data relates to the User and is primarily modifiable by the User only and has no direct business relevance then a Subtab App (Self) is appropriate. Examples: “My Support Tickets”, “Work.com – Recognition”.
2. Where a grouping of interactions form a usage profile that requires streamlined, efficient navigation of discrete, immersive, process centric tasks then a Console app is appropriate. Examples: “IT Helpdesk”, “Account Management”
3. Where a grouping of interactions from a usage profile that is non-immersive, non-complex (i.e. aligned with the pattern of record selection and view/edit) and likely to be conducted on constrained devices then Salesforce1 Mobile is appropriate. Examples: “Field Sales”, “Executive Insight”.

Design principles should also provide a strong definition for each application type covering all common design aspects to ensure consistency. For example, all Subtab apps should be built the same way technically, to the same set of standards, and deliver absolute consistency in the end user experiences provided.

At the time I started writing this post we were living in a Chatter Mobile world, this is no longer the case. As announced recently at Dreamforce ’13 we have entered the Salesforce1 era, the direction of which will no doubt become clearer as we transition to the Spring ’14 release. What is clear now however is that the unified platform is the focus this time, providing mobile enablement (apps) via a rich set of platform services (APIs x 10). A rich set of robust APIs is always great news for any development community, whether you’re connecting a mobile device or sensor device (IoT). I won’t venture further into what Salesforce1 is in concept or the implications, some of this is yet to be seen. In any case this blog is focused on the practical application of the Salesforce and Force.com technologies, and as such the following summary is a point-in-time outline of the information available at the time of writing.

So, on to the topic in hand, customisation options for the Salesforce1 mobile application.

As with most things in life, to make good design decisions it helps to understand the full set of options available (and to see the big picture). This obvious point is fundamental in architecting Salesforce platform solutions; it’s key to have knowledge of the complete standard feature set and extension points (declarative build model) such that technical solution components are minimised. Simply put, in the mobile context this guiding principle means exhaust the potential of the standard apps (meaning Salesforce1) and the customisation options before building a new custom mobile app from scratch.

The following summary notes attempt to clarify the function of the Salesforce1 app and the various customisation options.

The Salesforce1 App – What is it?
In application development terms the Salesforce1 app provides a flexible mobile container into which a blend of standard and custom functionality can be presented on a variety of connected devices (mobile, tablet etc.). The container itself comes in 2 forms; downloadable native app (iOS and Android) and mobile browser app. In either form Salesforce1 employs a feed-first paradigm, with publisher actions and a notification platform. The mobile browser app must be enabled from the setup menu under Mobile Administration->Salesforce1 and becomes the default when accessing Salesforce from supported devices (as-per Salesforce Touch). Salesforce1 does not replace the standard Salesforce web app, or Full Site as it is referred. Salesforce1 does replace Salesforce Touch, Chatter Mobile and Salesforce mobile apps.

Ok, so assuming we’re comfortable with the idea that Salesforce1 is a application container, how can we extend the functionality of the container to deliver custom application interactions?

Customisation Options
The following summary notes attempt to clarify the customisation options available with the Salesforce1 mobile app. Also included in the list are standard capabilities of the container app, provided for completeness. The Salesforce1 App Development Guide provides a comprehensive coverage of the topics including example code that can be loaded into a development org (via github) to experiment with.

— Mobile Navigation
Within the setup menu under Mobile Administration, the Mobile Navigation option provides the ability to define the content and structure of the left hand side menu of the container app (as shown in the screenshot below).

Note. The first item in the list becomes the home page.

— Custom Objects (declarative)
Self explanatory. Recently searched for objects appear under the Recent section in the mobile menu structure according to profile permissions. It would appear that page layouts are shared between Salesforce1 and the standard Salesforce web app. This may prove difficult in terms of providing a balanced structure that is effective in both views.

— Flexible Page Tabs (declarative and technical)
I’m not 100% clear on the use cases for Flexible pages, however they do exist and can be added to Flexible page Tabs and ultimately rendered in the container app via inclusion in the menu structure (via Mobile Navigation). I need to do some further investigation into the potential of Flexible Pages, perhaps I’m missing something obvious.

A Flexible Page can have global publisher actions, list views and scoped recently used items. A maximum of 25 components can be added to the page, this constraint applies to listviews and recently used items.

In terms of definition a Flexible page is manually created in XML and deployed to an org via the Force.com Migration Tool or IDE. Once a Flexible page exists in an org the Create->Tabs page will present a Flexible Page Tabs list (as per Visualforce tabs etc.).

— Publisher Actions (declarative and technical)
Publisher actions are accessed via the (+) button on the home page, Chatter tab, Chatter group and record detail pages.

Actions can be Standard or Custom and Global or Object scoped.

Standard actions include;
Create a Record – respects Validation Rules etc. A Create action defined for a object will automatically relate created child records.
Log a Call – record a completed Task
Update – update a record from the Chatter feed

Default standard actions are provided for the core standard objects (create and update), such actions have configurable layouts and the ability to predefine field values.

Custom actions include;
Visualforce pages
Canvas apps

Interestingly actions can be described and invoked via the REST API, resource paths below.
/services/data/v29.0/quickActions (Global)
/services/data/v29.0/sobjects/[object]/quickActions (Object)

— Compact Layouts (declarative)
Compact layouts are defined at the object level and are simply an ordered list of fields by definition. Compact layouts apply in the following areas;

Record highlights fields (first 4 fields in the ordered field list). The record highlights are displayed in the top region of a record detail display under the icon.
Defines the fields that appear in the Chatter feed if a record us created via publisher action.
Enhanced lookup mobile card (more on this below)
Object record preview card

— Mobile Cards (declarative)
Page layouts now have a section for Mobile Cards, the following items can be added which then appear as a swipe-to card within the record detail view within the Salesforce1 app only.

Visualforce Page
Expanded Lookup. Related object (via Lookup) Custom Layout fields are displayed.

— Visualforce Pages (technical)
There are a number of extension points within the Salesforce1 app where Visualforce pages can be employed.

Mobile Card
Custom Publisher Action
Visualforce Tab added to the Mobile Navigation

In all cases the page must be mobile enabled and designed specifically for rendering on constrained devices, i.e mobile plus tablet on a variety of form factors. A best practice to consider in this respect is the development of adaptable pages that support both Salesforce1 and standard Salesforce web app execution. There are 3 development models in this respect classic Visualforce, Visualforce mixed with JavaScript, JavaScript and static HTML only with JS remoting. In all models the recently added (to Visualforce) ability to pass through attributes (HTML5) will be of use. Additionally, Salesforce1 comes with a highly useful navigation framework JavaScript library.

In short, where branded or complex UI interactions are required Visualforce provides a good option. Such pages must be carefully designed to deliver a optimal mobile experience and where possible be adaptable to also work in the standard Salesforce web app. This latter point relates to the cost of development and maintenance, adaptability is better than duplication – at the cost of smart design.

— Force.com Canvas Apps (technical)
There are a number of extension points within the Salesforce1 app where Force.com Canvas apps can be employed. Pilot program currently.

Custom Publisher action – post to the feed from a Canvas app
Chatter Feed – Canvas app rendered in a feed item

The use cases for the above will be varied and no doubt very interesting. Over time I think we’ll see more traction in the area of application composition. The ability to compose experiences and interactions across applications seamlessly (with context) and securely is a powerful concept.

— Smart Search Items
Recently searched for objects for the user. Searches performed in the full web app appear can appear In the left navigation menu, pin objects in the full site to keep at the top of this list.

— Notifications (declarative)
The Salesforce1 notifications platform supports 2 types of notification;

In App – Appear in the app itself and can be accessed manually via the bell icon (top right hand corner)
Push – Mobile device applications only, push notifications not supported by the mobile browser app. Such notifications will appear as badges on the app icon etc.

The notifications are limited to Chatter (mentions, posts, comments etc.) and Approval requests. Notifications are enabled at the org-level, not per-user.

Final Thoughts
In application development terms, Salesforce1 provides a rich set of declarative and programmatic techniques for the development of mobile interactions. Building out compelling mobile experiences that replace or augment existing Saleforce functionality (custom or standard) should be highly achievable whether you’re technically minded or not. This in my view is the real power of the Saleforce1 app, once you accept the proprietary approach there are no barriers to rapid mobile enablement.