A quick video post providing a demonstration of the interactive Apex Debugger. The context of the demonstration is an ISV partner debugging a packaged code issue in a subscriber (customer) org.
Showing posts written by:
A quick video post providing a demonstration of the interactive Apex Debugger. The context of the demonstration is an ISV partner debugging a packaged code issue in a subscriber (customer) org.
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.
Please find below the findings of a recent investigation into Journey Builder Contact re-entry – where the concurrent journey injection relates to child records such as Opportunities or Purchases.
Where Journey Entry occurs at a Child-object level (Opportunity, Case or Purchase as examples), a given Contact may enter a Journey multiple times; the journey injection relates specifically and exclusively to the child record not the parent Contact.
When Contact Data attributes are referenced (by filter expressions) across one-to-many relationships there are no implicit filters applied that ensure that only the relevant Child-object record is referenced, i.e. the record that initiated the journey entry. Instead the first Child-object record (related to the Contact) that passes the filter conditions for a configured path will be utilised. This means that any child record (for the Contact) could drive the flow through each decision split within the Journey.
Note, auto-generated Data Extensions related to Salesforce Data Event Entry Sources are created with all fields set to nullable, apart from the Primary Key (Primary Object ID).
e.g. Entry Source = Purchase Data Extension (PK is Purchase Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can go ID field to ID field with an attribute to attribute comparison (which requires non-nullable fields).
In Journey filter expressions (specifically Decision Splits) add filter criteria to every path:
1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Object ID field (Primary Key)
The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.
2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.
e.g. Entry Source = Payment Data Extension (PK is Payment Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can’t go ID field to ID field instead the nullable FK field Purchase__c is the key into the Contact Model; being nullable an attribute-to-attribute comparison won’t work.
Link the auto-generated Entry Source Data Extension to the related (Synchronised or Standard) Data Extension with a new relationship in Contact Builder (Data Designer > Sales and Service Cloud Attribute Group).
In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:
1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > Event Source DE > Primary Object ID field
The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.
2) Add subsequent Contact Data filters by selecting the Entry Source DE and navigating the new relationship added to the Synchronised Data Extension.
In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:
1) Journey Data > Event Source DE > Foreign Key field (Could be the Primary Key field or any other field that holds the foreign key identifier value)
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Key field (i.e. Primary Object ID)
The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.
2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.
1) Journey Data returns the specific Entry Source DE record that initiated the Journey and provides the only means to establish a fixed reference for this record into Contact Data.
2) Exit Criteria can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level.
3) The Update Contact Activity can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level. This activity will update all child records for the current contact in the target data extension.
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.
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.
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.
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:
[code language=”bash”]
//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
[/code]
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.
[code language=”bash”]
//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
[/code]
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.
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).
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.
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.
Salesforce DX Developer Guide (Beta)
Salesforce DX on Trailhead
Salesforce DX Chatter Group
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
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.
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.
– features are GA if not indicated otherwise
External Services (Beta / LEX-only)
This new LEX-only feature provides a non-programmatic method for invoking external web service operations. The external service is registered (via JSON Schema) which generates proxy/wrapper Apex classes that can then be introduced into Flows which encapsulate the required business process automation. It will be interesting to see the code generated by the registration process, this could be a useful convenience irrespective of whether Flow is being. As a huge advocate of Flow (or Visual Workflow) it’s great to see investment that enables additional use cases. I’m slightly sceptical about non-technical treatment of API consumption scenarios, but that said anything that reduces the requirement for code should be a good thing.
Data Integration Rules
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 App Builder
The Lightning App Builder gets a serious overhaul in Spring ’17 with a new UI structure, additional templates, page cloning and the ability to assign record pages by app, record type and profile being the feature highlights. The latter point being key to delivering a customised experience across users and business processes.
Lightning API (Developer Preview)
The Lightning API is a REST API targeted at custom development use cases (mostly but not exclusively mobile) where the response payload can include data, metadata and layout information. Clearly the value-add here is efficiency – one API call to retrieve all the information that should be required to build the requisite UI/interaction. It should be noted that the API is rate-limited and will return a 503 if the limit is reached; careful client-side cache control logic should reduce the risk of this happening.
Lightning Experience – Filter Reports via URL
At long last it is now possible to set field filter values for reports via URL in LEX. This simple capability has historically played a significant role in most implementations; custom links on report detail pages, bookmarked reports etc. Good to see another LEX obstacle removed.
ISV – Subscriber Org Debugging
ISV partners now have access to the ISV Customer Debugger, meaning for each LMO a single Apex Debugger session can be run at a time against a customer sandbox. The Apex Debugger runs in the 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.
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.