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

Scrum Quality Assurance

More often than not quality assurance is considered to be an implicit benefit of agile process with no specific techniques or practices applied. Integrating effective quality assurance can be one of the most challenging aspects of applying the Scrum framework.

Before considering how quality assurance factors can be applied to the Scrum framework, let’s start with a clear definition.

Quality assurance (QA) is a set of practices which collectively ensure that standards of quality are met (i.e. technical standards) and specified requirements are delivered (customer or user needs or expectations). Standards of quality may include for example measures of correctness, integrity, maintainability or usability. Quality assurance does not mean software testing; this is one element of a quality assurance process. Effective QA means there are limited defects in the first place. The core elements of a QA process include standards, audits, solution governance, testing, defect management (analysis, tracking and resolution) and communication.

Scrum Concepts

The following points describe how QA should be considered in relation to some of the core Scrum concepts.

Developer. In Scrum terms this means any project contributor such as Software Testers, UI Designers in addition to Software Developers. This term is obviously confusing and a source of misunderstanding.

Scrum Ceremonies. QA should attend all meetings (Sprint Planning, Product Backlog Grooming, Stand-ups, Reviews and Retrospectives). A team-wide, test-first philosophy is often the driving factor behind high performance Scrum teams. This concept is also referred to as acceptance-test driven development.

Working Software. This means fully tested quality software – not code complete.

Definition of Done. The DoD must include strict criteria for testing and quality.

Customer Satisfaction. Conditions of Satisfaction (or Acceptance Criteria) defined for each User Story drive the quality assurance process.

Scrum Artefacts

The following points describe how QA should be considered in relation to some of the core Scrum artefacts.

User Stories. The User Story is a concise description of a feature told from the perspective of the person who requires it. User Stories are best considered a reminder of a conversation and should be limited to the detail required for effective estimation and prioritisation.

The following (INVEST) factors should be considered in respect to the quality characteristics of a User Story;
Independent – can it be delivered in a single sprint, or do dependencies exist?
Negotiable – the user story is not a specification (reminder of a conversation)
Valuable – is there obvious intrinsic value to the user?
Estimable – can it be estimated (sufficient detail, available knowledge)?
Small – is it sized appropriately (to fit in a sprint)?
Testable – are there appropriate Conditions of Satisfaction – or Acceptance Criteria?

The Conditions of Satisfaction (CoS) are most significant to QA. Each condition is a specific, user-focused requirement for acceptance and should be written using the Given-When-Then format (or heuristic technique) as below.

Given [context] – e.g. I have created a Customer Record and Sales Invoice.
When [event] – e.g. I attempt to enter a Sales Payment above the Sales Invoice Total.
Then [outcome] – e.g. I am warned that the payment exceeds the outstanding amount.

The high-level CoS will drive the team discussion of the User Story (in a test-first approach), a “Design and Test” whiteboard approach can be useful in this respect where the team consider both the design and testing approach at the same time. Each high-level CoS will be translated into lower-level (detailed) test cases (technical; unit and integration or functional).

User Story Test Cases. The Conditions of Satisfaction (CoS) for a given User Story provide a high-level framework for the definition of specific test cases. Such test cases should be structured to address a small, focused end-to-end workflow (or scenario) to avoid interdependencies and should enable collaborative and automated testing. Effective test cases provide a simple set of step-by-step test instructions (or steps). Note, the CoS covers the happy path scenarios only, test cases must be developed also that cover critical path, alternate path, negative path, technical, validation and edge case scenarios.

Product Backlog. The Product Backlog is a single, ordered list of requirements (typically but not exclusively User Stories) used by Scrum teams. The list is constantly evolving, business value ordered and estimated by the team – including QA.

The following factors should be considered in respect to the quality characteristics of the Product Backlog;
Prioritisation – are the Product Backlog Items (PBI) accurately prioritised to a consistent scale based on business value, ROI, interdependencies and risk?
Estimation – are the PBI consistently estimated (and benchmarked) by the team?
Well Groomed – is the backlog frequently groomed by the team?

Product Backlog grooming entails User Story discussion by the whole team (lead by the Product Owner) with a view to revising and refining estimates and adding details such as new Conditions of Satisfaction. Regular sessions should be scheduled for this purpose; ideally 10% of the Sprint time should be dedicated to this task. In practice this is rarely the case, however given the direct relationship between the completeness of the CoS to the efficiency of the quality assurance process it is important that sufficient time is allowed for effective grooming.

Scrum Practices

The following points describe how QA should be considered in relation to some of the core Scrum practices.

In Sprint Testing. User Story testing must be completed within the sprint – full-stop. The Definition of Done must include this criterion. Testing a sprint behind the development is common bad practice and directly violates the working software principle; additionally this approach builds up technical debt and defect debt to be resolved at a later time. Instead, the sprint backlog must be shaped to enable collaborative design, development and testing of each user story within the sprint. High performing Scrum teams will also automate some of the tests within the sprint. The following simplistic process describes how collaborative sprint development can be applied.

Developers and Testers working collaboratively – Team Swarming:
Write the test case
Write the code
Test together (developers and testers)
Fix the bugs (developers) / Automate the test case (testers)
>> next user story

Test Automation. The ability to automate the execution of test cases (i.e. unit tests and acceptance tests) is critical at scale. In order to quickly identify cases where the current sprint development breaks the code or functionality developed in a previous sprint it is necessary to execute the related tests efficiently. Test automation also supports evaluation of the impact of changes (What-if analysis) that can help with design decisions. Further QA related benefits of test automation include the ability to apply load testing (e.g. multiple concurrent users) and performance testing types. Unlike manual testing which must be conducted in-sprint, test automation can be added outside of the sprint and be developed a separate team. High performance Scrum teams will automate critical tests within the sprint.

Test data quality has a significant impact upon the effectiveness of testing. Random data simply doesn’t work and prefabricated test data is often written to expectations and is not representative. Using production data (real data) for test purposes can violate data protection regulations and comes with the risk of inadvertent communication to the customer, supplier etc. or PII or financial information leakage. To mitigate this an approach that combines real data with obfuscation (scrambling or scrubbing) techniques can produce large scale, representative test data sets without the risk. This can take significant time to perfect however the return on this investment will be high.

Note, in addition to automated tests, a quality test plan still includes manual testing to cover exploratory testing and usability testing types. Automated tests are systematic and unable to gauge the quality of the user experience for example.

Regression Testing. The ability to run test cases developed in previous sprints (and perhaps by different teams) enables the impact of a current development to be understood immediately. This testing practice is referred to as regression testing. Regression testing effort gets bigger over time, as with User Story test cases, regression testing should occur in-sprint and automation should be used wherever possible. It is good practice to reserve time at the end of the sprint to allow the team to complete regression testing, this should also include performance and security test cases. At scale, it is often necessary to be selective in terms of which test cases to focus upon. An effective but contentious practice is to reserve the final sprint for end-to-end regression testing – this sprint is referred to as a hardening sprint; the key risk with this approach is that defect resolution from earlier sprints is deferred to this sprint. The hardening sprint should be driven from the regression test plan not the product backlog and be managed by the QA lead.

Post Release Support. Once the product is released – and despite the QA rigour applied – it is inevitable that production defects will arise. Such defects should be reviewed first by the Product Owner to determine priority and relevancy. Where defects are to be addressed immediately (show-stopper bugs etc.) the resolution work should replace similar sized work in the current sprint. In every respect the defect should be treated in the same manner as a User Story. Defects can also be placed on the Product Backlog for grooming. Where the Scrum team is providing defect resolution it is good practice to retain velocity for production defects; this proactive approach reduces the requirement to pull User Stories from the current sprint that may be in progress.

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

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

Journey Builder Contact Re-entry

Please find below the findings of a recent investigation into Journey Builder Contact re-entry – where the concurrent journey injection relates to child records such as Opportunities or Purchases.

Problem

Where Journey Entry occurs at a Child-object level (Opportunity, Case or Purchase as examples), a given Contact may enter a Journey multiple times; the journey injection relates specifically and exclusively to the child record not the parent Contact.

When Contact Data attributes are referenced (by filter expressions) across one-to-many relationships there are no implicit filters applied that ensure that only the relevant Child-object record is referenced, i.e. the record that initiated the journey entry. Instead the first Child-object record (related to the Contact) that passes the filter conditions for a configured path will be utilised. This means that any child record (for the Contact) could drive the flow through each decision split within the Journey.

Solution A. Salesforce Data Events

Note, auto-generated Data Extensions related to Salesforce Data Event Entry Sources are created with all fields set to nullable, apart from the Primary Key (Primary Object ID).

A.1 Id field on the related Salesforce (Child) Object is the Foreign Key to the related Contact Data.

e.g. Entry Source = Purchase Data Extension (PK is Purchase Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can go ID field to ID field with an attribute to attribute comparison (which requires non-nullable fields).

In Journey filter expressions (specifically Decision Splits) add filter criteria to every path:

1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Object ID field (Primary Key)

The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.

2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.

A.2 Non-Id field (other relationship field) on the related Salesforce Object is the Foreign Key to the related Contact Data.

e.g. Entry Source = Payment Data Extension (PK is Payment Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can’t go ID field to ID field instead the nullable FK field Purchase__c is the key into the Contact Model; being nullable an attribute-to-attribute comparison won’t work.

Link the auto-generated Entry Source Data Extension to the related (Synchronised or Standard) Data Extension with a new relationship in Contact Builder (Data Designer > Sales and Service Cloud Attribute Group).

In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:

1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > Event Source DE > Primary Object ID field

The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.

2) Add subsequent Contact Data filters by selecting the Entry Source DE and navigating the new relationship added to the Synchronised Data Extension.

Solution B. Automation Studio Audience

In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:

1) Journey Data > Event Source DE > Foreign Key field (Could be the Primary Key field or any other field that holds the foreign key identifier value)
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Key field (i.e. Primary Object ID)

The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.

2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.

Additional Considerations

1) Journey Data returns the specific Entry Source DE record that initiated the Journey and provides the only means to establish a fixed reference for this record into Contact Data.
2) Exit Criteria can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level.
3) The Update Contact Activity can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level. This activity will update all child records for the current contact in the target data extension.

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 DX

This post provides a practioner’s introduction to Salesforce DX (Developer Experience) a new software development lifecycle paradigm for Salesforce. Please note at the time of writing (Spring ’17 – v40.0) Salesforce DX is at public beta status.

Salesforce DX (or SFDX) – What is it?

A new set of tools and practices to accelerate the software development lifecycle on the Salesforce platform. The tools in question enable established (technology agnostic) software development models to be applied to the Salesforce context efficiently; the practices provide guidance in how to do this effectively and at scale.
Many aspects of Salesforce DX have become standard practice over the last few years; source-driven development using tools such as Jenkins and git being a good example. Other aspects such as artifact-based development, the CLI and Scratch Orgs introduce a fundamentally new paradigm.

The Salesforce development model has historically been org-centric in concept; with the entire set of metadata types representing a single monolithic code-base. This conceptual model has benefits in respect to ensuring complex interdependencies are not overlooked and code structure and conventions are considered fully in a standardised approach. In the org-centric model – and typically not exclusively – a source-code control repository is mapped at the org-level and deployments are org-based not feature or app based. Salesforce DX provides the tools and practices to change the development model from org-centric to artifact-based; where an artifact represents a collection of components (org subset) – developed, tested and deployed together in safe isolation.

SFDX Tools

CLI (Command-line Interface – sfdx)

The new SFDX CLI provides the foundation for Salesforce DX with capabilities that span authorisation, org management, metadata creation, data population, packaging and deployment. The CLI commands are extensive and clearly structured within the top-level force namespace.

command examples:

//CLI create a new project (specific DX folder structure plus config file)
sfdx force:project:create 

//CLI needs to authorise against the DevHub (OAuth web-based flow or for CI JWT Bearer flow)
sfdx force:auth:web:login -d -a "Hub Org"

//CLI create scratch org (or set existing as default)
sfdx force:org:create -s -f config/project-scratch-def.json

//CLI push source code from local (respects the .forceignore file placed in root folder)
//Conflicts can be overwritten --forceoverwrite
//Note - Local project is the source of truth.
sfdx force:source:push

//CLI run unit tests
sfdx force:apex:test:run

A key concept is the local project which is the primary source of truth. The project structure is different from the Metadata API folder structure with higher-level metadata types such as Object broken down into sub-folders and individual files for sub-types such as listViews and fields. This new sfdx structure (or source shape) is designed for development and source-code control system interactions whereas the longstanding Metadata API structure related to deployment primarily. Conversion between the 2 formats is necessary when creating a new sfdx project from an existing org (or simply from existing metadata) and prior to deploying a sfdx project to a Salesforce org (not Scratch Orgs). The CLI provides commands to perform the format changes as illustrated below.

//Create DX project > Create folder for metadata files then ..

// Retrieve unpackaged metadata
sfdx force:mdapi:retrieve -r ./mdapipkg -u <username> -k ./package.xml

// Retrieve the metadata for a package
sfdx force:mdapi:retrieve -s -r ./mdapipkg -u <username> -p <package name>

// Convert to SFDX format.
sfdx force:mdapi:convert --rootdir <retrieve folder name>

// Convert to Metadata API format.
sfdx force:source:convert -d <metadata folder name>/ --packagename package_name
Scratch Orgs

A Scratch Org is a temporary org that can be created quickly and configured with predefined settings and preferences (Edition, languages, platform features etc.) via a JSON definition file. Scratch Orgs are easily created and deleted via the CLI; up to 50 can be created per-day (per Dev Hub) with up to 25 active concurrently, deletion occurs automatically after 7 days.

A Scratch Org is typically used for development and testing purposes and plays an enabling role in build automation. Note, unlike sandboxes, Scratch Orgs are not constrained by a refresh cycle, but also are not a clone of a source org configuration. A typical development workflow will be to create a short-lived feature branch in the Source Code Control system (SCC), create a local sfdx project (from the branch metadata) and Scratch Org, complete development and testing in the Scratch Org, commit change back to SCC and convert and deploy the change to Sandbox. In a Continuous Integration (CI) environment the CI server (Travis CI, Jenkins etc.) may initiate an automated build from the commit event. In such a scenario, headless Scratch Orgs may be used for automated testing (across editions, languages etc.).

The SFDX CLI provides commands for automating the population of data in a Scratch Org. This can be via CSV file loading or more interestingly via org-to-org copy via SOQL query export and subsequent import.

Finally, a key feature of the CLI is the automated tracking of change (the diff) between the current local project and the default Scratch Org. The CLI push and pull commands that facilitate the movement of change between the local project and the Scratch Org automatically process changed components only.

Dev Hub

The SFDX CLI must authorise to a Dev Hub before Scratch Orgs can be created; each Scratch Org is related to a parent Dev Hub. The Dev Hub is a production Salesforce org (Enterprise Edition or Unlimited Edition) – the feature can be activated from the Setup menu. A Dev Hub trial org can be created to enable safe experimentation with SFDX. Dev Hub trial orgs expire after 30 days and are limited (40 Scratch Orgs created per day, 20 active concurrently) why this is subtly different from the standard limits is unclear.

Authorisation of the Dev Hub org (and indeed any org) by the SFDX CLI is possible via OAuth Web Flow or JWT-based Flow. The latter being preferred for system authentications such as those conducted by a CI server.

For ISV (and others) working with namespaces, the Dev Hub provides a Namespace Registry capability which (as the name suggests) allows Developer Editions containing namespaces to be registered. Once the org link is complete, Scratch Orgs can be created as normal. This capability is great for ISV developing in a namespace registered org (as opposed to utilising a separate packaging org to apply the namespace).

IDE2

The new Force.com IDE2 is an Eclipse plug-in built on the SFDX CLI. Additional features of the IDE2 include the Lightning Code Analyser and Apex Code Analysis tools. The former wraps the capabilities of ESLint and the Salesforce Lightning CLI to evaluate JavaScript code against standard or custom rule sets. The latter covers syntax error detection and highlighting plus code auto-completion. The IDE2 also provides an embedded browser for editing Lightning Pages.

On initial inspection there didn’t appear to be any means to directly login/import metadata from an existing org. Presumably this must be done externally via the SFDX CLI.

Finally, the new IDE2 provides integrated tools for working with Git repositories, a key facet of the envisaged developer workflows centred around Salesforce DX.

Summary

At the time of writing, the available SFDX documentation relates primarily to the technical aspects of the tools, there is minimal information relating to process guidance (or practices). Whilst it’s relatively easy to envisage how the new tools and techniques could be integrated into development, test and deployment workflows, best-practice guidance in such areas would certainly provide confidence and accelerate adoption.

Historically, a key sticking point for source-based development (and deployment in general) in the Salesforce context has been the Metadata API coverage. In short, not all metadata types are supported and therefore automated deployments (whether Change Set or API based) are typically accompanied by pre- and post- deployment steps that manually address the gaps. As there’s no significant change in this regard, it’s likely that Scratch Orgs will require the same approach – however considering Scratch Org use cases will typically be code related this may have limited actual impact.

In general however Salesforce DX is a considerable step forward in terms of applying established software development lifecycle practices to the Salesforce context. The CLI alone is incredibly impressive and provides significant flexibility in respect to development, testing and release process. It will be interesting to see how tools vendors react to the availability of the CLI as a foundation for future, evolved IDE capabilities. Hopefully Salesforce DX represents the first step of many in this direction.

Resources

Salesforce DX Developer Guide (Beta)
Salesforce DX on Trailhead
Salesforce DX Chatter Group

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.