Salesforce Test Driven Development

I’ve been fortunate to have worked as a consultant Salesforce architect for the last decade, during this time I’ve encountered an interesting variety of approaches to Agile in the Salesforce space – most of which fitting with the hybrid model unfortunately – what has been noticeably absent is the application of agile engineering practices. Test Driven Development (TDD) is one of most widely understood agile engineering practices (alongside Pair Programming) – and is perhaps the most practical to adopt, however despite the benefits, despite the level of lip-service paid to the subject in practice TDD remains a rarity. With this post I hope to provide a convincing argument to Salesforce developers and architects that TDD does not add overhead to the development lifecycle and in fact the opposite is true. The Salesforce platform in development terms is maturing, the introduction of new tools and techniques such as Salesforce DX (SFDX) are testimony to this. In this context, the idea of developers working ad-hoc and in an undisciplined manner doesn’t fit, instead the consistent application of established engineering practices will play a key role moving forward. No more low quality unit tests (written as an afterthought) and no more random coding conventions and inconsistent standards. Salesforce development teams can no longer choose to hide in the void that sits between declarative development and traditional software engineering, it’s definitely time for some new habits.

This blog post draws together a high-level conceptual view of Test Driven Development with the implementation practicalities unique to the Salesforce platform.

Let’s start with great quote to set the scene.

Build it right to build the right thing“, Ron Jeffries. The concept is simple; build the product right, repeat until it’s the right product.

Test Driven Development

Test Driven Development is an XP agile engineering practice. eXtreme Programming (XP) is a software development methodology focused on customer value, continuous feedback, incremental feature delivery and team empowerment. It is a widely recognised fact that the earlier testing is applied in the software development lifecycle – the greater the value (shorter development timescales, more reliable code etc.). TDD takes this idea to its ultimate conclusion where testing occurs in front of actual coding. This may seem counterintuitive. In order to understand the impact of this fully it’s important to understand the high-level approach.

(1) Identify a low-level requirement (PBI, Task etc.)
(2) Describe the logical tests necessary to confirm that code satisfies the requirement
(3) Write the minimum code necessary to pass the tests
(4) Tidy-up the code to remove clutter, complexity and duplication

The steps above describe a design process where software evolves in very small increments with a focus on simplicity and testability. This step-by-step approach results in emergent design, where the code informs the design approach and guides the developer toward the best solution. This is the direct opposite of the traditional big-design-upfront (or BDUF) approach. The goals and benefits of TDD are many; “clean code that works” is a phrase that best summarises this (another golden Ron Jeffries quote). Note, TDD is often referred to as Test Driven Design in recognition of this emergent design side-effect.

TDD Cycle

It is imperative to understand the conceptual aspects of TDD in order to gain the full benefits, thankfully the practical application follows a relatively straightforward and approachable 3-stage cycle (Red-Green-Refactor).

Stage 1 – Red : Write the minimum code needed for a failing test. This may entail development of (or extension to) a test harness, plus the unit test code required to exercise the logical test case. The test code could be completely new or simply an augmentation to existing tests. In writing the test code the developer is forced to think through the requirement in detailed, logical terms – the type of thinking more typically applied at a later stage when writing the functional code.

It is imperative that test code evaluate predictable logical test conditions. The test code should fail for a specific, expected reason – not due to a test harness issue or due to the fact the test code itself is invalid.

Stage 2 – Green : Write the minimum amount of code needed to pass the test. The code written here must satisfy the test condition and nothing more – no embellishments.

Discipline is required to avoid the developers innate tendency to create.

Stage 3 – Refactor : The functional code should be reviewed and modified to remove clutter, complexity and duplication. Code should work (of course) but also (critically) be readable, updateable and testable.

Clean code is the objective here; if every tiny incremental addition of code satisfies the clean code criteria (readable, updateable and testable) the outcome will be a highly organised and easily maintainable code base that can be extended with new features at a consistent level of effort over time. Where such an approach is not applied it is often inevitable that a complete re-write becomes necessary once the steadily increasing incremental cost (time) of adding new features becomes intolerable.

The TDD cycle then repeats over and over until all requirements are addressed. The incremental design approach focuses upon each individual requirement one at a time. This minimalist, simple design lead approach can be difficult for experienced developers to adopt, however once the learning curve is addressed the focus on simpler designs allows easier modification, more efficient testing and faster production.

TDD in the Salesforce Context

The Salesforce (or cloud platform is an ideal software development environment in which to adopt the Test Driven Development (TDD) agile engineering practice. The Apex programming language has integrated unit testing capabilities which reduce the level-of-effort required. Salesforce Developers are also accustomed to the idea that code requires a (platform enforced) test coverage level of 75% for production deployment. In the Salesforce development context therefore the tools are provided and concepts relating to unit test development well understood. The only challenge remaining is the mind-set shift from big-design-upfront and retrospective test code development to TDD and the agile benefits of emergent design, clean resilient code and reduced development effort.

Unit Testing on the Salesforce Platform

An Apex class can be easily annotated (@isTest) to indicate its role as a unit test class. The snippet below shows a very basic example.

private class FeatureTestClass {
  @testSetup static void setup(){ 
    // populate custom settings.
    // create test data used by all tests.
  /* **/
  static testMethod void isAccountProcessed() {
    // setup test specific test data and context
    insert new Account(Name='Acme Inc');
    // do something
    // test outcome        
    System.assertEquals(1, [select count() from Account where IsProcessed__c=true]);               
  /* */

The [SeeAllData=false] flag indicates that only test data created by the class is visible to the test method (plus some actual data; products, users etc.). There are circumstances where the flag must be set as [SeeAllData=true] flag, where test code is unable to create required test data due to object access permissions. The isTest annotation takes a second parameter [isParallel=true|false] which controls whether the test class can run in parallel with other tests (for expedient execution) or whether the behaviour requires serial execution (perhaps to avoid lock contention on shared resources such as custom settings).

Once a test class is implemented, adding individual tests becomes very straightforward. A standardised naming convention for the test cases can help the readability of the code; perhaps based on the expected outcome or the logical test case. Test code organisation at the class level should also be predictable and may follow a feature convention.

There are a number of methods available for the execution of test code on the Salesforce platform; Setup menu, Developer console and API (incl. IDE) as examples. Tests can also be executed asynchronously at a scheduled future time via Apex or the API (ApexTestQueueItem, ApexTestResult objects).

As the screenshot above shows the developer can configure a test execution to include all or selected test cases from multiple test classes. In the context of the TDD cycle the developer requires the ability to run just the one test case – not all, this would waste time.

Test Suites allow test classes to be grouped and executed together; this can be seen in screenshot below.

In the TDD context, where unit tests drive the development process it is important to have a clear naming convention defined for:

Test Case: expected outcome, or logical test case (readability is key)
Test Class: group of test cases relating to a given feature
Test Suite: group of test classes relating to a functional area

What is a Unit?

For the TDD cycle to be effective it can help to understand the level at which a unit test is applied. A unit is variably defined as the smallest testable part of an application, or the smallest change that still makes sense to be tested in the developer’s opinion. This of course is a subjective definition.

Common sense should be applied; a 200 line Apex trigger on Account will not be a single unit, a 20 field update on Contact also won’t be 20 units. Instead the feature being developed should be decomposed into a unit test per logical test case. This can take practice to get right, but striving to keep each test as simple as possible should be the primary guiding factor. Simple tests are easy to modify and provide a self-documenting benefit.

Advanced Unit Testing

The Apex language supports the advanced unit testing technique of Mocking which enables isolation of test execution from external factors such as API callouts or Salesforce configuration changes.

Mocking essentially involves the non-disruptive, dynamic substitution of a test specific class instance in the place of a functional class instance. Apex provides the HttpCalloutMock interface to allow test code to utilise pre-fabricated Http callout responses. The Stub API (StubProvider interface and Test.createStub method) supports the development of Mocking frameworks that enable any class to be substituted dynamically at runtime.


Apex Developer Guide > Testing Apex

Ron Jeffries Blog – All things XP and much more

Martin Fowler – All things Code Refactoring and much more

Apex Debugger

A quick video post providing a demonstration of the interactive Apex Debugger. The context of the demonstration is an ISV partner debugging a packaged code issue in a subscriber (customer) org.

Salesforce Spring ’18 Platform Highlights

Spring is once again upon us (in Salesforce release terms at least) this year we have a nice logo featuring the trailhead character Codey the bear practising the Japanese art form of Bonsai (I think).

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

The new release is available now for pre-release preview.

The release notes are available online here.

– features are GA if not indicated otherwise

Flow Design

Flow or Visual Workflow if you prefer, gains significant new capabilities in the Spring ’18 release. It’s clear how strategically significant Flow is for Lightning Experience in providing a rich declarative build option to balance the technical complexity of Lightning Component development.

    Key design features for this release include:

  • Stages (beta) – the ability to track progress through a flow interview via Active Stages and Current Stage resources.
  • Flow Local Actions (pilot) – the ability to call the JavaScript controller of a Lightning Component and therefore invoke script running client-side in the browser.

Flow Distribution

In addition to the various design related changes the new release also introduces improved execution options enabling tighter UI-level integration of Flow interactions. The most significant of these options is the ability for Flows to be auto-launched as Subtabs in the Lightning Console in response to an associated record being opened. The release notes describe this feature as Lightning Flow for Service – which implies some level of restriction in terms of supported objects to start with.

Einstein Data Insights (pilot)

Described as one-click data science this new feature enables standard report data to be analysed to provide key insights. The feature is invoked by a button within report builder and specific numeric fields can be targeted for analysis. This could be a very powerful new capability for Salesforce reporting with broad appeal, the proof of this will lie – of course – in the usefulness of the insights drawn which could be limited by the available data.


Toward the end of 2017 Salesforce introduced the impressive sounding Saleforce IoT Explorer Edition, a platform to process events from connected devices in near real time. With the Spring ’18 release a new REST API is added to enable manipulation of the various IoT components (orchestrations, traffic etc.). It would be great to see more information on this somewhat mysterious edition; who’s using it and for what specific use cases.

Lightning Console – Pinned Regions

Previously available as Salesforce Classic feature, pinned regions are now available in the Lightning Console. 3 new templates are now available in the Lightning App Builder (e.g. Console: Pinned Header and Left Sidebar). Pinned regions provide an effective tool in composing optimised agent experiences that reduce the dreaded click-count.

Change Data Capture (pilot)

The Winter ’18 release introduced a pilot for Change Data Capture – a new data integration technology to support ongoing synchronisation of external data via an event bus. In short the client subscribes to a channel and receives published changed data events relating to record creation, modification and deletion operations taking place on the Salesforce platform. Spring ’18 adds Activity and PersonAccount objects plus Gap events (background process changes not normally published) and Overflow events (for high volume cases where the 10K change per transaction limit is exceeded). CDC offers a robust and scalable alternative to the data synchronisation capabilities of the SOAP API and also Heroku Connect.

Data Protection and Privacy

An obvious theme of the Spring ’18 release is Data Protection; with the European Union General Data Protection Regulation (GDPR) coming into effect in May 2018 (plus other equally significant regulations on a worldwide basis becoming more prominent) platform changes have been made to aid compliance and specific guidance provided for all business in respect to the processing of customer data.

    Key data protection and privacy features for this release include:

  • Individual Object. A new standard object for storing data privacy preferences that relates to Lead or Contact (or PersonAccount). The Individual object supports custom fields, validation rules, triggers etc. to enable full customisation as required for compliance with applicable regulations. In the previous absence of a standard approach to privacy data, many organisations have added custom objects, fields etc. for this purpose. For less forward thinking organisations data protection compliance has just become slightly easier to approach.
  • Contact data for customers in the UK and Ireland have been removed from Connect. In simple terms, for GDPR compliance such customers would require an explicit opt-in with reason etc. for processing.
  • Inbox Read Receipts can be turned off; to protect customer privacy.
  • Event log deletion.

Salesforce Surveys

A new Survey Component enables rapid development of User or Customer facing surveys. In short the Component is embedded in a Lightning Page and surfaced internally for Users or via Community to Customers (public or private).

The new Survey tab provides access to the Survey design environment.

Surveys can be previewed to test the runtime experience.

Surveys introduce new standard objects.

Action Overrides by Experience

Object overrides can now be set individually for Salesforce Classic and Lightning Experience, a huge improvement where both experiences are in use; which is the majority case.

Time Data Type (public Beta)

The highly useful Time field type moves from private to public beta in Spring ’18. Where time values need to be tracked outside of a given date, this new field type will be invaluable. Interesting that it’s taken until 2018 for such an obvious data type to make an entrance.

Salesforce Winter ’18 Platform Highlights

It’s that time of year again where summer is gently transitioning to autumn and the winter (in salesforce release terms) is on the horizon. Winter is coming – seems familiar as a phrase – starting late September (for instance details refer to Now more than ever before there’s no excuse not to be fully prepared, the available release readiness resources are considerable, including a Trailhead badge, videos, webinars etc. a great place to start is the customer success community. Those of an inquisitive mind can also participate in the Winter ’18 treasure hunt where release explorers are encouraged to post discovered features to Chatter and Twitter with the #Winter18Treasure hashtag.

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

The new release is available now for pre-release preview.

The release notes are available online here.

– features are GA if not indicated otherwise

Lightning Experience UI Changes
The Lightning Experience UI has evolved in the Winter ’18 release, no doubt in response to customer feedback and usability studies. The main issue that has been addressed is the sense of snow-blindness resulting from a lack of contrast between the page content and background elements. Other improvements include increased list density (more on a page) and page legibility (typography changes). In recognition that work will be required to align custom Lightning components to the new look, a new setting is provided to control activation (Setup > User Interface > Themes and Branding).

The screenshot above shows the new contrast between the background – now a blue image – and the foreground content.

Salesforce Developer Experience (SFDX) will move from Beta to GA status for the Winter ’18 release (specifically mid-October 2017). This includes the Visual Studio extension “Salesforce Developer Tools for Visual Studio Code” which provides a VS code editor for developing on the Salesforce platform using the Salesforce DX development flow.

I don’t see any new DX functionality specific to the Winter ’18 release, however there is a new beta for Second-Generation packaging; where the artefact=based (not org-based) model is extended to a new packaging approach – I assume.

Einstein Language API Beta
The Language APIs form part of the Einstein Platform Services API set and support natural language processing use cases such as intent (product interest, case/lead routing etc.) and sentiment (positive, negative and neutral) analysis.

The technical detail for the Einstein Platform Services APIs can be be found here.

New Base Lightning Components
Base Lightning Components are pre-built SLDS versions of common elements (buttons, labels etc.) intended to streamline and accelerate lightning development. Since release in Winter ’17 new base components have been added to extend the library. Winter ’18 adds an impressive 30 new components examples being accordion, data tables and notifications.

Salesforce Shield – Deterministic Encryption Pilot
Shield Platform Encryption has been extended to support filtering scenarios such as reports, list views and where clauses in SOQL queries. In addition to the existing Probabilistic encryption scheme, fields can now be set with the new deterministic encryption scheme which allows such encrypted fields to be filtered.

Lightning App Builder – Dynamic Pages
Filter conditions can now be set on Lightning Page to determine when a given component is rendered.

As the screenshot above shows individual Component Visibility can be controlled using compound filter logic driven dynamically from the record attributes.

Platform Events; Process Builder and Flow
Previously invocation of a Process Builder Process was limited to chaining and object data events, with Winter ’18 this is extended to include Platform Events.

Platform Events are part of the Salesforce enterprise messaging platform intended to support event-driven (or messaging) architectures. In simplistic terms a Platform Event is defined as a special type of custom object with a __e suffix. Events are inserted to the object from external publishers via API or Apex. Event records in a Platform Event can’t be edited, deleted or viewed in the Salesforce UI. Triggers on the object then consume the event and apply the required logic. With Winter ’18 Process Builder and Flow can now perform the event consumption instead of Apex.

Business Contact Sharing
Prior to Winter ’18 activation of Person Accounts (for B2C implementations) required that the Contact object inherit sharing from the parent Account. For a Person Account this makes sense, logically the records are unified. For Business Accounts however this approach can be problematic as often Contact sharing behaviour is required to be more granular. With Winter ’18 this sharing constraint is removed and Business Contacts have a distinct org-wide default setting when Person Accounts are activated.

Apex isParallel Annotation
The new @isTest(isParallel=true) annotation overrides the default “disable parallel test execution” setting and provides greater control over the level of concurrency applied during test execution. In many cases locking conflicts on Custom Settings can require the full set of unit tests to run synchronously where only a subset are affected. This new annotation will allow unaffected test classes to run in parallel.

ISV – Feature Parameters
Feature Parameters will be GA mid-October 2017 on. The Feature Management App (FMA) extends the License Management App (LMA) to allow control over individual features within specific Subscriber orgs. New features can be introduced and enabled for select customers before general release etc. Feature Parameters are defined in the packaging org (via Metadata API types) and referenced by packaged Apex code using the System.FeatureManagement namespace methods.

Salesforce Summer ’17 Platform Highlights

The Summer Salesforce release is once again upon us, sporting this time a seasonal Seagulls release logo. As someone who lives by the sea I’m no fan of the noisy gull – so this logo isn’t a favourite, I’d have voted for the Sunscreen release logo option personally. That said, the logo animation within Lightning Experience does work well.

Quick fun fact – there is actually no such bird type or species as the seagull or sea-gull – the correct term is gull. Our friends in the sunglasses are probably common gulls. Anyway I digress.

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

The new release is generally available now for pre-release preview.

The release notes are available online here.

– features are GA if not indicated otherwise

Visual Workflow – Field Rules (Pilot)
Field Rules enable conditions to be defined for a given UI input that control the setting of visible, hidden, required or optional attributes. Enabling the UI composition and interactions to be data-driven allows guided journeys to be implemented in Flow with better user experience characteristics than was previously possible. Flows are a great tool for developing custom UI in Salesforce and can remove the requirement to develop complex Lightning Component based interactions in LEX. There are additional capabilities in the Summer release for launching/embedding Flows within Lightning Pages (screenshot below shows the Flow component). It seems clear that extending the capabilities of Flow is seen as mitigation for the complexity/time/resource challenges of Lightning Components over Visualforce.

Einstein Vision
Einstein Vision is a REST API that offers image recognition capabilities such as visual search, brand detection and object identification via custom or pre-trained classifiers. An Einstein Platform Account is required to access the API (signup here), which offers 1,000 free predictions per month. Full detail of the API can be found at

Einstein Data Discovery for Salesforce Wave Analytics
Einstein Data Discovery performs automated analysis of an ingested dataset to provide natural language answers, explanations and recommendations leading to predictive actionable insights. The tool enables automated, unbiased analysis of scenario patterns as below.

What happened?
Why did it happen?
What will happen?
What should I do about it?

Results and recommendations can be exported to Wave Analytics or a Salesforce object for reporting purposes. Further detail is provided in this datasheet.

Deploy and Retrieve Metadata via Apex
A new Metadata namespace enables metadata manipulation directly from Apex script. This release is limited to Custom Metadata Type records and page layout metadata types which reflects a focus on use cases around development of custom configuration UI. Hopefully this is just a starting point and consistency with the Metadata API will ultimately be achieved.

Advanced PDF Rendering (Pilot)
Advanced PDF rendering provides support for the CSS Paged Media specification which adds functionality for pagination, margins, page size and orientation, headers and footers and image orientation. To configure a Visualforce page for advanced rendering the attribute setting renderAs=”advanced_pdf” is required. Visualforce is not an ideal solution for document generation, it is nonetheless a popular approach – so improvements to the layout handling will be widely appreciated.

Subscribe Other People to Reports (LEX-only)
Reporting Subscriptions were previously configured by the end-User on a one-to-one basis. In my view this implementation approach limited the use of this capability in addressing requirements for proactive notification. In the Summer ’17 release one user can configure a report subscription for multiple users – as shown below.

Lightning Console JavaScript API (Pilot)
Programmatically control Tabs, Subtabs and the Utility Bar in the Lightning Console from JavaScript within Lightning Component controller code. This API is the direct equivalent of the Console Integration Toolkit for the Classic Console.

Omni-Channel in Lighting Experience (Beta)
Omni-Channel support has been added to the Lightning Console to allow Agents to accept/reject routed Work Items and to set their Presence Status. The Omni-Channel Supervisor view is not yet supported which is unfortunate given how much functionality this relatively new feature adds. Live Agent Chat and SOS routing is not supported as the underlying features are not yet Lightning ready. Active time tracking is also absent in this release.

Omni-Channel External Routing (Beta)
There is little information available on this one, however it appears that Queues can be configured for either standard Omni-Channel routing or to delegate routing to an external source via API. This could be incredibly powerful where routing decisions rely on off-platform data or cross system boundaries.

UI API (Developer Preview)
The previously named Lightning UI has been renamed to the UI API, which makes sense. This API provides UI centric, composite responses intended for the efficient composition of UI.

Salesforce Selective Queries

A basic understanding of the selective query concept is fundamental to scalability on the Salesforce platform. Non-selective queries have a significant performance impact on List Views, Reports and SOQL and can often result in Apex Trigger runtime exceptions as below – as the data volume increases over time.

System.QueryException Cause: null Message: Non-selective query against large object type (more than 200000 rows)

SOQL queries executed from Apex Triggers have to be selective where the record count in the queried object is 200,000 or more. The determination of a selective query is a function of volume plus field-level selectivity. It is therefore the case that the selectivity state of a given query is volatile meaning in practical terms that the initiating Apex Trigger may work one day and not the next.

Selective Query Definition

Selectivity is determined by the index state of the query filter conditions and the number of records the filter returns (selectivity) versus the object total records. The thresholds below show the difference between the selectivity calculation for a standard index versus a custom index.

Selectivity Thresholds:
Standard Index – 30% (first 1M) then 15%
Custom Index – 10% (first 1M) then 5%

Unary filter:

e.g. select Name from Account where IndexedField__c=’ABC’

With a custom index on IndexedField__c the filter must return <10% of the total records in the object to be considered selective – up to the first 1 million records from that point the threshold drops to 5%.

Multiple filters AND (exclusively):

e.g. select Name from Account where IndexedField__c=’ABC’ and SecondIndexedField__c=’123′

The Query Optimiser will set the leading operation on the basis of lowest cost. If no filters are selective a table scan is performed.

If all filters have an index then a Composite Index Join optimisation can be applied.

In this case each filter must be less than 2x (two-times) the selectivity threshold.
All filters combined must be less than selectivity threshold.

If all filter fields are standard then use the standard index selectivity threshold – otherwise use custom index selectivity threshold.

Multiple filters OR (at least one):

e.g. select Name from Account where IndexedField__c=’ABC’ or SecondIndexedField__c=’123′

Selective AND filter indexes could be set as the Leading Operation – if none exist, then a table scan occurs unless all filters have an index then a Composite Index Union optimisation becomes possible.

In this case each filter must be less than selectivity threshold.
All filters combined must be less than selectivity threshold.

If all fields are standard then use the standard index selectivity threshold – otherwise use custom index selectivity threshold.

Parent Field Filter:

e.g. select Name from Contact where IndexedField__c=’ABC’ and Account.IndexedField__c=’ABC’

Where parent object fields are referenced in a filter, each filter index is individually and the lowest cost option selected as the leading operation.

Note, the parent field is not indexed on the queried object, so Account.Id can incur a table scan on Opportunity whereas AccountId may allow the standard index to become the leading operation.

The notes above provide a basic outline of the concepts but should be sufficient to convey the key concepts.


Implementation Approach

As data volumes grow query behaviour can change dramatically, to mitigate this database queries originating in Apex code, list view and report definitions must consider the future peak data volume and field-level data characteristics (primarily selectivity). This considered approach can help identify an appropriate indexing strategy that maintains query performance by ensuring query selectivity. So, forward planning is absolutely key; queries should be designed to be selective up to the projected peak data volumes. Thinking ahead to this extent is very seldom applied in my experience, particularly where the Salesforce implementation evolves project-by-project and the longer term picture is not a priority.

In order to evaluate the selectivity of a given query – the following 2 approaches can be applied.

REST API Query Resource Feedback Parameter

The REST API exposes a Query resource that accepts an explain parameter which can set with a SOQL query, List View Id or Report Id. The results show the options considered by the Query Optimiser and the lowest cost option (leading operation) taken. A relative cost value of less than 1 indicates a selective query, anything higher indicates non-selective. The example below shows the output for a report where a report filter hits an indexed field.


Developer Console Query Plan

From Summer ’14 on the Developer Console can be enabled [Help>Preferences>Enable Query Plan] to display a Query Plan option on the Query Editor tab. The construct of the output is the same as the API approach. Note, this appproach is limited to SOQL queries.


The references section below provides link to the technical detail of the 2 approaches introduced above.



Query & Search Optimisation Cheat Sheet

Developing Selective Queries through the Query Resource Feedback Parameter Beta

Developer Console Query Editor

Improve performance with Custom indexes using Selective SOQL Queries

Custom Index Request Checklist

Salesforce Spring ’17 Platform Highlights

Accompanied by a huge (472-page) release notes document, the Spring ’17 release rolls out in early February. For perhaps the first time (to my recognition) a Lightning Experience (LEX) only theme is identifiable across the newly introduced set of features. This isn’t exhaustive but interesting nonetheless as historically any functional disparity typically favoured Salesforce Classic. Adoption rates for LEX will certainly be one-factor behind this approach, it’s also not surprising to see investment going into the future platform. What this does underscore is the growing status of Salesforce Classic as a legacy platform despite the high proportion of implementations yet to transition.

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

The new release is generally available now for pre-release preview.


– features are GA if not indicated otherwise

External Services (Beta / LEX-only)
This new LEX-only feature provides a non-programmatic method for invoking external web service operations. The external service is registered (via JSON Schema) which generates proxy/wrapper Apex classes that can then be introduced into Flows which encapsulate the required business process automation. It will be interesting to see the code generated by the registration process, this could be a useful convenience irrespective of whether Flow is being. As a huge advocate of Flow (or Visual Workflow) it’s great to see investment that enables additional use cases. I’m slightly sceptical about non-technical treatment of API consumption scenarios, but that said anything that reduces the requirement for code should be a good thing.


Data Integration Rules Clean Rules will be replaced with a generic framework for the definition of Data Integration Rules provided by external parties. Some rules will incur a cost, others such as the Geocode Address rules are free-of-charge. The term integration in this context relates to data enrichment i.e. a rule updates mapped fields on a given record from an external data source. The update can occur on-demand per-record or en-masse via data refresh (note, the Geocode address rule does not support data refresh). The ISV side of things isn’t clear at this stage in respect to publication of new Integration Rules.

External Data – Cross-org Adapter for Salesforce Connect
The REST API based Cross-org adapter for Salesforce Connect now supports write operations. Given the cost implications of this approach it will be interesting to see how much traction this gains – Salesforce-to-Salesforce whilst technically very different (data synchronisation etc.) does address the same set of use cases without the additional licence cost.

Lightning Console Apps (Beta)
Spring ’17 delivers a beta version of Lightning Console Apps. As one would expect Sales and Service standard console apps are provided plus the ability to define a custom console app. New Lightning Components (Related List, Related Record) and a Lightning Page Template (3 columns) are provided to enable implementation of console record detail pages comparable with Salesforce Classic. Given the beta status, lack of migration path and the number of omitted features it’s unlikely that customers will view this as a viable option right now, however now is the time to start thinking about a transition later in the year. Clearly compatibility with Omni-Channel, telephony solutions etc. will be fundamental to such planning.


Lightning App Builder
The Lightning App Builder gets a serious overhaul in Spring ’17 with a new UI structure, additional templates, page cloning and the ability to assign record pages by app, record type and profile being the feature highlights. The latter point being key to delivering a customised experience across users and business processes.


Lightning API (Developer Preview)
The Lightning API is a REST API targeted at custom development use cases (mostly but not exclusively mobile) where the response payload can include data, metadata and layout information. Clearly the value-add here is efficiency – one API call to retrieve all the information that should be required to build the requisite UI/interaction. It should be noted that the API is rate-limited and will return a 503 if the limit is reached; careful client-side cache control logic should reduce the risk of this happening.

Lightning Experience – Filter Reports via URL
At long last it is now possible to set field filter values for reports via URL in LEX. This simple capability has historically played a significant role in most implementations; custom links on report detail pages, bookmarked reports etc. Good to see another LEX obstacle removed.

ISV – Subscriber Org Debugging
ISV partners now have access to the ISV Customer Debugger, meaning for each LMO a single Apex Debugger session can be run at a time against a customer sandbox. The Apex Debugger runs in the IDE (i.e. eclipse) and provides enhanced support for code debugging; breakpoints, step into/over, call stack inspection etc. This powerful tool is normally a paid-for service – providing a free license to ISV partners will be well appreciated.

ISV – List Lightning Bolt Solutions
At some point after the initial rollout it will be possible for Salesforce partners to distribute Bolt solutions as managed packages listed on the AppExchange. A Bolt solution is prefabricated Community template typically targeting a vertical solution or providing a foundation for horizontal solutions such as booking/event management, membership etc. It will be interesting to see the traction for listed Bolt solutions over the coming months, I think the opportunity here could be significant for both ISV and consulting partners. Anyway it’s great to see the AppExchange now supported low-level Lightning Components and high-level Bolt solutions in addition to the standards Apps and Consultancy services.

Skype for Salesforce (Beta)
Check online status, chat and make audio/video calls directly within Salesforce. Chat transcripts can be saved as Notes. All useful and convenient functionality. A “Skype for Business” component can be added to LEX Pages via the Lightning App Builder. The component provides the same functionality for records with at least one email address field.

Kanban Views
List views now support easy switching between the default grid layout and the Kanban style visual layout. Custom Kanban settings and record types are also supported, the latter appear as tabs above the board.


AccountContactRelation Enhancements
The AccountContactRelation standard object which allows Contacts to be related to multiple Accounts receives further enhancement in Spring ’17. Relationships can now be defined between Person Accounts and Contacts, the object supports process automation (workflow, Process Builder etc.) and custom buttons, links and actions. I’m a big fan of this seemingly innocuous feature; great to see the additional capabilities being added each release.

Apex Stub API
The Apex Stub API provides a mocking framework for use in test code development. Typically mocks are used to isolate code for specific logical test cases or to allow streamlining of unit tests. Mocking frameworks are common to other programming languages, as such it’s great to have a standard approach for Apex.

Salesforce ISV Environment Strategy


Please note – This content was previously posted on the site directly and is re-published here as part of the consolidation of 2 blogs.

This post provides an overview of the various environments involved in delivering ISV solutions to the Salesforce AppExchange. As will be obvious to architects working outside of the ISV domain, the ISV environment strategy has some commonality to the non-ISV approach in respect to the development and testing activities but also introduces a further level of complexity and environment roles unique to the AppExchange distribution model.

Primary Org Definitions

Packaging Org

For small-scale, low complexity managed package developments the packaging and development orgs may be combined.

1. Package/Patch Upload
The Packaging Org is where the Managed Package is created and its namespace prefix defined. Package uploads in either Managed Beta or Managed Release state are initiated from this environment.

2. Patch Development Org – PDO
PDO are short-lived orgs created specifically for Patch development. Only certain components can be modified in a PDO. Once ready for distribution a Patch can be uploaded and pushed to Subscriber Orgs.

3. Push Upgrades
Uploaded Major Releases and Patches can be scheduled for push distribution to selected (or all) Subscriber Orgs. Package subscribers have no control over whether to accept pushed changes and as such it is not advisable (unless with tacit agreement) to push changes that impact the end user experience in any material way.

4. Localisation
Translation Workbench based localisation of internationalised resources.

Partner Business Org

A Partner Business Org can be provisioned upon partnership agreement with Salesforce or the same environment roles can be established within an existing production org.

1. Environment Hub
There Environment Hub enables partner orgs to be created for Development, Test and Trialforce usage. Single Sign-on can be implemented across connected orgs. A hub member org can only be connected to one hub at any given point in time. Where Trialforce is being implemented the TMO and Packaging Org must be connected to the same Environment Hub. The Environment Hub can create TSO directly, although bypassing a TMO prevents implementation of custom branding.

2. AppExchange Publishing Org – APO
This org role is for AppExchange management and is where Private and Public Listings and the Publisher Profile are stored.

3. Licence Management Org – LMO
This org role relates to the License Management App, a custom app installed by Salesforce which enables management of Packages, Package Versions, Licenses and Subscriber data resulting from AppExchange interactions. The LMO is also the entry point for Subscriber Org Login Access.

4. Channel Orders Application – COA
This org role relates to the Channel Orders app (also termed the Partner Order app), a custom app installed by Salesforce which supports automation of Service Order submissions (relating to AppExchange sales) to Salesforce.

5. Usage Metrics Reporting
Usage Metrics provides a daily update of statistics relating to Custom Object record counts (snapshot) and Visualforce Page access and performance (summaries) across all production Subscriber Orgs. There is no opt-in required for Package subscribers. The usage data is written to objects that are API accessible only; a visualisation app is available on the AppExchange to provide convenient access. Usage Metrics provide the basis for monitoring usage patterns and proactive customer retention process.

Trialforce Orgs

AppExchange listings can offer customers the ability to trial an app within a new, pre-configured Trial Org (package, data and users). This highly valuable capability is implemented with Trialforce. Trial organisations can also be created directly from Signup forms hosted on an external website or via the API. In addition to offering free trials the Trialforce solution provides a convenient option for the quick creation of pre-configured orgs for QA or demonstration purposes.

1. Trialforce Management Org – TMO
An optional environment used for centralised management of TSO for different packages. TSO can be created directly from the Environment Hub also, however such this direct approach does not support custom branding. The TMO approach does enable custom branding for Login Pages and Email Templates.

2. Trialforce Source Org – TSO
The TSO is where the package is installed (or upgraded) and configured to reflect the trial experience (user profiles, sample data etc.) A snapshot is taken of the Source org state to create a template. Note, TSO expire after a 12 month period unless a partner case is raised to request an extension. TSO are linked to the AppExchange Publishing Console manually, once a link is in place templates are listed on the Trial Templates tab.

3. Trialforce Template.
Templates listed in the Publishing Console can be submitted for Security Review. This reviews takes less time than the Package Security Review. Once approved a template can be connected to an AppExchange listing at which point the link to start a free trial appears on the AppExchange listing.

Note, each time a package is updated the TSO must be upgraded and a new template created, reviewed and connected to the AppExchange listing.

The ISVforce Guide provides further detail on the environments listed in the preceding sections.

InvocableMethod Invocations via Process Builder

As I’ve previously stated the combination of Process Builder and Apex Actions is incredibly powerful.

This short post adds the answer to a frequently asked question; how many times is the InvocableMethod called when records are modified in bulk?

To answer this with an example. With default batch settings (200 records) and 201 modified records the InvocableMethod is called twice (2 times – 1 invocation per-batch), first call with 200 records then a second call with 1 record. Not 201 individual calls!

If the Process applies entry criteria met by only 10 of the first batch – plus the single record in the second batch – there would again be 2 calls (10, then 1). So the assertion holds true; one invocation per batch.

This bulk behaviour is why the @InvocableMethod input parameter is a list of course; however it isn’t obvious in the related documentation.

Salesforce Winter ’17 Platform Highlights

Once again regretfully it’s time to start talking about Winter; the Winter ’17 (v38.0) release that is. This (pre-Dreamforce ’16) release sees the return of a snowman logo (last seen in Winter ’10) – albeit rather glum looking on this occasion – despite the animated wink ;-); perhaps Dreamforce ’16 will cheer him/her up.

The new release is generally available now for pre-release preview. The preview release notes are available here.

The Winter ’17 sandbox preview starts early September 9th, with production orgs being upgraded late September/early October. Full details of the release schedule can be found on the site.


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

– features are GA if not indicated otherwise

App Launcher
Winter ’17 re-introduces Application as a primary navigation concept; with previous LEX versions Applications are essentially logical groupings of functions within the App Switcher but had no further relevance – Navigation Menus are defined at the Profile Level not per-Application. With Winter ’17 Custom Applications are defined as Lightning Applications, tabs are added as-per Salesforce Classic – so really the only difference is the position of the App Launcher (far-left of the tab bar) and its ability to open a tab directly. The new App Launcher can also be set as the default page.

Winter 17 - App Launcher

AccountContactRelation Person Account Compatibility
The Summer ’16 release introduced a standard object version of the junction object typically implemented between Account and Contact to support indirect relationships (where more detail is required than ContactRoles allows). Winter ’17 provides Person Account compatibility and also support for Apex Triggers and Validation Rules. This is great functionality; Person Accounts (in a primarily B2C context perhaps) can now reflect any Business Account relationships and vice-versa using standard features.

Lightning Component Actions
Lightning Components that implement the new force:LightningQuickAction or
force:LightningQuickActionWithoutHeader interfaces can be invoked from a Custom Action added to a Page Layout.

Winter 17 - Lightning Component Action

Winter 17 - Lightning Component Action 2

Spanning Relationships Limit Increase
The Spanning Relationships limit applies to declarative features such as formulas, workflow rules and validation rules and constrains the number of unique object references. Previously this limit was 10 but could be lifted to 15 via Salesforce Support. Hopefully the new value of 15 can also be increased as this particular limit can be serious scalability constraint particularly where the org customisation has made no effort in respect to conservation.

Invoke a Process from a Process
Invocable Processes allow one Process to call another Process; this allows a modular design approach to be taken to support reuse of processes as units of logical encapsulation.

Winter 17 - Invocable Process

Flows for Lightning Experience (Beta)
With this beta feature enabled URL-based flows can execute with the Lightning runtime rather than the Salesforce Classic runtime. It’s great to see Flow (or Visual Workflow) entering the Lightning era – automated conversion of existing Flows to Lightning Experience is a real benefit for implementations that have taken advantage of this incredibly powerful and much overlooked capability. Winter ’17 also provides the ability to embed flows within Lighting Pages (App, Record and Home pages).

Use SLDS in Lightning Apps
Lightning App definitions can now automatically reference the latest Salesforce Lightning Design System (SLDS) styles and design tokens. This is achieved by defining the application as extends=”force:slds”. This approach is recommended over the Static Resource approach where a particular version of the SLDS is statically referenced.

Automated Package Installation via API
ISVs are now able to automate managed package push upgrades via the API. This capability provides support for use cases such as customers accepting an upgrade offer sent via email or submitting a web form to request an upgrade. The Tooling API now supports automated upload of packages, upload status monitoring and the retrieval of installation Urls for distribution to subscribers – via the PackageUploadRequest object (and related).

Omni-Channel Routing for Chats (Beta)
A new Routing Type “Omni” enables Omni-Channel to route and prioritise Live Agent chats alongside other types of Work Item. Previously Live Agent chats were routed using skills and Agent availability only. As with Omni-Channel generally, this feature is Salesforce Classic only at this time.

Lightning Login
Passwords can be frustrating for users and a system administration nightmare. With Lightning Login user authentication can be achieved through a simple mobile-based approval. The user enters their username and clicks the Lightning Bolt, a notification is sent to the Salesforce Authenticator app (iOS and Android), user completes authentication in the app via Fingerprint or PIN. The feature works in both LEX and Salesforce Classic and is assigned to users via Permission Set.