Einstein Analytics: Demystifying Bindings – Part 7

When we build dashboards and show the dashboard to end users they have an expectation to see data in a table view. Maybe not in the beginning, but for the most part they do want to be able to see the details. In Einstein Analytics we do this by adding a values table. But how can we make this dynamic? This is what this blog is all about.

Step types

Before digging into the binding it’s important to understand that a values table like any other chart on our dashboard is a step. If you have worked with the Dashboard JSON before you may know that each step has a ‘type’ parameter. Until now we have worked with ‘aggregateflex’ and ‘saql’ steps. These step types use the binding 2.0 format, but values tables do not (yet) use these step types, instead, they use the ‘grain’ step, which takes the binding 1.0 format. Yup, there used to be another way of doing bindings. Note that this is changing with the Summer19 release as values tables will be using the ‘aggregateflex’ step.

Binding with values tables

In my use case, I have a static step with three values and I want to allow the end user to select one of them, which will change one column in the values table. My static step has the following values:

"values": [
{
"display": "Industry",
"value": "Account.Industry"
},
{
"display": "Amount",
"value": "Amount"
},
{
"display": "Billing State",
"value": "Account.BillingState"
}
]

My grain step, in other words, my values table looks like below. Notice the step type parameter.

"ValueTable_1": {
"datasets": [
{
"id": "0Fb1t000000bvp8CAA",
"label": "Opportunities",
"name": "opportunities",
"url": "/services/data/v45.0/wave/datasets/0Fb1t000000bvp8CAA"
}
],
"isFacet": true,
"isGlobal": false,
"label": "ValueTable",
"query": {
"values": [
"Account.Name",
"Name",
"StageName",
"Account.Industry"
]
},
"type": "grain",
"useGlobal": true,
"visualizationParameters": {
"options": {},
"parameters": {
"borderColor": "#e0e5ee",
"borderWidth": 1,
"cell": {
"backgroundColor": "#ffffff",
"fontColor": "#16325c",
"fontSize": 12
},
"columnProperties": {},
"columns": [],
"customBulkActions": [],
"header": {
"backgroundColor": "#f4f6f9",
"fontColor": "#16325c",
"fontSize": 12
},
"innerMajorBorderColor": "#a8b7c7",
"innerMinorBorderColor": "#e0e5ee",
"mode": "fittocontainer",
"numberOfLines": 1,
"showActionMenu": true,
"showRowIndexColumn": false,
"totals": true,
"verticalPadding": 8
},
"type": "table"
}
}

Looking at just the query above I want to replace the industry with a dynamic value from my static step. As you can see below the binding looks different from what we have been covering in this blog series and what we completely demystified in part 1 explaining each component.

"query": {
"values": [
"Account.Name",
"Name",
"StageName",
"{{value(selection(Static_1))}}"
]
}

As you can see the binding is pretty simple and contain some of the same things we are used to in the bindings 2.0. Before we look at the above specific examples let’s have a look at how the simplest binding would look like.

{{selection(source_step)}}

In the example above we can see all we have to define is the binding type, which in this case is ‘selection’. We could also use ‘result’. The next we have to define is the source step. And that is it. If we compare to the binding 2.0 syntax we are really only looking at our data serialization, which is simplified greatly. Hopefully, you can see how powerful bindings 2.0 are in comparison.

Now we can add a bit more to our binding 1.0 syntax. As you see in the actual query we have added the operation value(). This specific operation allows us to transform the array into a single value. In other words, this is similar to what the data serialization does. Using the value() operator we end up with the following binding.

{{value(selection(source_step))}}

Adding this knowledge to our value table you can see all that we are defining is that we are using a selection binding from the static step called ‘Static_1’ and that we want this to be a single value. Hence we end up with the following.

{{value(selection(Static_1))}}

There are more operators

We didn’t cover all the binding 1.0 operators in this blog. If you want to see the other operators you can take a look at the official documentation to find all the possibilities you have with bindings 1.0. You may wonder why I won’t cover it here since this blog series is all about demystifying bindings. Well, bindings 1.0 is something from the past that we rarely use because the step types we use with the exception of ‘grain’ steps do not support bindings 1.0. And with the Summer19 release, that is just around the corner, values tables will be using the ‘aggregateflex’ step and thereby the bindings 2.0 syntax.

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