Salesforce TLS 1.0 Support

As of June 25th 2016 sandbox orgs no longer support TLS 1.0 encryption. The previously optional critical update “Require TLS 1.1 or higher for HTTPS connections” was auto-activated on this date. Production orgs will be auto-activated on the 4th March 2017.

Inbound API connections requesting TLS 1.0 will receive the error message “TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.”.

Eclipse IDE Error

For Force.com IDE (Eclipse) users on Java 7 the eclipse.ini file must be modified to add the line below. This is not required for Java 8.

-Dhttps.protocols=TLSv1.1,TLSv1.2

Further information here.

Salesforce Summer ’16 Platform Highlights

Thankfully it’s time to start thinking Summer; the Summer ’16 (v37.0) release that is. Sporting a cheery (but perhaps more Autumnal than Summer) fireworks logo, the new release is available now for partner preview. The release notes are generally available here.

The Summer ’16 sandbox preview starts early May (7th/8th), with production orgs being upgraded early June. Full details of the release schedule are listed in this official blog post.

As expected Summer ’16 is an evolutionary release not revolutionary and continues the trend of Lighting Experience consolidation. As well as closing the gap on Classic functionality, a number of interesting net-new LEX features have been added.

_16__1_

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

– features are GA if not indicated otherwise

Sandbox-to-Sandbox Cloning
Recent releases have provided some interesting enhancements in the sandbox area (post refresh scripts, increased edition allowances etc.), Summer ’16 build on such improvements with a new function that allows a sandbox to be created as a clone of another sandbox (as opposed to a production org). Superficially this sounds like a useful capability; on further thought however this could have a significant impact on development process, allowing QA sandboxes to be cloned as copies of development at the end of sprint (as just one example). Any uni-lateral sandbox-to-sandbox deployments could theoretically be replaced with a clone. Multiple development sandboxes converging into a single upstream org would be the exception. Cloning is also supported by the Tooling API, enabling full automation of environment management. I’ve been unable test this feature as sandbox copy doesn’t appear to be enabled in pre-release orgs, however it would appear that data can be included in the clone. How data copy works between the different sandbox types is yet to be seen.

Summer 16 - Sandbox Clone

Force.com Flow REST API (Pilot)
New resources have been added to describe Flows and to manipulate Flow Interviews. The intent of this will be to enable the development of fully customised user experiences for Flow. Whilst possible to some degree via CSS, the user interface for Flow is difficult to customise in respect to branding, fine-grained control over layout, responsive behaviour etc.. The new API resources allow development of a Flow user interface in any technology that can manipulate a REST API.

Custom Metadata Types – Relationship Fields (Pilot)
CMT now support relationship fields that reference other CMT, custom objects or one of the core CRM standard objects (Account, Contact, Lead, Opportunity, Case). Previously pseudo-relationship fields were required of the text type that held the Name or id of the parent record; the new functionality is clearly a big improvement on this.

Apex – Populated SObject Field Map
As a programming convenience it is now possible to get a map of the fields populated in memory for an SObject instance. Previously, trial-and-error coding approaches have been required to identify whether particular fields are populated; this is prevalent in dynamic code and prone to error. Useful simplifications to the Apex language are always good news.

Lightning Components LockerService
LockerService introduces a new security architecture for Lightning Components comprised of technologies and techniques. Summer ’16 introduces LockerService in the form of two critical updates for existing orgs; one for internal components, the other for communities. New orgs will be auto-enabled by default; Winter ’17 will see all orgs auto-enabled. In short LockerService provides component namespace isolation in respect to DOM access and JS visibility, additionally only public documented Lightning JS APIs can be accessed. There’s considerably more to LockerService than this description covers, the link below provides more detail.

Introducing The LockerService For Lightning Components

Shield Platform Encryption
Shield Platform Encryption now supports Custom Date Fields and compatible fields within Managed Packages. The breadth of platform features that work with the shield data encryption-at-rest technology has also been extended; the new vertical clouds, Organisation Sync and Salesforce-to-Salesforce being interesting examples.

Create a Calendar from Standard/Custom Object Data
Personal Calendar views can now be created directly from data held in Standard or Custom objects. The calendar configuration requires that fields are specified for event start and end dates and also the name. There are currently limits to the number of events that can be viewed and also no means to share or subscribe to a calendar view of this type. Hopefully the next release will support public calendars of this type; the requirement for this style of data presentation is very common.

Summer 16 - Calendar

Process Builder – Execute Multiple Action Groups
Summer ’16 sees further investment in Process Builder which is great news for implementation practitioners using the process automation capabilities of the platform. Previously a process execution (or Flow interview behind the scenes) applied the logic of a single action groups and stopped. With Summer ’16 action groups can be configured with finish behaviour that continues to to evaluate the next action group in sequence. As such multiple logical conditions can be evaluated and acted upon within a single process execution. This new extension will help reduce the number of processes necessary to deliver even simple business process automations and as such is great maintainability improvement.

User Switcher
Regardless of role, most Salesforce users require access to multiple orgs at some stage; Summer ’16 introduces the convenience of a user switcher located on the drop-down menu accessed from the profile picture in Lightning Experience. Adding a user name provides one-click access from this menu to the org. Streamlined cross-org navigation has been long outstanding; beyond the obvious sandbox access use cases, in my experience the level of multiple-org access continues to increase over time.

Summer 16 - User Switcher

Associate Contacts to Multiple Accounts
The Contact to Account relationship is now extended to support one direct relationship plus multiple indirect relationships. A new junction object [AccountContactRelation] provides a standard Roles picklist, plus the ability to add Custom Fields. The inability to customise Contact Roles historically has resulted in the prevalence of custom approaches to Account to Contact relationship modelling. Note, it doesn’t appear possible to add process automation to the new object.

Summer 16 - AccountContactRelation 2

Summer 16 - AccountContactRelation 1

Enhanced Email
Emails sent from the Lightning Email Composer are now recorded as strongly-defined Email records rather than Tasks. A new Email standard object has been added which supports workflow, custom fields, layouts, triggers etc. Email records can be associated with multiple contacts, leads and person accounts and a single account, opportunity etc. Enhanced Email will be enabled by default where Email to Case is not in use. Representing emails as Tasks has never made complete sense; with Enhanced Email, Email records can be used as the basis for business process. Note, workflow on the Email object is limited to updating Case fields, this will limit the applicable use cases for this new functionality.

Salesforce Omni-Channel

This post provides a technical view on the Salesforce Omni-Channel feature-set added in the Summer ’15 (beta) and Winter ’16 (GA) releases.

In functional terms Omni-Channel enables use-cases where work items are proactively pushed to specific agents based on defined rules in relation to priority, capacity and availability. The model extends the traditional Queue approach through routing configurations that define how work items (Cases, Leads etc.) are sized, prioritised and the required routing logic (least active agent or most available). Agent capacity and availability is configurable per work item type, or service channel in Omni-Channel terminology. Queue membership controls the applicability of a given agent for a given work item. As such queues are defined to represent the work item assignment structure (skills, regions, teams, products, knowledge etc.) – as would typically be the case outside of Omni-Channel. Once a work item is assigned to an Omni-Channel enabled queue automated routing to an available queue member takes place. Where automated assignment fails, pending work-items are held on the queue and routing attempts made each time agent availability changes. Agent work load is represented by ownership of the records represented by work items.

From an agent perspective Omni-Channel interactions are handled via an Omni-Channel Widget in the Salesforce Console. The widget supports accept/decline behaviour and manual presence status setting. “Away for Lunch”, “Available for Cases” being illustrative examples. The work item display in the widget is controlled via the primary compact layout for the object the work item represents.

Omni-Channel Console Widget

Omni-Channel integrates seamlessly with Live Agent, enabling a standardised approach to routing and agent capacity across channels. Seamless in this context relates to the end-result, there are configuration changes required to transition from standalone Live Agent to an Omni-Channel integrated state. The objects supported by Omni-Channel are limited to those objects supported by Queues i.e. Cases, Chats, SOS video calls, Social posts, Orders, Leads, Custom objects.

Hopefully the preceding paragraphs sufficiently set the scene for the technical aspects covered below.

Data Model

Omni-Channel Data Model

As the model above shows Omni-Channel is underpinned by a significant number of standard objects. The majority of the objects support queryable, createable and updateable access levels which provides extensibility where standard features require augmentation. The one notable exception to this is the UserPresenceStatus object which records the current presence status for agents, this object is read-only. This limitation will prevent custom solutions (or more likely 3rd party AppExchange solutions) from programmatically manipulating the agent presence; this could be significant where solutions wish to share state with Omni-Channel at the application level.

Extension Points

Beyond the ability to extend Omni-Channel through direct data-level interactions (Apex or API) there are additional extension points to consider.

1. Custom Fields. The UserServicePresence (aka User Presence) and AgentWork objects support the addition of custom fields.

2. Apex Triggers / Validation Rules. The UserServicePresence object supports both Apex Triggers and Validation Rules. In the former case custom logic could be introduced to take action when specific presences are set. In the latter case conditional logic could be applied to prevent presence changes, although the console widget behaves erratically in response to validation rule failures.

3. Custom Console Footer Components. For each Service Channel (Lead, Case etc.) a footer component can be specified to open when a work item of the service channel type is opened. The customisation potential here is considerable.

4. Omni-Channel SOAP API Objects. Full set of objects exposed via the standard SOAP API.

5. Omni-Channel Objects for the Salesforce Console Integration Toolkit. Extensions to the standard console JavaScript API to support manipulation of Omni-Channel objects. Straightforward enough. A key point here to note is that unlike Apex or API transactions, the JavaScript API does support update of agent presence.

sforce.console.presence.setServicePresenceStatus(statusId, function(result) { ..}

6. Pre-assignment. Omni-Channel routing is applied when a work item is assigned to a Queue via record ownership. Automated routing logic then assigns the work item to a user based on priority, availability and capacity rules. Granular control of the user-assignment is not provided. Use cases that require one agent to be preferred over another based on logic such as last customer contact are not supported. Finer grained routing of this type should be addressed in the pre-assignment step, i.e. before the queue assignment. Agent presence and capacity are accessible via code and could therefore be queried as part of a custom user-level routing process. The AgentWork object is also createable suggesting that a record representing a pre-assignment could be added to ensure visibility of the work item to Omni-Channel.

References
Omni-Channel for Administrators
Omni-Channel Developer’s Guide

Update – 10th March

With Omni-Channel current agent workload is determined by work item records open in the Salesforce console not record ownership. Closing the tab for a Lead record has the effect of setting the related AgentWork record status to closed.

Salesforce Spring ’16 Platform Highlights

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.

Butterfly16

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.

Developer Console - New Suite Run

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.

Platform Health Check

Process Builder Apex Actions

A technical best practice in the Salesforce domain is to employ Apex code predominantly as an enabler for the declarative platform capabilities. This light-touch approach is simple in concept; the minimum amount of Apex code necessary is introduced to enable non-technical build features to solution the functional requirement. In the majority case this works very well and provides a strong maintainability story. In more complex scenarios complete technical solution options can be warranted and are perfectly acceptable, but one should always preclude the Apex-as-glue approach first.

In practice this model can be challenging to implement. The solution design process must be driven by individuals who are both expert in the current-release declarative capabilities of the platform and have the skill and experience to deconstruct a requirement into a structured solution design composed of declarative and technical components. Typically functional experts revert to technical solution options as a last-resort and don’t always think in terms of blended solutions. Salesforce technical resources don’t usually have a deep understanding or practical experience of the functional capabilities of the platform – some do, most don’t consider this a development concern or don’t have the opportunity to build skills in this area.

The recent introduction of the (Lightning) Process Builder with its ability to invoke Apex Actions (via the InvocableMethod annotation) provides a powerful shared language between functional and technical perspectives, enabling a clear decomposition of functional and technical solution components. To elaborate on this, process automation solutions can be implemented (i.e. Processes) that are comprised of declarative functionality but also with delegation to Apex code where gaps exist. In other words a clear exemplar of the model described previously. Adding parameterised Apex Actions in this context enables declarative configuration of the technical component and removes the black-box issues related to Apex Trigger components etc.

The screenshot below shows an Apex Action invocation within the Process Builder design environment.

Process Builder - Apex Action

In consideration to the concept of Processes (or indeed Flows – the technology that underpins Process Builder) invoking Apex Actions, a new development paradigm becomes possible, one that avoids black box, inflexible Apex Triggers and places control and configuration in the hands of non-technical resources (business analyst, administrator, app builder etc.).

From the development perspective Apex Actions should be coded as reusable, encapsulated components with flexible configuration (via parameters) and simply dropped into Processes as required. Note, Actions are also invocable directly from the REST API – a further point of potential for this approach. This component-based architecture should work well for all parties. The question of when to write an Apex Trigger or an Apex Action will be influenced primarily by factors such as whether the logic applies to all record modifications or is selective and whether bulk operations must be supported at default batch sizes – at the time of writing there are governor limit considerations with Process Builder that should not apply to correctly written bulk-safe Apex Triggers.

Platform Cache – Salesforce Winter ’16

This video post provides a technical overview of the Platform Cache feature added in the Winter ’16 release.


Custom Metadata Types – Salesforce Winter ’16

1 Create New Custom Metadata Type

This post provides a high-level overview of the Winter ’16 enhancements to the Custom Metadata Types platform capability.

Custom Metadata Types – The App Configuration Engine for Force.com

There are in my view two distinct ways to consider Custom Metadata Types (CMT); firstly as analogous to Custom Settings and secondly as an architecturally significant paradigm shift in regard to platform extensibility. In the former case CMT can be viewed as a straightforward, almost like-for-like replacement to List Custom Settings – with the added benefit that records can be deployed as metadata. There are of course considerable differences between the two, however conceptually this view is simplistic and approachable. In respect to the latter case, prior to CMT platform extensibility for Force.com could be viewed as a vertical model where new instances of pre-defined metadata types are created to deliver custom interactions. Custom Metadata Types enable a horizontal extensibility model where new type definitions can be introduced and instances created as metadata. The platform is no longer constrained to the pre-defined set of metadata types, developers have freedom to extend the model and deploy both the types and instances freely across environments. This horizontal extensibility model enables a host of new use cases such as bespoke development frameworks that abstract or extend the Force.com platform, an idea variously described as Platform-on-a-Platform or Custom Platform.

Custom Metadata Types were introduced as a beta release in Spring ’15, with the GA release in Summer ’15. The enhancements added to Winter ’16 appear to represent another milestone on the journey toward an increasingly capable platform extensibility model where custom types can be related to standard types, perhaps to override or extend platform behaviour. This is definitely a key area of the Force.com platform to pay attention to over subsequent releases.

Note, the native user interface for Custom Metadata Type administration shown in the following screenshots is a new Winter ’16 feature, previously Metadata API calls were required to define types and manage associated records.

Key Concepts

Metadata Type
As the screenshot below shows, Custom Metadata Types support Custom Fields and Page Layouts, all very consistent with the Custom Object and Custom Setting equivalents (although not layouts in the Custom Setting case). At this point it’s worth considering the fact that all standard metadata types are comprised of a collection of attributes, for example an ApexClass has Name, Body attributes in the same way a CustomField has Name, Label, DisplayType attributes. This is how Force.com platform metadata is structured. The difference between a CMT and a Custom Object or Setting isn’t the definition it’s the type of data stored; with a CMT we’re recording metadata. Taking a somewhat obscure example, we could invent a new proprietary platform language called Opex (;-)), define a CMT called OpexClass with a Body attribute etc., populate it with metadata records that represent a System namespace and ship some actual ApexClass instances to translate and run the Opex code. I’ll concede this isn’t a practical example, however the point I hope should be clear.

2 Custom Metadata Type

The protected component attribute applies to Managed Packages; meaning visibility of the CMT in a Subscriber org.

When defining a new CustomField for a Custom Metadata Type, there are limitations to the field types that can be specified and as-per Custom Settings there are no picklist or relationship fields (as yet anyway).

3 New Field

Field Manageability is a new concept in Winter ’16 to understand, again in relation to Managed Packages. In short this setting provides field-level editability control, selectable values being:

Locked after release : Field value is locked after deployment (includes the developer org).
Subscriber editable : As the name suggests; deployed (developer) updates will not override subscriber field value changes.
Upgradable : Locked in the subscriber org, developer can edit and deploy upgrades.

4 Custom Metadata Type with Fields

Metadata Record
A Metadata Record is really where Custom Metadata Types head off on their own path; a Metadata Record as the name implies represents an instance of the metadata type as a record that can be manipulated by the Metadata API, deployed via Change Set and packaged. The significance of which is obvious but incredibly powerful. It becomes possible, for example, to track Metadata Records using Source Code Control tools and to deploy metadata plus configuration via a single deployment transaction. No more, 2 stage deployments or clumsy post-install data loading.

5 New Metadata Record

As can be seen in the preceding screenshot it is possible to define a Protected Component setting at the Metadata Record level. This enables the type to be public but records to be selectively hidden in the subscriber org – a very flexible capability.

6 Metadata Records

Key Benefits

As mentioned in the introduction the Custom Metadata Type platform feature is still emerging, in my view at least, the most interesting aspects are potentially yet to be revealed, however there are definitely some key benefits to highlight with the Winter ’16 release.

For Enterprise : Manual steps within an otherwise automated Application Lifecycle Management process can cause compliance issues and release management inefficiency. Custom Metadata Types enable application configurations to be deployed as part of a seamless, one-step deployment process thereby removing manual friction. Configuration management tools can also track and version control the application definition and its configuration state.

For Partners : A long time issue for ISVs has been the deployment of application configuration data as part of the managed package installation process. Post install scripts provide one option, but creating data via Apex script doesn’t scale well or deliver the required fine-grained control over subscriber org configurability and upgradeability. Custom Metadata Types address both issues.

The screenshot below shows both a Custom Metadata Type and Metadata Records added to a Managed Package definition.

7 Packageable

Note, the benefits stated above are those practical benefits of the capability in relation to its generic capability, the actual benefit for many developers will be the flex

Implementation Considerations

Audit trail : Changes to both Custom Metadata Types and Metadata Record are visible via the Setup Audit Trail, this is new to the Winter ’16 release.

8 Audit Trail

Metadata Record Access : Metadata Records can be accessed via SOQL query only, there is no direct Apex support. Note the __mdt suffix.

Widget__mdt[] widgets = 
 [select QualifiedApiName, Height__c, Width__c from Widget__mdt];

Metadata Record Modification : Custom Metadata Types do not support DML operations via Apex, the Metadata API must be used. For use cases where configuration data needs to be created via code, CMT may not be an effective approach.

Relationship Fields : At some stage (Spring ’16 perhaps) in the future evolution of Custom Metadata Types I would expect support for relationships to be provided. This I believe is where the feature will really take-off.

Apex Testing : Currently Metadata Records are visible in Apex unit tests (without SeeAllData=true), it’s likely that simulated test data will be supported in a future release to enable testing under different configurations.

Permissions : The permissions model for Custom Metadata Types is limited, the Metadata Records are either visible or not at the org-level. A finer-grained permission model, perhaps just at the record level would be an obvious progression.

References

https://developer.salesforce.com/blogs/engineering/2015/08/custom-metadata-types-winter-16.html

https://help.salesforce.com/HTViewHelpDoc?id=custommetadatatypes_overview.htm

http://releasenotes.docs.salesforce.com/en-us/winter16/release-notes/rn_forcecom_development_custom_metadata.htm

Salesforce Winter ’16 Platform Highlights

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.

winter release

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.

Lighting Experience Record Detail Page

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.

Platform Cache Setup Page

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.

Salesforce Standard Reporting (3 of 3) – Best Practices

This final post in the Salesforce Standard Reporting series outlines a selection of best practice concepts and techniques to be considered in the delivery of on-platform reporting solutions that maximise the value of the standard reporting tools.

The key message of this series is simple; a solid understanding of how the Salesforce standard reporting tools work in practice, and the reporting patterns supported, can avoid the necessity to employ additional, expensive off-platform reporting tools. The earlier this thinking is applied, the greater the likelihood of success.

Best Practice Considerations

In no significant order, the following points provide a non-exhaustive selection for consideration.

  • Solution Design
  • Perhaps the most obvious point, but equally a common oversight, is the consideration of key performance indicators during the solution design phase. This approach shouldn’t entail a full coverage of all reporting requirements; instead a selection of exemplar reporting use cases that represent a broad set of required outputs should be documented in clear concise terms and factored into the overarching solution design. This early consideration mitigates the inherent risk of the classic “reporting workshop” held once the solution design is no longer emergent; the impact of which can often be the introduction of off-platform reporting solutions with their cost and security implications.

  • Data Model
  • A Salesforce data model, in physical terms, will not necessarily comply to standard relational database normalisation principles, other factors must be considered. The sharing model is one such consideration, where record access or indeed object access permissions mandate a deviation from the standard 3rd normal form. Reporting is another significant area of consideration; constraints in respect to the depth of object relational hierarchies and the ability to traverse parent-to-child relationships must be accommodated within the data model design to maximise the potential of the standard reporting tools. Techniques in this regard include reporting convenience lookups, which are added to bridge parent-to-child and sibling relationships, and restructuring hierarchical data to limit the depth of hierarchy to four levels.

  • Sharing Model
  • The standard reporting tools fully respect the implemented sharing model and as such a complex, over-specified sharing model design can inhibit the potential use. The sharing model design often reflects the transactional processing requirements for record visibility, but not necessarily the reporting need. To avoid creative workarounds during report production it is imperative that the sharing model design reflects both the former and the latter requirements.

  • Report Types
  • Standard Report Types are maintained by the platform and require zero administration, new fields are exposed automatically. As such, wherever possible build reports using standard report types. Custom Report Types require ongoing maintenance, but can be highly useful in providing a clear data-set for a focused purpose or where the standard report types are insufficient. The implementation of a limited number of complementary custom report types with clear descriptions that adhere to a strict naming convention is the best practice approach. A standardised approach here promotes re-use. A typical implementation for reporting on the Salesforce platform involves end-users developing their own reports, for this to work efficiently they should be provided with a clear set of intuitive report types upon which to work.

  • Conventions
  • Given that reports are often developed by business users and not administrators or developers, it can be challenging to maintain an ordered state. To mitigate this risk, a strict naming convention and structure should be adopted for report folders and exemplar reports should be provided that exhibit a standardised approach to report naming (and description). It is a best practice to conduct periodic reviews of the reporting environment with the business users to ensure standards are applied, inefficiencies are avoided (such as duplication), platform features are being exploited optimally and ongoing training requirements are identified and addressed.

    Folders

  • Art of the Possible
  • Clear communication in regard to the capabilities and constraints of the standard reporting tools is imperative to the successful implementation of a reporting solution. A demonstration environment configured with contextualised reports and dashboards which showcase the art-of-the-possible can be an effective communication tool. Business users and the project team should have access to the demo org to explore the possibilities and to establish their own frame of reference.

    This approach can aid understanding (and therefore increase usage) of less obvious concepts such as historical trend reporting, reporting snapshots, dynamic dashboards, dashboard filters and joined reports.

  • Visibility
  • A common oversight in the implementation of an effective on-platform reporting solution is the visibility of reports. Reports should not be hidden away on the Reports tab, instead all possible entry points and display options should be considered as part of an overarching report visibility model. Examples in regard to entry points include custom links and buttons on detail pages, perhaps with some level of parameterisation. Examples in regard to display options include report charts added to detail pages (Embedded Analytics) and console sidebars (Summer ’15 feature). A further consideration is the inclusion of report charts in Visualforce pages (via the reportChart component), this approach avoids the requirement to address the underlying data directly in Apex code where the reporting engine can be applied.

  • Collaboration
  • Reports and analytics can provide important data visualisations and business insight that should serve as the basis for employee collaboration. An effective Chatter implementation model should therefore encourage communication and sharing around reports and dashboards such that the internal conversation is captured.

    Dashboard Collaboration 1

    Dashboard Collaboration 2

  • Active not Passive
  • Reports and analytics are typically implemented to deliver outputs in a passive state, i.e. the report runs on-demand or by schedule and the output is provided. A final best practice to consider is the active state where report outputs are evaluated against defined conditions and action (email, post, Apex script etc.) is taken automatically. Reporting Notifications provide active state options that can be a powerful tool in reducing report-noise and driving actions proactively from significant data conditions.

    Notifications

Salesforce Deployment with Ant

This first video post provides a brief introduction to scripted Salesforce deployment with the Force.com Migration Tool and Ant.