Salesforce Summer ’18 Platform Highlights

For the first time (in memory) this lightweight edition of the platform highlights series refers to the current Salesforce release (v43.0) not the next in line. As such there’s no need to cover release dates, pre-release access, release notes links etc. instead I’ll make a quick mention of the Summer ’18 certification maintenance changes. Previously all maintenance exams were taken via Webassessor and involved a recurring fee; with Summer ’18 most of the maintenance exams have moved to Trailhead and are now free-of-charge. This is great news for everyone but particularly those with multiple certifications to maintain. I found the new maintenance process to be a significant improvement, I particularity liked the practical testing element e.g. the “Get Hands-on with Flows” unit (App Builder certification maintenance unit 2). More of the same please.

– features are GA if not indicated otherwise

Apex Switch Statement

At long last the Apex language now supports Switch (or Case) statements for control flow adding coding simplification and processing efficiency (assumed). Switch statements in Apex support Integer, Long, sObject, String, Enum data types plus lists of literal values.

switch on expression {
    when value1 {
        // code block
    } when anotherValue2, anotherValue3 {
        // code block
    } when null {
        // code block
    } when else {
        // code block
    }
}

SOQL Count Limits

SOQL queries that utilise the Count aggregate function no longer calculate Query Row limit consumption at the underlying record level, instead the number of aggregate groupings is applied. If there is no Group By clause then the limit consumption equals 1. This seemingly small change has a huge impact in enabling code to apply dynamic conditions based on the overall record count. Previously calculating a record count in code would be wasteful in limit terms in most cases, but impossible at higher data volumes. The SOQL Count Limits change in Summer ’18 is perhaps my favourite Apex language enhancement over recent releases, I can definitely see some significant benefits to the practical application of Apex/SOQL.

Apex Code Size Limit Doubled

Not often does a platform limit double in size between releases. The previous Apex character limit (3MB) was a soft-limit that could be increased by Salesforce Support, now however the limit is 6MB by default.

Apex Triggers on User Logout

A new standard object LogoutEventStream enables ApexTriggers to subscribe to User Logout events (not session timeouts). As the names suggests, the object should be considered as a published stream of event information and is read-only with no query support. This capability provides support for new security related use cases (e.g. logout propagation and audit tracking) as well as other data reset/cleardown type scenarios.

Einstein Bots

Einstein Bots are a new Service Cloud AI capability enabling intelligent conversational experiences to be developed that utilise Einstein Platform Services. Bots are comprised of Dialogs (Messages, Questions, Actions or Rules), Slots (Data variables extracted from responses – and passed to Actions), Entities (Groupings of Slots for a given data type) and Dialog Intents (Phrases or words used by the Einstein Platform Intent Service to select the Dialog most likely to match the entered response). Actions can incorporate Apex code into the flow where required.

Salesforce limits the number of free bot conversations to 25 per active Live Agent user.

Cloud Flow Designer – Debugging Support

A new Debug button appears in the Cloud Flow Designer which allows input variable values to be specified and the Flow to be executed with the activity of each step displayed in sequence. Note, the Flow is actually executed meaning DML actions are not rolled back on completion. With Flow gaining a renewed significance in Lighting Experience (as a key component of the declarative development model), it’s great to see continued investment in this tool.

Contactless Users for External Identity Users – Beta

The External Identity user license type now supports a model where no Contact record is required to be associated to the User. Contacts can be added at a later time if required. The Contactless approach avoids the overhead of storing, maintaining and potentially synchronising the 2 records. Where Salesforce is providing identity services only (or a blend of functional and identity based capabilities across the user base) this lightweight license type will provide some significant benefits. For example porting a membership database to Salesforce now becomes easier as the Contact or PersonAccount record could be added to the User at point of access and not up-front; thereby lowering the license cost (assumed) and optimising data storage.

Apex Replay Debugger – Beta

The Apex Replay debugger simulates a live debugging session using the Apex Debug Log generated by an executed transaction. Whilst very limited in general code debugging terms executed code can be stepped through, breakpoints set and variables inspected; all very useful tools to have available. it should be noted that unlike the full Apex Debugger, the Replay Debugger is free of charge and can be applied to logs generated by any org (including production orgs), the Apex Debugger is limited to sandboxes.

With the Replay Debugger a workflow such as (modify code, run to generate log, debug, modify code …)

Salesforce CPQ

This post provides an annotated Object Model for the Salesforce CPQ product (formerly known as Steelbrick). The document was produced as part of my preparation for the Salesforce CPQ Specialist certification and is shared as-is with the CPQ practitioner community for information purposes only. Please note, the notes were written before I sat the exam so no question or topic hints here I’m afraid.

By way of background; the acronym CPQ standards for Configure, Price, Quote. In almost every sales context a flexible and capable quoting engine is required that supports complex product configurations (bundling etc.), discounting and pricing calculation and finally efficient quote document generation and distribution. As standard Sales Cloud functionality provides only a basic capability in these functional areas the AppExchange category for CPQ solutions is one of the most popular in terms of both customer demand and vendor solutions.

As there is no Salesforce CPQ implementation guide (at the time of writing) I found that a practical (hands-on) approach to learning the Salesforce CPQ product worked best. For this I installed the CPQ package into a developer edition org and created my own demo dataset. The Salesforce CPQ product is both powerful and complex in equal measure; given the available help documentation it will require expert consultancy services to implement the product correctly beyond basic use cases.

Salesforce CPQ Object Model (Winter ’18) – Annotated

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

@isTest(SeeAllData=false)
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');
        
    Test.startTest();        
        
    // do something
    AccountProcessor.process();
                  
    Test.stopTest();
        
    // 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.

References

Apex Developer Guide > Testing Apex

Ron Jeffries Blog – All things XP and much more

Martin Fowler – All things Code Refactoring and much more

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

IoT REST API

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 Data.com 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 http://status.salesforce.com/status). 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 Force.com 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.

SFDX
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 Force.com 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 https://metamind.readme.io.

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

selective-queries-api

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.

selective-queries-developer-console

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

 

References

Query & Search Optimisation Cheat Sheet

Developing Selective Force.com 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 Analytics Cloud Overview

analytics-cloud

This post provides an overview of the features and functionality of the Salesforce Analytics Cloud.

The Analytics Cloud, or Wave Analytics as it is also referred to, is a cloud-based business intelligence platform that enables the connection of disparate data sources to form interactive data views (or visualisations) that can be distributed via dashboards. A key concept here is empowerment of business users to deliver their own insights, in fact usability is often described as the defining feature – perhaps in addition to mobile access.

From a history perspective, during 2013 Salesforce acquired a cutting edge BI platform via the EdgeSpring acquisition. The EdgeSpring platform included the EdgeMart data storage service plus the Lens dynamic visualisation engine; both of which (one could safely assume) feature strongly in the Analytics Cloud architecture.

The first release of the Salesforce branded Wave Analytics took place at Dreamforce 2014, where the dynamic visualisation capabilities drew significant attention. The offer at this stage was expensive and complex in terms of licensing (Explorer and Builder user licenses plus platform setup fee/license), platform-led and focused on enterprise deployments. The perceived complexity and cost aspects particularly impacted negatively upon adoption. A second generation of Wave Analytics was launched at Dreamforce 2015, this time with a simplified license model and a focus on prebuilt analytics apps for Sales, Service and ultimately Marketing. The introduction of prebuilt Wave Apps offers two clear benefits; template-based, simplified deployment and tighter, cross-cloud integration (with Sales and Service Cloud predominantly). This latter point is key; end-users shouldn’t have to navigate consciously between distinct analytic and transactional views the two services should be seamlessly blended – this is the key differentiator Salesforce will be targeting to drive adoption.

The current set of prebuilt Wave Apps are listed below. There are also a growing number of 3rd party Wave Apps being developed on the Wave Analytics Platform; Financialforce (ERP Wave Apps; Accounting and Supply Chain) and Apptus (Quote-to-Cash Intelligence App) are notable examples.

Sales Wave Analytics App: A 9-step wizard captures parameters relating to segmentation, lead funnel and opportunity pipeline fields plus additional Sales Cloud related dimensions and measures; on completion an App is created with datasets populated via a number of auto-launched dataflows.

Service Wave Analytics App: As above with Service Cloud related dimensions and measures (7-step wizard).

Event Monitoring Wave App: Event log and setup audit trail datasets enable analysis of org and user behaviour.

Wave for B2B Marketing App: Consolidation of Sales Cloud and Pardot data to enable analysis of marketing impact on sales etc.

Key Concepts

Wave Assets – App: Analogous to a Folder an App contains a logical grouping of dashboards, lenses, and datasets. Apps can be Shared or Private.

wave-assets-app

Wave Assets – Dashboard: A dashboard is a composition of charts, metrics, and tables based on the data provided by one or many lenses.

wave-assets-dashboard

Wave Assets – Lens: A lens is a view on to the data provided by a dataset. The definition of a lens encapsulates both a query and visualisation for a specific analysis. A Lens can be clipped; this effect of this is to copy the Lens query to a Step within the most recently used dashboard.

wave-assets-lens

Wave Assets – Dataset: A dataset provides the source analytical data in a representation optimised for interactive visualisation. Data Sources can be Salesforce objects, uploaded files or partner connectors (Informatica, Jitterbit etc.). Fields added to a dataset are defined as date, dimension (qualitative) or measure (quantitative) type. Predicates can be added, with filter logic, that define record-level permissions which reflect Salesforce record ownership, management visibility or team/account collaboration.

wave-assets-dataset

Dataflow: A dataflow is a set of instructions (in JSON format) that specifies the data to extract and transform from Salesforce objects or datasets.

wave-dataflow

Visualisation: A single analytical representation of data (chart, tabular etc.) underpinned by a query.

Dimension: A dimension is a qualitative value such as Product or Region. Data analytics are primarily comprised of measures projected over multiple dimensions.

Measure: A measure is a quantitative value such as Price or Quantity. Mathematical operations can be applied to measures to calculate aggregates.

Architecture

The diagram below shows the main building blocks of a Wave Analytics App and the flow of data.

wave-analytics-architecture

Key Features

Cross-Dataset Faceting: Faceting enables steps to auto-filter in response to filters applied to a related step. Steps that share the same dataset facet by default, cross-dataset faceting can be defined directly in the dashboard designer.

Trend Wave Dashboards: Trended Datasets can be created from Salesforce reports. A snapshot of the report data is created each time the dataset is updated by the trend schedule. Each snapshot is limited to 100K rows.

Bulk Actions (Spring ’17): Table widgets can invoke a custom bulk action where the underlying SAQL query is passed to a designated Visualforce page. Apex page controller code can then execute the SAQL query (via the Wave Analytics API) and apply custom logic to results. This provides a flexible integration point, where analytics can be used to drive action such as campaign creation, email sending and so on – powerful stuff.

Smart Data Discovery (Spring ’17 tbc): This feature relates to the integration of BeyondCore (another Salesforce acquisition) into the Analytics Cloud UI. BeyondCore adds statistically significant insights such as unbiased answers, explanations and recommendations.

Analytics Home (Spring ’17): The new Analytics home page allows commonly used apps to be pinned, notification tracking is displayed with convenient links directly to the related dashboards. In new Wave orgs the Analytics tab can be accessed directly within the Salesforce UI, older orgs require a custom tab plus Visualforce container page.

Dashboard Annotations: Widgets within a dashboard can be enabled for collaboration via Annotations. This feature is natively integrated with Chatter; annotations will appear as Chatter posts and vice-versa. @Mentions are also supported.

Smart Notifications: Number type dashboard widgets can be configured for smart notifications; criteria is added to define the notification logic and a query scheduled defined. The notifications appear in the app, mobile app and are also sent via email.

Salesforce Integration Points

Lightning Experience: The Wave Dashboard component enables dashboards to be added to Lightning Home Pages, Record Pages and App Home Pages defined within the Lightning App Builder.

Salesforce Classic: Wave Analytics Assets appear listed in the palette of the Enhanced Page Layout editor and can be added directly to page layouts with context supplied via field mapping. The Visualforce component enables dashboards to be embedded and integrated at any entry point available to Visualforce (Custom tabs, links/buttons etc.). The component supports filtering to enable context to be set.

Communities users (Customer Community Plus and Customer Partner Community licenses) can view Wave Analytics Dashboard embedded in a Visualforce page.

References

Analyze Your Data – 700+ page PDF
Wave Analytics Platform Setup Guide
Wave Analytics Data Integration

Salesforce Marketing Cloud January 2017 Release

icon-cloud-marketing

This post marks the first Salesforce Marketing Cloud related post on this blog, an event reflective of the increasing number of Salesforce implementations that span both the Salesforce and Marketing Cloud platforms (or cross-cloud, a term I can’t seem to stop using). Architects working on such implementations require a solid understanding of Marketing processes and both the functional and technical composition of the Marketing Cloud platform – not to mention the various APIs, connectors and 3rd party solutions offered via the HubExchange. Such a grounding is necessary to allow business processes (that are incidentally cross-cloud) to be understood and optimally implemented. This point is key; in ideal terms marketing processes should be integral parts of wider/deeper business processes that touch upon multiple areas of the business in pursuit of better customer experience or engagement. This type of thinking is key to realising current industry trends such as “Continuous Experience” where classic organisational structures (sales, service and marketing operations) are abandoned, or diminished, in favour of delivering unified customer journeys across all touch-points. For architects tasked with delivery of such solutions, the challenge starts with marketing domain knowledge and Marketing Cloud practitioner insight. In my own recent experience both stated aspects can benefit greatly from the combination of website/blog trawling, Trailhead and certification (Salesforce Certified Marketing Cloud Consultant). I completed the two required exams for this certification recently and found the experience challenging and time consuming but ultimately rewarding and definitely something I’d recommend to all Salesforce architects.

And so, on to the actual topic for this post – a review of the key features within the first of five major releases for the Salesforce Marketing Cloud scheduled for 2017.

The release notes are available here. The release is due to occur on the 27th January – this of course is subject to change.

– features are GA if not indicated otherwise

Marketing Cloud Connect – Sales & Service Cloud Activities
The ability to create Salesforce Activity records within a Journey Builder definition is now more intuitive via a new Lightning UI that abstracts the complexity of the WhatID/Who Id model for relating Activity records to Leads, Contacts and related records. Salesforce record interactions from within Journey Builder are key to blending the power of the two cloud platforms.

Content Builder – Themed Templates
Email messages can now be created from Themed Templates that encapsulate best practice for content creation. The templates provided cover Financial Services, Retail, Restaurant and Newsletter scenarios. The Themed Templates options can be found in the Define Properties step of the content creation flow.

Journey Builder – History Tab
The Contacts tab in the main Journey Builder navigation has been replaced with a History tab that displays the status of running journeys along with failure reasons to aid troubleshooting.

Marketing Cloud Mobile App
The January release brings an Android version of the mobile app and a new home dashboard for the iOS version. The Android version exhibits the same Lightning Experience UI and can be downloaded from the Google Play Store. The new app version will be released 2 weeks approximately after the main release date subject to Google/Apple app review. The new home page for the iOS version of the mobile app supports daily or weekly reminders and the delivers key performance statistics plus the current status of marketing automations. Note, the reminders work as push notifications and appear as badges on the app icon (as per email, SMS messages etc.). The new version of the iOS app also supports SMS campaigns via the SMS button in the primary navigation.

Social Studio – Emoji Support
Emojis come to life in the January 2017 release. The Publish component now supports the use of social network specific emojis within social content creation via the Emoji Picker (Composer and Inspector). Emojis are also correctly rendered by Engage and can be used to infer sentiment within Analyze thereby increasing accuracy.

Social Studio – Facebook Reviews
Social Studio now provides features to manage the reputation for a local Facebook page. Facebook reviews can be organised to filter promoters from detractors, automated actions can also be triggered based on review score. For example low scores could invoke a Journey Builder journey or Service Cloud case. Powerful stuff.

Social Studio – Analyze Dashboards
The Analyze component of Social Studio receives significant enhancement in respect to dashboards. The new release supports mixed dashboards showing content across multiple social accounts or topic profiles and expanded real time date options. Advanced card configurations enable filters, custom names and custom dimensions to be applied to individual cards within a dashboard.

Web Studio – Smart Capture to Lists
Previously Smart Capture Blocks defined within Content Editor were limited to Data Extensions for data push, with the January release this is extended to Lists.

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 Force.com platform (in no order of significance).

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

spring17logo

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

external-service

Data Integration Rules
Data.com 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 Data.com 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-console

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-app-builder

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

kanban-settings

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.