Category: Salesforce

Plug-In Generation to Extend Salesforce CLI

When any team at Salesforce builds a new feature, we remind ourselves that every customer is unique. That is why we build features to be customizable and extendable. Salesforce CLI is no different: We know that as a developer your workflow is unique, and although Salesforce CLI comes with a great set of commands right out of the box, you might need something more. That is why the Salesforce CLI team worked closely with the Heroku team to give you the ability to create your own custom commands.

We call this Plug-In Generation and it is built on top of Heroku’s Open CLI Framework (oclif). When you run the Salesforce CLI command sfdx plugins:generate, the Salesforce CLI plug-in wizard leads you through the configuration steps for your new command and generates a plug-in project. You start with a scaffolded command, basically a fully functional “Hello World” command, and the project’s file structure so you don’t need to start from scratch.

Today, Plug-In Generation is generally available and we are open sourcing the Core and Command Libraries to allow you to dig into the code and if there is a functionality you wish to see, contribute back the repository.

What are we announcing today? Plug-In Generation is GA: We provide the scaffolding to get you going so you can build whatever you want. Plus, when you generate a new plug-in, there is an example command in the project folder you can dig into. A plug-in developer guide: The Salesforce CLI Plug-In Developer Guide walks you through the process of building a plug-in with examples so you can get going now. Open-sourcing the CLI Core and Command libraries: The Core Library is a NodeJS module that contains all the “core” utilities of the Salesforce CLI infrastructure. These utilities include authentication, config, project management, and much more. Your plug-in can use the Core library to access information in the same way the force:commands do. Explore the Examples folder in the repo, because you can do more than just Plug-In Generation with the Core Library. The Command Library gives your plug-in access to flag parsing, argument parsing and validation, and help: all the things that a good command should have. Using the Command library allows you to make your command consistent with other SFDX commands and to be user-friendly. What can I build?

If you already have custom scripts that you use with Salesforce CLI, revisit those scripts to determine if it makes sense to create a custom plug-in instead. Whenever you want to perform repetitive tasks and have to support multiple operating systems or work across multiple DX repositories a custom command or set of commands may make your team’s workflow better.

For example, let’s say you have a custom linting program that you want your team to run every time they push to a scratch org. You can create a plug-in that does just that.

Another example of a command that you can create might be to post to Chatter when

Salesforce Developers Succeed Together in the Trailblazer Community

You’ve found our blog and website, you probably have a Developer Edition org. But have you been to a Developer Group meetup in real life?

Whether you’ve been working with the Salesforce platform since the dawn of Apex (like me), you’ve just switched from another platform (welcome!), or you’re building your dev skills from scratch (keep on learning!), I want you to know there’s something different here, and it’s not just the platform.

The Salesforce Platform has world-class technology. It’s metadata-driven and multi-tenant. It’s trusted, fast, easy, and smart. In short, it’s groovy. But there’s a lot of cool technology out there, and the same can be said for other platforms. When I talk to Salesforce Developers, what I hear most is that they love the tech, but the key differentiator is the community. I also hear that from Bret Taylor, Salesforce President and Chief Product Officer, and co-creator of Google Maps and the Google Maps API, among other things.

 

“I’ve worked at a lot of amazing technology companies in my career but no company has a community like the @salesforce Community #TrailheaDX @trailhead #TDX18 @btaylor pic.twitter.com/nElhS3nXIP

— Charlie Isaacs (@charlieisaacs) March 28, 2018

So, if you haven’t yet stepped foot into a Developer Group meeting or joined a Developer Group meetup virtually, you’re missing out!

What’s a Developer Group?

Developer Groups in the Trailblazer Community are one of the fastest ways to learn best practices and get inspired by learning with and from your peers. There are hundreds of active Trailblazer Community Groups all over the world. These volunteer-led groups typically meet monthly to learn with and from each other (and Salesforce employees) and to inspire each other to achieve great things in their careers, companies, and communities.

Take a look on TrailblazerCommunityGroups.com to find in-person or virtual groups that interest you, and register for the next meeting!

Don’t take it from me — check out what our Developer Group members have to say:

Jigar Shah Melissa Hansen Philip Southern Sue Maass Adam Olshansky  

Ready to get inspired? Go to TrailblazerCommunityGroups.com and I’ll see you soon!

Awesome resources

Mary’s Favorite In-Person DG: New York City, NY Developers Group
Mary’s Favorite Virtual DG: Women in Tech Developers Group
Trailhead Module: Trailblazer Community Groups

About the author

Mary Scotton is a VP of Developer Evangelism at Salesforce and has been blazing trails with the Salesforce Platform since 2005. Originally a member of the Platform Product Management team, she led the development of many of the point & click app development tools that are still used today. She is passionate about educating, enabling, and having fun with the awesome Salesforce Admin and Developer community. You can find her on Twitter @rockchick322004.

Hands-On with Financial Services Cloud: Tying It All Together

This is the third and final part of the our blog series where we will cover some of the best practices for writing code that extends Financial Services Cloud and adheres to Salesforce’s security recommendations. We will also review some of the packaging nuances when building on top of Financial Services Cloud.

Before diving in here, you may want a refresher on parts 1 and 2 of this series.

Let’s start with the development best practices.

Writing secure code

While building managed packages it is important to implement secure coding practices to ensure that your package passes the Salesforce security review . Salesforce has published an Enterprise Security API library (ESAPI) to provide a convenient and easy mechanism to inject security best practices into your programmatic constructs . The source code published for the Drivewealth project referenced in the second part of this blog series makes use of this library extensively.

Just to refresh your memory, here is the sequence diagram that explains the high-level flow of the project.

The getDWAccount method of the DriveWealth.cls instantiates a util class and accesses the static methods to check for access control for the respective objects and fields within the object before returning the Account information.

public static DW_Account__c getDWAccount(Id DWAccountID){ //CRUD/FLS check //Chek for DW Account Util.AccessController.assertAuthorizedToView( Schema.DW_Account__c.getSobjectType(), new List<Schema.SobjectField>{ Schema.DW_Account__c.fields.Name, Schema.DW_Account__c.fields.Account__c, Schema.DW_Account__c.fields.Account_ID__c, Schema.DW_Account__c.fields.Account_No__c, Schema.DW_Account__c.fields.Account_Type__c } ); //Check for account as we also need it for that Util.AccessController.assertAuthorizedToView( Schema.Account.getSobjectType(), new List<Schema.SobjectField>{ Schema.Account.fields.Name, Schema.Account.fields.DW_User_ID__c, Schema.Account.fields.DW_Username__c, Schema.Account.fields.DW_Password__c } );

This Util Class returns the SFDCAccessController object from the ESAPI library.

public with sharing class Util { public static Boolean debug = false; public static void log(Object message) { if(debug == true) { System.debug(message); } } /** * @return the current ESAPI SFDCAccessController object being used to maintain the access control rules for this application. */ public static SFDCAccessController AccessController { get { if (AccessController == null) { AccessController = new SFDCAccessController(); } return AccessController; } private set; } }

The SFDCAccessController class also includes other methods (e.g. isAuthorizedToView) that enforce CRUD and FLS checks, which you can invoke from your package.

public boolean isAuthorizedToView(Schema.SObjectType someType, List<String> fieldNames) { return checkAuthorizedToView(someType, fieldNames, false); } public boolean isAuthorizedToUpdate(Schema.SObjectType someType, List<String> fieldNames) { return checkAuthorizedToUpdate(someType, fieldNames, false); }

Also note that the queries in the DataQuery class, which consolidates the queries used in the project, uses static text with variable substitution, thereby minimizing vulnerability to a SOQL Injection attack.

return [select ID,Name,Account__c,Account_ID__c, Account_No__c, Account_Type__c, Account__r.DW_User_ID__c, Account__r.DW_Username__c, Account__r.dW_Password__c from DW_Account__c WHERE Id=:DWAccountID]; }

This is only a sampling of the secure coding guidelines that Salesforce’s Security Review team will be looking for as they review your application. The coverage of the entire set of guidelines is outside the scope of this article.

Deploying the project using Salesforce DX

You can use Salesforce DX to deploy the sample project in this blog series to a scratch org or any other development org. The project’s Github readme files provides instructions and

Modular App Dev: Your Questions Answered

On our recent webinar Modern App Dev: Modular Development Strategies, we saw lots of great questions come in from our (wonderful and super sharp) attendees. We’re tackling the most common ones (that we didn’t get to during the webinar) here.

What tools were you all using?

We showed you a few different tools:

VS Code (the IDE we both used) Salesforce CLI Salesforce Extensions for VS Code (find installation instructions here) If you scroll down on the Marketplace Extensions site to the Documentation for Included Extensions section you can dig into the different extensions that are part of the extension bundle and their corresponding documentation. You can also check out the GitHub repository of the extensions, as it is an open-sourced project.

If you’re new to these tools, make sure to check out the resources at the end of this post.

Do we have to have use Salesforce DX or enable anything to get started? Can we just use sandboxes?

As we mentioned, Salesforce DX itself includes lots of tools and new features to help you build and deliver Salesforce apps. The Salesforce CLI, sandboxes, scratch orgs, Change Sets and unlocked packages could all be considered part of Salesforce DX.

So if you’re building and delivering apps on Salesforce (and not just building directly in production!), you’re already using pieces of Salesforce DX. But if you want to start building your apps and deploying changes in more modular, focused ways — yes, you’ll want to look at using more of the tools and features offered by Salesforce DX. But no, you don’t have to use every part of Salesforce DX in order to get started.

So what tools do you need to use to get started?
The real answer is the Salesforce CLI. You can install the CLI and use it to work with any kind of Salesforce org. If you want to get powerful connections to the Salesforce CLI from within your IDE, then you should also check out VS Code and the Salesforce Extensions for VS Code. Plus, there’s LOTS of other awesome stuff in those extensions.

As you work, you may find that you have to connect to a Dev Hub org in order to execute some CLI commands. We’ll talk more about that below.

Where can we activate a Dev Hub? Can sandboxes be Dev Hubs? Is there a cost to activating a Dev Hub?

Dev Hub functionality can only be enabled in production orgs and Developer Edition orgs. You can not use a sandbox as a Dev Hub org. There is no cost to enabling a dev hub functionality in an org. If you want to explore without enabling your production org as a Dev Hub, that’s fine. As of the Winter ’19 release, you can enable Dev Hub functionality in any Developer Edition org. (No more special sign-up!)

Be aware of that the type of org you use as your dev hub will determine the limits you’ll need to plan for as you work.

Connecting Your APIs with MuleSoft and Salesforce Identity

At their Dreamforce 2018 breakout session, Chuck Mortimore and Ashley Jose show some love for securely connecting users with data using Salesforce Identity and Mulesoft.

What’s MuleSoft again?

If you attended Dreamforce 2018, it was hard to miss MuleSoft. Considering the Integration Keynote: MuleSoft Connects Every App, Data and Device, multiple breakout sessions, and various booths, the MuleSoft Anypoint Platform was well represented. But in case you missed Dreamforce 2018 or you just need a refresher, here’s a brief overview of what the platform is and what it does.

The MuleSoft Anypoint Platform is a single, unified platform for connecting data, apps, and devices. With MuleSoft Anypoint Platform, you can design, deploy, manage, and secure APIs to unlock data distributed across resources, such as SaaS apps or on-premise servers. MuleSoft also offers increased operational efficiency. For example, you can reuse Customer Support’s order fulfillment status API to provide the Marketing department with customer purchasing history. To learn more, check out Getting Started with MuleSoft: A Quick Start Guide for Salesforce Developers.

MuleSoft and Salesforce Identity: Better together

Yes, MuleSoft Anypoint Platform rocks, but it’s even better when combined with the protection of Salesforce Identity — which is what Salesforce uses to secure CRM connections between customers, partners, and employees. Salesforce Identity is a composite of technologies (such as mobile-first identity, two-factor authentication, and single sign-on) that registers, authorizes, and recognizes users across digital channels. So when you combine MuleSoft Anypoint Platform with Salesforce Identity, you can securely connect customers, partners, and employees to the data they need to complete their jobs.

How do I build it?

By combining the awesomeness of MuleSoft Anypoint Platform with the superhero security of Salesforce Identity, you can safely expose your API assets and build accessible and reusable API networks. Follow these steps to configure Salesforce Identity with Mulesoft Anypoint Platform.

Step 1: Configure Salesforce to protect data stored in Anypoint Platform.

Start by calling Salesforce Customer Support to activate dynamic client registration and token introspection. Also, request an initial access token, which you’ll use in step 2. (Spoiler alert: These features will be generally available and you’ll be able to generate an initial access token in a future release.)

Set up single sign-on (SSO), with either SAML or OpenID Connect, using Salesforce as the identity provider. With SSO, your users can log in to Salesforce and access MuleSoft without a separate MuleSoft login.

Create an OAuth 2.0 connected app that integrates MuleSoft with Salesforce. You use the MuleSoft connected app to automatically create additional child connected apps in Salesforce. The child connected apps are needed for consumers to access data. (We’ll talk more about this process below.)

Mulesoft Anypoint Platform connected app created in Salesforce

Finally, configure the dynamic client registration and token introspection endpoints. The MuleSoft parent connected app sends a request to the dynamic client registration endpoint to create a child connected app. The token introspection endpoint allows the MuleSoft parent connected app to check the current state of an OAuth

Iterate Toward Greatness with Agile AI and Einstein Vision

If you work in any type of software development, you’ve probably heard about or used the agile methodology. Based on agile’s success in software development, the principles and processes have been applied to other disciplines, like project management, manufacturing, marketing, human resources, and even artificial intelligence (AI). Yes, these same principles and processes can be used to deliver data science functionality to your customers.

In this post, we cover what agile AI looks like in practice using an Einstein Vision project as an example. You can also apply all the concepts covered to Einstein Language. Here’s what we’ll do:

Follow the minimum viable product (MVP) principle to create a minimum viable dataset (MVD). Learn when and how to add a negative label to improve your model. Further improve the model by using feedback and progressively adding new labels. Agile AI

A key principle of agile is customer satisfaction through early and continuous software delivery. What does this mean? It means deliver something that customers can use and then continually improve and deliver in regular intervals.

In an agile AI approach, teams break down a data science project into small, manageable, and achievable chunks. The goal is to deliver something usable to the customer with each milestone. The team can then build on what they deliver and continue to incrementally improve.

Let’s look at building a car: Let’s say you’re on a team tasked with building a car. The customer’s ultimate goal is to get from point A to point B as quickly and easily as possible. This image illustrates what delivery might look like using a waterfall versus agile approach.

The waterfall method uses a linear approach to achieve the final product. However, using the agile method, you could first deliver a skateboard. A skateboard is nowhere near the functionality of a car, but it does get you from point A to point B. Then, in each subsequent iteration, you improve the functionality, always delivering something usable.

Data science projects can be high visibility and high risk. Taking an agile approach to your next data science project is one way to reduce risk and ensure success.

So what does an agile approach to data science look like? Let’s take a look at a scenario that uses Einstein Vision to classify images. In this scenario, you use Einstein Vision to create a model that identifies whether an image is an apple or a pear.

During this process, we look at how to approach the project in an agile way, and at techniques you can use to incrementally improve your model and its accuracy. In this scenario, we have three sprints (milestones).

Sprint 1: Create an MVD for your MVP

One agile term you might frequently hear is MVP, or minimum viable product. The MVP is the minimum functionality the team delivers in a given sprint with just enough features to satisfy early customers. Those customers can then provide feedback for future product development. In agile AI, we start with

5 Ways To Make Your Lightning Community Even Faster

The Lightning Community Builder enables you to easily build out beautiful, pixel-perfect digital experiences for your customers and partners using all clicks or a combination of clicks and code.

While the Lightning Platform is already very fast, there are several things that you can do to optimize your community load times for your users. Optimizing the performance of your community becomes especially important when you begin to build image rich pages or complex pages with lots of Lightning components, or your community members are geographically dispersed around the world. However, all of us want our Lightning community to load as quickly as possible and even the most basic community will load even faster with the following five tricks!

Use a content delivery network (CDN)

Out-of-box, all of the assets used to develop your community (CSS files, JavaScript libraries, images, etc.) are stored on your company’s Salesforce instance. For example, if your Salesforce instance is on NA1, your server is located in North America. The further your customers are from your Salesforce server, the longer it takes to get assets over to their computer and thus, the longer the page load time is for your community. This is why you should use a CDN.

A CDN is essentially a service that will cache your assets on servers around the world, so those assets load quickly no matter where in the world people access your community. We are happy to set you up with a Community Cloud CDN for no additional cost, or you can use your own CDN. Follow these steps to set up the Community Cloud CDN.

Turn on progressive rendering

There are two options for how your community pages load. One option is to load components in a serial fashion. If your pages load quickly, this is a good option for you. However, if you are seeing your pages take a while to load and discover that certain components are taking longer than others to load using the Community Page Optimizer, you might consider turning on progressive rendering. This effectively allows components to load in parallel and for you to prioritize the order in which they load on a given page. It is recommended to prioritize the items that are visible when the page loads over those that are only visible when scrolling down on the page for the best user experience. This is all set up through clicks — no coding required!

Enable browser caching

Rather than loading the same images over and over, you can enable browser caching, which will store a copy of the asset on your community user’s computer. This is enabled by default, so unless you’ve unchecked it, it should be set up and ready to go. Note: this feature is global and applies both to your internal org and all of your communities.

Use smaller image files

The more images that you have on each community page and the larger the image files are, the longer it takes for your computer or mobile

Understanding Experienced Page Time

With Winter ‘19, we have exposed Experienced Page Time (EPT) to everyone on the Salesforce Platform. This EPT metric, better understood as Page Load time, can be explored through the Lightning Usage App which highlights the performance at both a browser and page level. This blog post is going to help you understand how we define and calculate EPT.

Lightning Usage App

The Lightning Usage App is a new way to track adoption and usage of Lightning Experience so you can monitor progress and make informed decisions. With insights like daily active users, the number of users switching to Salesforce Classic per day, and the most visited pages in Lightning Experience, you can better understand your users’ needs and focus on the issues that really matter.

The app is available right from Lightning Experience. Simply click the App Launcher icon in the navigation bar, type Usage in the search box, then click Lightning Usage. In the app, you can click tabs in the ACTIVITY or USAGE sections on the left side of the page to view the associated data.

In the graph featured below, we are able to see the performance metrics for an example org leveraging the Lightning Usage App. This graph will vary from org to org as it is tailored to you. In this particular org, we can see that there was a spike in Android use in June and that Salesforce Mobile has the least EPT overall.

A view of the Browser Performance tab of the Lightning Usage App

 

In our next graph, we can quickly view the performance of our most viewed pages. We can see that in this org, Feed Items tend to load really fast, as well as Chatter.

A view of the Page Performance tab of the Lightning Usage App

 

Defining EPT

EPT is a performance metric Salesforce uses in Lightning to measure page load time. The idea behind this metric is to time how long it takes for a page to load so it’s in a “usable state” for a user to meaningfully interact with it.

The base definition of EPT may be simple, but a lot of things can affect it. We’ll explain more in the next section.

How do we calculate that?

A major difference between Salesforce Classic and Lightning Experience is that pages load progressively in Lightning, while pages in Classic are generated on request by the server. Due to the progressive loading from the client (that any loaded component in the page might arbitrarily load more sub-components at any point in time), measuring when a page has “finished” loading is not straightforward. Since EPT is the page load time that the end users experience, a lot of factors can come into play in calculating the value.

For instance, component implementation details, errors, and caching can all negatively impact EPT. There are also external factors like network quality, browser performance, and user interactions with the page while it’s loading.

Some other things

A Look at Robotics Ridge (DF18 Edition)

At TrailheaDX in 2018, a few of us Salesforce evangelists had the brilliant idea to build a demo with robots. The idea was centered around the Fourth Industrial Revolution and showing how Robotics and Artificial Intelligence could play a big role in our lives. We wanted to show how Salesforce could be at the center of everything; your customers, partners, employees, and robots.

After the crazy success and fun we experienced with Robotics Ridge, we decided we wanted to bring it back and make it better than ever for Dreamforce 2018. This is the story of what we added to our demo, what we improved and how we overcame the challenges we faced at TrailheaDX. If you want to read more about the original demo and challenges, check out Philippe’s post.

An order fulfillment system

Robotics Ridge was an order fulfillment process with two separate pipelines. We wanted to show that an ordering process could have two simultaneous flows, similar to a real production factory. The left side and the right side of the stage each ran the same demo, but could be controlled independently.

Image of Robotics Ridge before the show began.

 

If you look carefully at the image above, you’ll notice there are five different robots on stage. From the left to the right you will see an ARM, a custom Linear Robot, an ABB YuMi, another custom Linear Robot and a final ARM. Each of these robots worked together to pick up a requested payload and deliver it the front of the stage near the YuMi.

ARM

Image of the ARM robot on its own

 

The ARM robot is a robot made by the company GearWurx. It is mounted on a tripod and can be controlled in a few ways. It has a manual controller that has a slider for each degree of freedom, but we wanted the arm movements to be automated. We used a Raspberry Pi 3B+ with a servo hat. The ARM was also equipped with a Raspberry Pi Camera attached near the gripper. We wrote a Node.js app to control everything, from the movement to the picture capture.

Linear robot

Image of the Linear Robot robot on its own

 

Our linear robot was a custom robot we built just for TrailheaDX and then modified for Dreamforce. It is controlled by a Raspberry Pi 3B with a Pi-Plate Motor Plate for movement and an Aurdino Mega to control NeoPixel lights that would guide your eye to where your package is, all controlled via a Python script. The lights, not currently pictured, were attached to the front of the robot on the top bar near the cart. The build was inspired by the OpenBuilds Linear Actuator build and was created using Aluminum V-Slot beams from OpenBuilds.

YuMi

Image of the YuMi on its own

 

The YuMi is a robot from ABB. It is a human-friendly robot that has many collision sensors that keep