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.

Salesforce Selective Queries

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

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

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

Selective Query Definition

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

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

Unary filter:

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

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

Multiple filters AND (exclusively):

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

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

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

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

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

Multiple filters OR (at least one):

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

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

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

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

Parent Field Filter:

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

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

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

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

 

Implementation Approach

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

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

REST API Query Resource Feedback Parameter

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

selective-queries-api

Developer Console Query Plan

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

selective-queries-developer-console

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

 

References

Query & Search Optimisation Cheat Sheet

Developing Selective Force.com Queries through the Query Resource Feedback Parameter Beta

Developer Console Query Editor

Improve performance with Custom indexes using Selective SOQL Queries

Custom Index Request Checklist

Salesforce Analytics Cloud Overview

analytics-cloud

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

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

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

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

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

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

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

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

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

Key Concepts

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

wave-assets-app

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

wave-assets-dashboard

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

wave-assets-lens

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

wave-assets-dataset

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

wave-dataflow

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

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

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

Architecture

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

wave-analytics-architecture

Key Features

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

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

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

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

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

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

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

Salesforce Integration Points

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

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

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

References

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

Salesforce Marketing Cloud January 2017 Release

icon-cloud-marketing

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

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

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

– features are GA if not indicated otherwise

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

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

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

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

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

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

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

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

Salesforce Spring ’17 Platform Highlights

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

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

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

spring17logo

– features are GA if not indicated otherwise

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

external-service

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

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

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

lightning-console

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

lightning-app-builder

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

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

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

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

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

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

kanban-settings

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

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

Goodbye Force365 Hello Audit9

Regular visitors to this blog may notice that the title has changed recently from Force365 to Audit9.blog. I’ve done this firstly to remove the term “Force” which proved problematic in establishing an ISV contract with Salesforce for the AppExchange listed clearMDM product (something for other bloggers to consider perhaps) and secondly to consolidate all my activities (both personal and otherwise) against a single identity. I hope this makes sense – the content on this blog moving forward will be the same as ever, thanks for reading.

Salesforce ISV Environment Strategy

salesforce-isv-environment-strategy-all

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

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

Primary Org Definitions

Packaging Org

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

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

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

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

4. Localisation
Translation Workbench based localisation of internationalised resources.

Partner Business Org

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

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

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

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

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

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

Trialforce Orgs

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

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

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

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

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

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

InvocableMethod Invocations via Process Builder

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

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

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

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

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

Salesforce Winter ’17 Platform Highlights

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

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

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

images

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

– features are GA if not indicated otherwise

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

Winter 17 - App Launcher

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

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

Winter 17 - Lightning Component Action

Winter 17 - Lightning Component Action 2

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

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

Winter 17 - Invocable Process

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

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

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

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

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