Einstein Analytics: Demystifying Bindings – Part 1

Creating dashboards in Einstein Analytics is easy and it becomes yet easier with every release. But sometimes you want your users to have even more dynamic controls in the dashboards and this is when you start introducing more advanced functionality like bindings. If you are new to Einstein Analytics or even if you have been working with Einstein Analytics for a while understanding the binding syntax can be hard. So I thought it was time to demystify the hardest part of it: the syntax.

A binding in Einstein Analytics is not just a binding. There are different syntax variations of bindings and it would be hard to cover every variation in one blog. In this particular post, I will be looking to give an introduction to the most commonly used binding; result and selection binding for compact form. Remember compact format is the default way a query is written through the UI, for advanced queries you can switch to SAQL.

Where to Use Bindings

I wrote that bindings can be used to give the users more flexibility in the dashboard. But what does this mean? Well, a dashboard consists of widgets (charts, number, text etc.) and steps, both have different parameters that can be defined in the UI. These same parameters can be overwritten with a binding to pass in a dynamic parameter. Hence you can use bindings to dynamically parametrize part of a query (the grouping, measure, limit, filter and order) or to dynamically change the color or label in a widget, which you can not do in the UI. The use cases are endless. If you want to see different bindings in action, I recommend installing the templated app “Learning Adventure” and check out the dynamic dashboard section. Note that from Winter 19 this it is no longer required to install the app from AppExchange, it is now available as a templated app by default.

Binding Functions

There are two types of binding functions; ‘result’ and ‘selection’ binding. And when you start writing your binding you have to determine if you want the binding to happen with or without user interference. When viewing a dashboard all steps are executed and any ‘result’ bindings will also automatically trigger to insert the desired values. In contrast ‘selection’ binding will need the user to click on the source step of the binding for the binding to execute and update the values. It all, of course, comes down to the use case, but an easy way to determine which one to use is to ask this question:

“Should my user click on anything on the dashboard in order to trigger the binding?”.

If the answer is ‘yes’ then you are looking to do a ‘selection’ binding. If the answer is ‘no’ then you need to use a ‘result’ binding. Generally, when you are using ‘static’ steps you are always working with ‘selection’ bindings – unless you can use the ‘connect data sources’ functionality – and when you are working with “hidden” steps you want to use ‘result’ bindings. You can check out my blog on static steps to see some examples for ‘selection’ bindings or check out the documentation. For an example of a ‘result’ binding check out my blog on how to make a gauge chart dynamic or have a look at the documentation.

Binding Syntax

Okay, let’s get down to the syntax of a binding. Instead of an actual binding, I have tried to include the different component of a binding.

"{{Data_Selection_Function(step_name.Binding_Function, Details_From_Reference_Step).Data_Serialization_Function()}}"

If we convert this into an actual example it could look something like below – in this particular case, it’s a selection binding.

"{{column(Step_1.selection, ["value"]).asObject()}}"

Binding Components

Let’s have a closer look at the different components of a binding as mentioned in the above syntax.

Data Selection Function: this function determines what data is being selected from a step or table. It can either be data from a cell, column or row.

Step Name: this is the step API name (not the label) where the binding should select the data from.

Binding Function: this is the type of binding that should be used; result or selection.

Details from Reference Step: this is related to the data selection function. It defines that field or column in the table to grab as well as what row should be used. The latter is only relevant for cell() and row() functions.

Data Serialization Function: this defines how the data is formatted for example a string with double quotes, an array of strings, an array of array, etc., so it is fit to be used in the binding.

Please refer to the documentation if you want more details.

Getting Started

When I am writing a binding, I ask a few questions in the process to determine how my binding should look. But before I start writing I, of course, have to go to the dashboard JSON (command+E or control+E)and find the source step and fields that I’m using as parameters in my binding.

When it comes to the actual binding the first step, however, is to write the basics; quotes and curly brackets. And please note that a binding is case sensitive. Generally, everything is in lower case but be aware of API names and data serialization – here upper case often appear.

"{{}}"

The second step is I ask the question we already covered: “Should my user click on anything on the dashboard in order to trigger the binding?”. This will determine whether I should use a ‘selection’ or ‘result’ binding.

"{{.selection}}"

The third step is to define which step do we need to take the selection (or result) from. Hence you need to know the step API name – not the label. You can always find this in the UI if you are unsure of the name.

"{{Step_1.selection}}"

The fourth step is to define data selection function. The question I tend to ask is “looking at the step we are referencing, do I want to have information from a cell or column?”. Technically you could also get information from a row, but the most typical use cases use the functions cell() or column().

"{{column(Step_1.selection)}}"

The fifth step is where I define the data serialization function. For this, I ask the question “what result of data from my referencing step am I expecting?”. By this I mean is it one value or an array of information? If you look at the data selection function it tends to be that if you use column() then you need to use .asObject() and if you use cell() then you should use .asString() as your data serialization function. Note this heavily dependent on where you are putting your binding, for instance, the “group” or “filter” section of a query requires arrays hence you should use .asObject() and a color value or label of a line in a widget is typically one cell value, which is why you would use asString().

"{{column(Step_1.selection).asObject()}}"

The sixth step is to complete the data selection function. We have defined if we want to use a cell() or a column() and which step to use, but we have not defined what information to take. So next we need to define the field we want to grab. Since we have defined that we are expecting an array of information (we used column), as a result, we need to wrap this in brackets. If we were just expecting one value (ex. cell) and using .asString() then there is no need to use brackets. Also, note that we need to escape the string by using “”.

"{{column(Step_1.selection, ["value"]).asObject()}}"

Now in this example, we are using column(), so we only have to define the column we want to use, but if we were using a cell() we need to also define which row to take the cell from. Also, in this case, we would not be looking at an array of information so we would be using .asString() instead of .asObject(). In that case, the binding would have looked like below.

"{{cell(Step_1.selection, 0, "value").asString()}}"

Following these steps completes the basic binding.

That Thing Called columnMap

If you are binding parts of a query like measures and groupings then there is one more step to remember. In Spring 18 a new parameter called ‘columnMap’ was introduced to steps and widgets. You need to make sure to set this parameter to null or make another binding, a walkthrough of how to bind to columnMap can be found here, or how to set it to null here.

Checking out the result

If you have followed all the steps and your binding is using the correct syntax then you should have a more dynamic dashboard.

A tip I would like to pass on as well is before you switch from the dashboard JSON to view your dashboard do make sure you copy the JSON for the whole dashboard. Sometimes if the syntax is wrong or you deleted something you didn’t mean to you may be forced to do a refresh, which makes you lose all your changes. If you have the JSON copied you can always paste it back in.

From teaching others how to do binding it is my experience that most errors in bindings happen because of incorrect references. By this, I mean that references are case sensitive, so if you are using ‘accountid.industry’ or ‘account.id.industry’ but it’s actually ‘AccountId.Industry’ then your binding will not work.

Finally, the best way to visualize or understand how the binding is being rendered, always view the ‘Query Details’ by clicking on the drop down of the widget then ‘View Details’ and then ‘View more details’ icon to see how the bindings are rendering and the values being passed. It’s a good way to debug if your syntax is correct but you are not getting the expected result.

Continue on and read more about bindings:

• filter bindings in SAQL
• grouping and measure bindings in SAQL
• date bindings
• nested bindings
• bindings in compare tables
• bindings on grain steps
• data manipulation functions.

All the bindings I have used in the above-mentioned blogs can be installed in any developer org by following this guide. If you are struggling to choose the right data selection or data serialization, then check out this blog.

Written by

Rikke Hovgaard

I have worked with CRM Analytics since 2015 (back then Wave). I started this blog to help make the journey to master CRM Analytics easy by documenting tips, tricks & cool solutions.

See author's posts