Showing posts filed under:
This post provides an annotated Object Model for the Salesforce Field Service Lightning product. The document was produced as part of my preparation for the Salesforce Field Service Lightning Consultant certification and is shared as-is with the 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.
Salesforce Field Service Lightning Object Model (Spring ’19) – Annotated
Salesforce DX introduces an entirely new development paradigm for Salesforce; Source Driven development, Scratch Orgs, Unlocked packages – there’s a lot of new concepts, capabilities and tools to consider when designing a modern, collaborative development process.
This post outlines a Developer Workflow that combines the Salesforce CLI and Git version control system as one basic example of how Salesforce DX can be applied in practice. The workflow includes a reference to the type of commands that may be executed at each step, however specific details in respect to parameters etc. should be referenced at the links below.
git Reference Manual
Salesforce CLI Command Reference
A Source Driven Development methodology is applied; the source of truth is git never a Salesforce org.
Source Format is always SFDX (git and local).
Scratch orgs are intended for single developer use.
Developer1 and Developer2 will work collaboratively on a new Feature1 for ProjectA.
git: A new branch is created for ProjectA.
git: A new branch is created for Feature1.
1.1 create a new local branch Feature1Dev1 and check out to this branch.
[code language=”bash”]$ git checkout -b Feature1Dev1[/code]
1.2 retrieve the Metadata API components from a Source org and convert to Source format. This could be by package reference or manifest.
[code language=”bash”]
$ sfdx force:mdapi:retrieve ..
$ sfdx force:mdapi:convert ..
[/code]
1.3 add source format files to the git branch (not the metadata source).
[code language=”bash”]
$ git add .
[/code]
1.4 create a Scratch org (optionally with an expiry date; max is 30 days).
[code language=”bash”]
$ sfdx force:org:create ..
[/code]
1.5 push source format to the Scratch org.
[code language=”bash”]
$ sfdx force:source:push ..
[/code]
1.6 transport data to the Scratch org.
[code language=”bash”]
$ sfdx data:soql:query ..
$ sfdx force:data:tree:export ..
$ sfdx force:data:tree:import ..
[/code]
1.7 run configuration scripts e.g. PostInstallScript (or equivalent Apex script) in the Scratch org to configure settings.
[code language=”bash”]
$ sfdx force:apex:execute ..
[/code]
1.8 open the Scratch org to make declarative changes and pull to local folder.
[code language=”bash”]
$ sfdx force:org:open ..
$ sfdx force:source:pull ..
[/code]
1.9 modify code in the VS Code IDE and push to the Scratch org. Note, SFDX tracks changes between the local folder and the Scratch org, i.e a pull command will return only detected changes.
[code language=”bash”]
$ sfdx force:source:push ..
[/code]
1.10 create a Scratch org user for any QA users involved in early system testing.
[code language=”bash”]
$ sfdx force:user:create ..
[/code]
2.1 Developer1: pushes local branch Feature1Dev1 to origin.
[code language=”bash”]
$ git add .
$ git commit -m "feature1 commit.."
$ git push origin Feature1Dev1
[/code]
2.2 Developer1: create Pull Request (Feature1Dev1=>Feature1)
2.3 CI: create Scratch org, runs unit tests, runs Lightning Lint (Pull Request specific build behaviour)
2.4 Developer2: review Pull Request (Technical QA) (Feature1Dev1=>Feature1)
2.5 Developer2: merge Pull Request to Feature1 branch
2.6 CI: create Scratch org, runs unit tests, runs Lightning Lint (Commit specific build behaviour)
2.7 Developer2: fetch the Feature1 branch from origin and merge to local Feature1Dev2
[code language=”bash”]
$ git fetch origin
$ git merge origin/Feature1
[/code]
3.1 Developer1: create Pull Request (Feature1=>ProjectA)
3.2 CI: create Scratch org, runs unit tests, runs Lightning Lint
3.3 Technical Lead: review Pull Request (Technical QA) (Feature1=>ProjectA)
3.4 CI: create Scratch org, runs unit tests, converts SFDX Source to Metadata API and pushes to ProjectA Salesforce org for QA (Commit specific build behaviour)
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
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.
[code language=”Java”]
switch on expression {
when value1 {
// code block
} when anotherValue2, anotherValue3 {
// code block
} when null {
// code block
} when else {
// code block
}
}
[/code]
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.
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.
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 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.
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.
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.
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 …)
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
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 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.
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.
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.
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.
[code language=”java”]
@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]);
}
/* */
}
[/code]
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
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.
The Apex language supports the advanced unit testing technique of Mocking which enables isolation of test execution from external factors such as API callouts or Salesforce configuration changes.
Mocking essentially involves the non-disruptive, dynamic substitution of a test specific class instance in the place of a functional class instance. Apex provides the HttpCalloutMock interface to allow test code to utilise pre-fabricated Http callout responses. The Stub API (StubProvider interface and Test.createStub method) supports the development of Mocking frameworks that enable any class to be substituted dynamically at runtime.
Apex Developer Guide > Testing Apex
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 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.
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.
Described as one-click data science this new feature enables standard report data to be analysed to provide key insights. The feature is invoked by a button within report builder and specific numeric fields can be targeted for analysis. This could be a very powerful new capability for Salesforce reporting with broad appeal, the proof of this will lie – of course – in the usefulness of the insights drawn which could be limited by the available data.
Toward the end of 2017 Salesforce introduced the impressive sounding Saleforce IoT Explorer Edition, a platform to process events from connected devices in near real time. With the Spring ’18 release a new REST API is added to enable manipulation of the various IoT components (orchestrations, traffic etc.). It would be great to see more information on this somewhat mysterious edition; who’s using it and for what specific use cases.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[code language=”java”]
System.QueryException Cause: null Message: Non-selective query against large object type (more than 200000 rows)
[/code]
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.
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%
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%.
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.
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.
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.
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.
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.
From Summer ’14 on the Developer Console can be enabled [Help>Preferences>Enable Query Plan] to display a Query Plan option on the Query Editor tab. The construct of the output is the same as the API approach. Note, this appproach is limited to SOQL queries.
The references section below provides link to the technical detail of the 2 approaches introduced above.
Query & Search Optimisation Cheat Sheet
Developing Selective Force.com Queries through the Query Resource Feedback Parameter Beta
Developer Console Query Editor
Improve performance with Custom indexes using Selective SOQL Queries
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.
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 – Dashboard: A dashboard is a composition of charts, metrics, and tables based on the data provided by one or many lenses.
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 – 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.
Dataflow: A dataflow is a set of instructions (in JSON format) that specifies the data to extract and transform from Salesforce objects or datasets.
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.
The diagram below shows the main building blocks of a Wave Analytics App and the flow of data.
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.
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.
Analyze Your Data – 700+ page PDF
Wave Analytics Platform Setup Guide
Wave Analytics Data Integration
