Example of using dashboard context variables in experience view

Help
1

Hi Folks

I’m finding the documentation a bit sparse on providing details of using context variables to render variations of a dashboard page in an experience view. I’m struggling a bit to grasp the relationships between context variables names, endpoint replies, and the URLs that can generate the pages.

Mare there any examples anyone can share to make it more tangible?

Thanks

2 Likes
2

Here’s an example I just put together -

https://weathermap.onlosant.com/weather/58b7367d735a550001bbfe86

Clicking on the “View Device” link inside one of the map pins, or on the city name in the data table, will change the dashboard context by visiting a new URL. The currently selected device is referenced by the device ID at the end of the URL, which is passed down as context to the dashboard.

As for configuration, here are screenshots of the config for my experience endpoint, and the experience page that I’m returning for requests to that endpoint. The workflow backing requests to my endpoint is just a straight Endpoint Reply Node, replying with the page from my screenshot. Nothing special there.

Note in the page, I am setting it to return a dashboard page (my weather dashboard specifically), and I’m setting the “devId” context variable to the value of “request.params.deviceId”, which corresponds to whatever is in the “{deviceId}” spot from my endpoint.

Let me know if you have any more questions.

51%20PM

14%20PM

3

Thanks @Dylan_Schuster

That helps a lot.

A few clarifications if you don’t mind:

  1. I had been reading that the payload data always gets passed down on the pageData object but I noticed you were using request. Why the difference?

  2. How do you populate your state table with the device IDs? Is the table essentially a static list of cities or is the list driven from some other tags or workflows? You may already see where I’m going with that question - I am attempting to populate my state table with a dynamically filtered list of devices based on the experience user tags (a multi tenant approach).

Thanks!

4

The pageData object passed down to your views is of your own making; it does not necessarily include the entire payload of the workflow, but you can choose to make it so if you so wish. You can read more about constructing pageData for more info.

As for my example, I simply chose to set the context by a property in the URL, which in the dashboard example I provided allows me to navigate to other contexts via the links in the dashboard. If instead you wanted to have one master dashboard, but pass context down to it based on your user (so that each user saw device data relevant to them but all users got the same dashboard blocks / layout), you could instead set the context based on a tag on the user object. In that case you would set the value of devId to be experience.user.userTags.KEY_MAPPING_TO_DEVICE_ID.

In my example, the state table is a static list and it does not change based on the current context. But we are getting more and more requests for support device tags as context variables, so we’re looking into adding that support soon. Having that would allow you to build a state table with data from multiple devices all specific to one user.

5

@Dylan_Schuster

Much clearer to me now.

I believe your example mentioned in your second paragraph would be limited to one device per user, is that correct?

6

Correct. However, if you knew each of your users would have a set number of devices (we’ll say 3 for example), and each of those IDs was stored as a separate tag on the user object, you could still create 3 context variables in your dashboard (e.g. device-1, device-2, and device-3). Then, in your dashboard, you could create separate blocks for individual values for each device, or create blocks with aggregated values from common attributes on device-1, device-2 and device-3.

1 Like