Einstein Discovery – Bring Your Own Model Deployment
Welcome to part two of the BYOM deep dive. In this post, we will take you through the process of deploying the model we generated in part one of this blog. Similar to part one, the overall structure of this walk-through is contained within two primary phases; some of which also have multiple steps:
- Deploying the BYOM Python model with Einstein Discovery Model Manager
- Generating predictions on Salesforce records with the Automated Prediction Field and APEX prediction channels.
Trade-Offs of BYOM vs. Native
Before we move on to deployment, there is an important topic we need to talk about first. In Part 1 of this 2-part blog post, we did not have space to consider the trade-offs between BYOM Python models relative to Einstein Discovery ‘native’ models. There are important differences in the capabilities of BYOM vs. native, so we will dive into that a bit before moving to deployment.
Einstein Discovery provides many unique capabilities when the models are built, deployed, and consumed within your Salesforce CRM environment. This is discussed in depth in the Einstein Discovery whitepaper. For our purposes here, we will focus solely on the key differences between native and BYOM models. “Native” in this context, means that the data, the machine learning, and model creation all reside on the Einstein Discovery platform – whereas BYOM uses data and modeling done outside the Salesforce platform.
The differences between Native and BYOM models can be summarized in four categories:
- Data
- Model Creation
- Deployment
- Prediction Consumption (aka Prediction Channels).
Data
When building Einstein Discovery native models, the data source for model training is always a CRM Analytics dataset. This data is typically ingested from one or more of the Salesforce clouds – and often from common external data repositories (e.g. Snowflake).
On the other hand, data for BYOM remains in another platform. The only data that is really moved into Einstein Discovery is the small validation.csv file discussed in part one of this blog. Obviously, there are many trade-offs to consider here. If the center of gravity for your data is in Salesforce, it will certainly make sense to consider a native model before resorting to BYOM.
Model Creation
Because Einstein Discovery is designed as a clicks-not-code ML tool, the modeling process is highly automated. Most of the complex parts of building a statistical ML model are hidden from the end user. This provides numerous benefits for the team building the Einstein Discovery model – speed, iteration, ease of use, etc.
On the flip side, BYOM makes the assumption that you have built a Python model that is created with custom code. The benefit is that you have complete control of the modeling techniques, algorithms, etc. Of course, that also means that model performance (good or bad), is all in your hands.
Deployment
The basic deployment process for Einstein Discovery native and BYOM models is similar, although you do lose some of the features if you choose BYOM. A partial list of the key items that are only available to native models is:
- Story Experience (Insights)
- Model Explainability and Actionability (top predictors, recommendations, etc)
- Model Metrics
- Automatic Model Refresh
Prediction Consumption
One of the real strengths of Einstein Discovery is its ability to deploy via many different “prediction channels”. If you’re not familiar with those channels, please refer to this excellent article. With the option to choose from different prediction channels, you can select the appropriate channel(s) that match your use case and planned end-user consumption (e.g. in a CRMA dashboard vs. a custom Lightning component). A subset of prediction channels available to native models is supported for BYOM. They are listed in the chart below.
Prediction Channel | Enabled for ED native model | Enabled for BYOM model |
Lightning Component | Yes ✔ | Yes ✔ |
Predict API | Yes ✔ | Yes ✔ |
Apex | Yes ✔ | Yes ✔ |
Async Apex | Yes ✔ | Yes ✔ |
Bulk scoring (zero day scoring) | Yes ✔ | Yes ✔ |
Einstein Discovery in Tableau | Yes ✔ | Yes ✔ |
Einstein Automated Prediction Field | Yes ✔ | Yes ✔ |
CRMA Recipes and Dataflows Predict Node | Yes ✔ | No ❌ |
Process Automation (Flows, Formulas, etc) | Yes ✔ | No ❌ |
Phase 1 – Deploy the uploaded model
Picking up from where we left off in part one of this blog, we are assuming that you have successfully uploaded the BYOM model with the necessary files in Model Manager. Now, we need to deploy it so that you can start creating predictions on your data.
Step 1
Locate the dropdown button at the far end of the row that contains your uploaded BYOM model. Click on it, and select Deploy.
Step 2
After you click on deploy, a popover appears (as shown below). Some of the information like Model Name and Prediction Definition might be auto-filled using the information from the prior upload step. You have the option to edit the model name or prediction definition name if desired. For our example, we will proceed with the names below.
As shown in the screenshot, we selected “Deploy as a new model with a new prediction definition”. This is the recommended setting if it is your first time deploying the BYOM model. If you want to add this model to an existing prediction definition (which could contain other models) – or if you want to replace an existing model, you may do that by selecting the other options in the dialog box.
Click on Next
.
Step 3
The next step in the deployment is to choose whether or not we want to associate the model with a Salesforce object. For the purpose of this exercise, we created a custom Salesforce object named “Car”. The fields in this object match the raw data and the input columns from the validation.csv After you have selected the relevant object that you want to associate with the model, click on Next.
Step 4
The next step involves mapping the fields of the object to that of the raw data input. As you can see, this step is done automatically if the names of the fields match the name of the columns in the raw data.
Click on Next
.
Step 5
The next step is segmentation. This option is particularly helpful if you have more than one model associated with the same prediction definition. Segmentation would help you configure which model needs to be used at the time of the prediction.
For more information on model segmentation, refer to this article. Since we are deploying the new model in a new prediction definition, we don’t need to use segments for now.
Click on Next
.
Step 6
The last step reviews all the settings you have configured for your model deployment. Once you’ve confirmed everything looks as expected, click on Deploy
to deploy the model into Salesforce.
Step 7
Upon successful deployment, you will be automatically redirected to the deployed model detail page where you can monitor the lifecycle of your model. You can also navigate to this page later by going into Model Manager and choosing your model from the Deployed
tab (see the screenshot below).
Your BYOM model is now deployed into Salesforce and ready to produce predictions on records! Once a BYOM model is deployed, the process to make predictions is essentially the same as with native models.
In the section below, we provide examples of how to deploy your BYOM model with two prediction channels – Automated Prediction Field and APEX.
Note: Please recall from the prediction channels table earlier in the article that these are not the only two options you have, we are simply using them as examples.
Phase 2 – Creating Predictions
Option 1 – Consuming BYOM predictions with Automated Prediction Field
Step 1
One option to score records is with the Automated Prediction Field and Bulk Scoring (aka zero-day scoring). Navigate to the prediction definition page from Analytics Studio (see below).
Step 2:
Click on Enable
for Automated Prediction Writeback.
Step 3
Select the Create a prediction field option. This creates a new field in your object where the prediction will be stored.
Step 4
Select Don’t monitor performance for now. Click on Save & Next
.
Choose Don’t refresh automatically as this option doesn’t apply to BYOM models. Then, click Save & Next
.
On the Quality Notifications screen, for now, simply click Save
.
Step 5
Navigate to the scoring tab as shown below.
Step 6
Enable Scoring by clicking on the Enable
button.
Step 7
Score all records by selecting the Score all records option and clicking Start Scoring
.
If you are ready to proceed, select Continue
.
Step 8
You can monitor the scoring process – it should complete in a few seconds (depending on the number of records that are being scored of course).
Step 9
The predictions are stored in the predicted_Fuel_efficiency field that we created specifically for this. This field is a hidden field in the target object by default. You can make it visible by navigating to the Object Manager page in Setup and configuring visibility for the field in the appropriate object.
And now you have prediction scores on the records in your object which can be displayed and used in the manner you prefer. Easy, right?!?
Option 2 – Consuming a BYOM model with APEX
Step 1
Navigate to the Developer Console by clicking the settings icon on the top right of your Analytics Studio and then selecting Developer Console
from the dropdown.
You will be redirected to the Developer Console in a new tab.
Step 2
Open the Execute Anonymous Window by clicking the Debug option in the top menu (as shown below), and then selecting Open Execute Anonymous Window
option. This will open a window where we can write Apex code that consumes a BYOM model.
Step 3
Edit the following code to reflect the Prediction Definition of your BYOM model and the record IDs of your target Salesforce object. In our case, it is the “Car” object we chose during the deployment of our model.
public class TestPredict {
public void testPredict() {
ConnectApi.SmartDataDiscoveryPredictInputRecords input = new ConnectApi.SmartDataDiscoveryPredictInputRecords();
List<String> recordStrings = new List<String>{'<CAR record ID 1>','<CAR record ID 2>', '<CAR record ID 3>'};
List<id> records = new List<id>();
for(String rs : recordStrings) {
records.add(Id.valueOf(rs));
}
input.predictionDefinition = '<REPLACE with prediction Definition ID>';
input.records = records;
ConnectApi.SmartDataDiscoveryPrediction result;
try {
result = ConnectApi.SmartDataDiscovery.predict(input);
for(ConnectApi.AbstractSmartDataDiscoveryPredictRepresentation pr : result.predictions) {
ConnectApi.SmartDataDiscoveryPredictObject predictionObject = (ConnectApi.SmartDataDiscoveryPredictObject) pr;
ConnectApi.SmartDataDiscoveryPredict prediction = (ConnectApi.SmartDataDiscoveryPredict) predictionObject.prediction;
System.debug(prediction);
}
} catch (Exception e) {
System.debug('Exception: ' + e.getMessage());
}
}
}
TestPredict tp = new TestPredict();
tp.testPredict();
If you need to, you can always obtain your prediction definition ID by navigating to the Advanced section of the Prediction Definition page in Analytics Studio. This is shown in the screenshot below.
In our org, the Prediction Definition ID is ‘1ORB00000008TzKOAU’.
To obtain the record IDs, navigate to the custom object page from Salesforce home as shown below.
In the above case, we could use a0RB000000nIly1 as an input record.
Step 4
Once you have pasted the code in the anonymous execution window (with appropriate ID’s), click on Execute
.
Step 5
After clicking Execute, you should have results in a few seconds. You can view them by going to the Logs
section in the bottom panel (as shown below).
Open the log by right-clicking on the recent entry.
Step 6
What we have done in the script is output the prediction value for the record Id with our prediction definition (BYOM model). You can see this by scrolling down in the log where you should find a DEBUG log with the value of your prediction.
For all you APEX developers, this provides record-level prediction scores for you to use in your custom solutions.
Wrapping Up
In this two-part blog post, we have provided an end-to-end example of the entire BYOM pipeline in Einstein Discovery. Everything you need to understand the process of creating a model, preparing for BYOM, deploying and scoring is contained in the two posts.
So now you are armed with the knowledge for bringing custom Python models into Einstein Discovery where they can be operationalized, scored, and deployed to your Salesforce or Tableau data. With this functional example in your hands, we are excited to hear your success stories! And with that, we wish you the best of luck in your efforts to use Einstein Discovery machine learning in your business.
Great content, Darvish and team, as always!
Thanks for the details on BYOM. It sure shows great value of CRM Analytics/Einstein Discovery~!
Thanks Gents. BYOM is such a positive and forward-looking appraoch of Salesforce, although it’s taken some time. Your details help us tremendously with getting started.
Is Data Cloud mandatory for BYOM for the models built in Sagemaker using scikit learn?