Brandon Cannaday: Good afternoon, everybody. And good morning or good evening wherever you might be coming from. And welcome to our Deeper Dive Webinar. So, for anyone that's new, our Deeper Dive Webinar Series kind of covers two different topics. One is more solution-oriented where one of our solutions engineers will come on and talk about how we can take a lot of different functionality within Losant and combine that into a more complete solution. And then, what we're doing today is one of our platform update deeper dives. Usually, we time these around new and interesting functionality where we take a kind of a deep inspection of that new capability and what it means for you as Losant developers. My name is Brandon Cannaday. I'm the Chief Product Officer here at Losant. I'll be talking most of the time but joining us specifically for Q and A will be Dylan Schuster who's our lead UX Engineer and Erin Thompson who is our Senior Software Engineer. So, these are the two engineers that did most of the development on the specific capability we're going to cover today. Speaking of Q and A, generally, I like to keep the content within about 30 minutes and then we leave the second half of the hour open for Q and A. We're using the Zoom Webinar Platform so you'll see somewhere on your interface, I believe it's near the bottom, there's a button that says Q and A. At any time, if something pops into your head, you can click that and type a question, and once we're done with the main content, we're going to go through those. And we've got Dylan and Erin to help on any technical questions, and I'll be here to talk about anything else. So, like I said, at any time during this Webinar, if something pops in your head, you’ve got a question, don't hesitate to get it in the Q and A section and we’ll get it answered if we can at the end. If you're new to Losant, in general, what we are is an application enablement platform. So, we provide the foundation with a set of tools that really come together to deliver new IoT experiences or IoT services. So, it's all one platform. If you get Losant, you get everything, but we like to talk about it kind of in these five major components, really helps to describe where our platform begins and ends. It starts down at Edge Compute which is a software agent that runs on Linux gateways, helps bridge that gap between your local environment or equipment, and the Losant platform may be running in the Cloud. And it goes all the way up through end-user experiences, basically delivering back to your customers in a completely custom, white-label branded way, all of that valuable IoT information. Today's webinar is going to spend a lot of time on that end-user experiences and some of the new capability that we've introduced there. We’ve provided this platform and this foundation for a lot of customers, big and small, across a wide variety of industries mostly in the industrial and smart environment spaces. So, a lot of the customers that I'm showing on this slide have made use of our Experiences functionality to [Distortion 00:03:08] solution to their customers. And we’ve designed this new capability around what we’ve seen they do, what we've seen them build workarounds for. And I think anyone currently, or is a current developer of Losant, is really going to like what we’re going to introduce today. So, that leads me into the content. We're going to cover Nested Experience Groups. And what we found over the years is Losant, I think, is uniquely positioned to deliver these end-user Multi-Tenant IoT applications compared to a lot of other platforms specifically in the industrial space. We've added a lot of capability when it comes to delivering an ended…end-branded experience to your customers. And the major part of that is multi-tenancy. You might have a ton of devices in your application. You want to have control over when someone logs in, which devices do they get to see, which should they see, and how do I design that tenancy model within Losant. So, prior to this update, it was less technically possible. You had to do some kind of sophisticated linkage between your resources maybe using tags or data tables. But we’ve really brought that in as a first-class support through first nesting your user groups and then a built-in first-class association between our devices and those groups. And then, we’ve surrounded that with a lot of capability to utilize that new model. So, what I think is probably the best way to demonstrate kind of multi-tenancy is really looking at an example, an example application. And we built out this… It’s a pretty complicated full end-to-end multi-tenant application based around the concept of a hypothetical company called Kanarra Technologies. And Kanarra Technologies is a manufacturer of those large industrial generators that you see at a lot of hospitals. But what they wanted to do is build and offer a service to their customers that are utilizing these generators in order to remotely monitor these applications. And if you think about generators at hospitals, these are critical pieces of equipment. So, if the power does go down, these things need to work. They need to be maintained very well. They need to have a lot of confidence that if they need to turn on and run, they will turn on and run. So, what Kanarra has put together here is a hierarchical multi-tenant solution where their direct customers are the hospitals. Those hospitals, in turn, have a set of regions, and within each of those regions, they've got multiple facilities. So, the actual generator, the actual devices, and equipment is sitting at each facility. You might have one, two, maybe up to four generators per hospital, depending on the size. So, new customers or new users coming to Losant, if this is your first time, you're going to really like the capability I'm going to continue to show because it really is a very clean and easy way to model this kind of hierarchical tenancy model. If you're already a Losant user, you may have already gone through the challenge of maybe putting some workarounds but everything we release is backwards compatible so it should be fairly straightforward for you to also adopt this in your existing applications. But what we want or what Kanarra wants is any of their customers to be able log in at any level in the hierarchy and see the information about these devices and any devices beneath them. So, for example, if you’ve got a Regional Facilities Manager maybe assigned to the California Northern group or region, they should be able to see the information about all the devices beneath them at every facility inside that region. So, let's jump into the actual Kanarra app. I'm going to login as somebody in this level in the hierarchy and we can kind of see the application from their perspective. The first page that’s going to pop up here is a fairly custom interface built entirely within our existing views capability but it really does showcase a lot of the new kind of multi-tenancy capabilities that we have. On the left, it's got a list of the groups and the subgroups where that user starts so I log in as a user assigned to the California Northern group. I can get to see all the groups beneath me. I can check these, toggle this on and off, to see devices specific to each of those groups. I've got an overview map using Google Maps showing a distribution of where all my devices are. And then, I’ve got a list, basically a grouping, of all the devices associated with any selected group. So, if I log back out, I can log back in as maybe somebody higher up in this tenancy model. We can see this experience from a different perspective. So, let's log in as the actual OEM, so Kanarra. They are the manufacturer. There’s a lot [Distortion 00:08:10] actual manufacturer of this equipment to get this visibility into all their field and equipment. So, now you can see my view has changed and it's changed simply because I logged in as a different user. Now my tree of subgroups, regions, and customers is much larger because I’m the OEM. I share the information about all of my field and equipment. The map has got a lot bigger. I’ve got devices out here in Hawaii, San Francisco, and some in the Midwest. And then my overview of devices has also gotten quite a bit larger showing a quick view into which devices might have some problems, some low fuel, some maybe…here's a fault, low oil pressure. But then what I can do is if I have a device that I want to dig a little deeper in, I can click on one and I can see a totally different view into this application's devices. On the left now, I have a list of every device that I should have access to as this logged-in user. And since I'm logged in as the OEM, I’ve got quite a list of devices. On the right, is what we call a dashboard experience page. So, we’ve had this capability for quite a while, and it allows you to build an Experience page and then embed an existing dashboard into it. So, if you've got all this work done for dashboards, you don't need to re-implement it on a custom view, you can take that work and embed it directly in a page. This dashboard, however does show some unique capability. So, at the top, I've added an overview kind of section, maybe an overview dashboard, or in this case, a section of an existing dashboard that shows an overview of all the devices that I am associated with as this logged-in user. So, I got that map, same map using our building dashboards. Then I'm using some widgets that will do a cross-device aggregation. So, prior to this update, that was a pretty challenging thing to do, to know and to scope, or define context for a dashboard based on the currently logged-in user. You had to do some sophisticated work with device tags and then associating those tags to users. But with this update, we've done a lot of work making this model, this tenancy, and this device association usable in other parts. So, before I get into some of the dashboarding capabilities, I'm first going to dive into the platform and talk about the actual device group configuration. So, now I’ve switched to the platform itself. For any current user, you may have been exposed to the Experience's functionality before. The first thing you might notice is the users' and groups' application menus have been combined together. And just so everyone’s aware, we did release this last week. So, if you sign in, you will see all of these new capabilities. So, what I'm demoing right now is all live and in production. We combined these menus because the users and groups are very related resources and it made a lot of sense to be able to edit and work with those from a single view, so that's why we’ve merged those together into one tab. And we've had the concept of groups for a long time. You were always able to create Experience users and always able to group those users into various groups. But with this release, we've added two major new pieces of capability. The first, and probably most important, is the direct first-class association to devices. That’s what's shown here. You can associate any devices you like. You can pick them manually, explicitly associate devices. What I would recommend is you use the existing device tag functionality. So, if you are already a developer within Losant, you already have an application. It's very likely you've already got some kind of tagging structure on your devices to organize them. You should be able to piggyback on that and just kind of bring that directly into your experience groups. And the next capability that we added to these groups is this nested structure. So, parent groups can have multiple children, allow you to build this hierarchy of group structure. And what that allows us to do is some really interesting queries about who has access to what devices. So, if you recall from a moment ago, I was logged in as the California… This user here, user that’s assigned to the California Northern group, if I look at the devices directly associated with that group, I have none, it's because I don't need to have any. Parent groups automatically adopt all of the associations from child groups. So, even though I'm logged in as California Northern, I have no devices associated directly with my group. When I ask some other parts of Losant, which I’ll show in a minute, which devices should I be able to view, we will return… We’ll automatically traverse this tree and return and find all those devices for you. Now, what I want to show is kind of how to utilize some of this capability. What we've done with this release is greatly improve the integration between our experiences functionality and the rest of the Losant resources. So, we've got this device association. We’ve made a very easy to kind of query which devices should be associated with which users. We rolled that ability out to a lot of different places within Losant. The first one we'll talk about is dashboards. So, again this dashboard includes this overview block. I'm a logged-in experience user. I need to be able to display all of the devices associating with me and all of my child groups. So, let’s dive into this dashboard and see how that's done. So, I just switched to the platform itself. This allows me to edit this dashboard. And what I’m going to show first is a new context variable. We’ve had context variables for a while. What we’ve added with this release is a new context variable type that is an Experience user. So, now you can pass into a dashboard, basically, the user that you would like that dashboard to display information about. It works just like all other context variables. You give it a name and you get a default value. So, this is when you're editing the dashboard, it at least gives you some information to preview. Let's look at how I use that. I’ll first jump into this GPS history block that’s showing a distribution of all my devices. Let me edit that. And what you'll see is right here, I'm using that context variable as a device selector. Whereas before you could always choose specific devices, you could choose devices by tags, now you can use the Experience user as a device selector. And if you choose that, Losant will automatically go look up in that group structure that I just showed all the devices that should be associated with my user. And that's what's displayed over here. So, I’m showing the last received data point of every device associated with me and then you get this distribution. They’ve made it very easy to bring that Experience’s capability into the dashboard themselves. We also had a really nice tool and helper in order to preview what a dashboard might look like from the perspective of your users. So, if you click the drop-down up here, we've always had the ability to quickly change context variables. But now you can also choose any user and we’ll change that context variable before you and you can see what the dashboard looks like from that user. If I switch just the California Northern, apply, you'll see all of my information will change and my device locations will update to only include some devices in that Northern California region. So, very quick, powerful way, while you're editing a dashboard, to see what it might look like from a different user’s perspective. When it comes to getting this information into the Experience… So, you have to be able to pass the context variable. In this case, we're passing two context variables into this dashboard. One is the device, which populates all the information down here, and one is the Experience user itself which takes care of passing or populating all this information up here. So, if I switch to the actual page, we’ve had this concept of dashboard pages for quite a while, what I'm showing is just a dashboard page. My page type is dashboard, Generator details is that dashboard I was just showing, and at the bottom here is where these two contact variables are passed in. And what's nice about this is there's really no workflow required behind the scenes because Losant provides a lot of this capability for you. When I go back to this page here, we’ll see the device that I want to view is on the URL parameter. So, every time I click one of these, what I'm doing is basically reloading this page and updating this URL parameter. The Experience user itself, that’s just automatically provided by Losant. Any time an authenticated Experience user makes any requests, we will add this experience object and the user object that did it. So, these two context variables are passed in just from the information we're providing for you. We're automatically parsing that query parameter and we’re automatically giving you the user ID so you can pull those off of the context available for the page and pass them directly into the dashboard. So, no workflow required. You can create kind of these user-driven, context-driven dashboards. However, there is an interesting side effect that comes with this. If we just take whatever device ID that they typed in and pass it straight through to the dashboard, there's a chance a user could view information they're not supposed to see. If they just stumble across the device ID that's not in their group structure, there's nothing in line here that's preventing this dashboard from just showing that device. So, we are going to use a workflow behind the scenes and then we're going to talk about some additional new capability on the workflow side to make use of this tree or this group structure. Before I do that, I want to show this diagram. I showed this in a previous deeper dive but it's very important to understand how data and information flows through our experiences engine. It all starts from an endpoint request. So, if we go back to that page again, you'll see that up here. This is the endpoint request. I'm hitting URL, slash device details, and providing some information. That’s a browser making some kind of request. Now, that starts everything. Then we've got work [Distortion 00:18:41] endpoint request. Losant itself will take care of automatically parsing all of the information if the information is posted at the endpoint or if it's on the query params. All that’s automatically parsed and provided in the starting Payload for that workflow. Then the workflow is responsible for doing whatever it needs to do. In this case, it needs to validate what was the device ID that was just sent to me should that device ID be exposed to the currently logged-in user. And then this page, also if I switch back, this page also has a list of all of the devices that that user should have access to. When this page loads, that workflow gets triggered. The workflow does a query giving me all the devices I’m supposed to show on the list and also validate that this user should see the device that's on that URL. So, if we start from the endpoint itself, this is the device detailed endpoint, nothing's changed here. We are restricted to authenticated users. If they're not logged in or authenticated, we just redirect them to the login page. And then here's where we say, “Well I can't just render it out statically, I do need to use the workflow in order to make some decisions and get some data in order to properly render this page.” So, if we jump to that workflow, this is it. You can see it's very simple. Again, we just trigger from the endpoint. The important note here is this device verify. So, the device ID… I'm pulling it here from the Payload. I get the full device up here to make sure it exists. But I can do a quick comparison or quick validation or verification that the device ID that was passed in matches or it is associated with the Experience user that’s currently logged in. So, this Experience user is automatically available on the device that is coming in through a query parameter. And this will traverse that tree, so this verify node will check the current group that the user is logged into or assigned to and it will also check all child groups. Remember, the model that we have adopted is kind of this hierarchical, parents do adopt associations from children. So, if you assign a member…a user into a parent group, it's really important to remember that they will be associated, all these verify nodes will pass if that device is in any child of that group [Phonetic 00:21:01]. Then in order to populate that list of devices on the left, we've extended the device get node with some new capability. So, because we have this model that we can go query, we can now look up all the devices associated with the user or a group. In this case, I've got a user, they’ve requested the page, they're authenticated, I know their ID, now I need to get a list of all the devices that are associated with that user so I can put in a list on the left. I'm using the new Experience user ID or you can put the email of the user if you choose. I’m pulling the user ID from Payload that's automatically available and then just adding that back to the workflow that’s eventually then sent to the page when I render it. So, I render the device details page and I give it my entire working object that includes all the devices and all that information. So, at that point, it kind of switches over to the views side to display it in that kind of custom way I showed. So, this shows a couple of custom new nodes, but while we’re in the workflows, I do want to switch back to the device group and talk about some of the other nodes that we added in order to make it possible to render a page like this. So, if we look at this page, you'll see on the left, we've got a tree view, kind of a summary view of all the group information. And when I logged in at different level, the tree started there. So, I need to be able to query that hierarchy in order to render this tree view appropriately. Then if I change this and just pick a couple of specific groups, I also need to be able to query other devices associated with groups. In this case, I'm not doing by user ID, I’m doing by groups. So, I can add these sections here for each group, and then I can render the devices into those sections. There's a lot of just tenancy-associated data that I have to be able to query easily in order to render a page like this. Let’s dive in into the workflow that backs this and then I'll dive into some of the actual views and the kind of handlebars in HTML that comes together to make something like this. Let me switch to the page, Workflow. So, this is the workflow that renders the homepage. Again, it's very easy. Our new capability has reduced the complexity quite a bit when it comes to building something as complicated as what I'm showing. The first is the group summary node, that's what controls that list view on the left. And again, all the information is automatically provided when a user requests an endpoint. We provide you all the user groups. In this case, I've just taken a best practice that I assign users to just one group. You can do multiple groups but for a kind of hierarchical model, if you do implement a model like that, it's probably best to try to organize your users and just assign them to one group. And you can use that nesting structure to provide them access or a disassociation to data just based on that tree. So, I grab the first group and that's going to be the one they're assigned to. And the summary node gives you this high-level data structure of those groups and then their children. It’s in a model…a data structure that’s easy to render with handlebar helpers. So, then I've got multiple selected groups. So, if I come back to this page, I've got two selected groups so I need to be able to ask this workflow what devices come with each of these groups. And these groups are added to the URL parameter up here, its query parameters. So, when I select them and hit apply, basically, I’m just reloading the page and providing these up here. So, I can iterate each of those and ask what devices go to each one of those. So, I’ve got a loop here. It’s iterating over the selected groups. And then we’re using two new nodes here or one new node and the extension to an existing node. The first is the group get, so this allows me to just get all the full information about that group if I wanted its name or additional information. We do have group tags now so we can display any additional information we want. Then we use this other new extension to the device get node that allows me to query all the devices by the group ID. So, where previously I was querying by user ID, now I want to show the list of devices per group so I'm using this new additional option to obtain the devices that way. And again, they're all just added to the Payload and then sent up to the page in order to be rendered using the Endpoint Reply. And I'm showing my home page and passing it my Payload object. So, now I'm going to get into a little bit of the actual experience side of how this comes together. And that is a pretty major use of our Experience Views functionality. So, views have been around for a while and there’s really nothing new in Views related specifically to the Experience groups functionality but we've heard a lot of feedback from you guys to dig a little deeper into the Views so that's why we kind of created this reference application to set down some best practices on how all of this should come together into a larger-scale application. So, whereas you can edit all the Views to the interface, I prefer to use our Command line tool. If you haven't adopted this for developing your Experiences, I would definitely recommend it. It allows you to edit everything locally using your favorite browser or favorite editor. I prefer Visual Studio Code but you can use whatever you want. And then, this tool will take care of synchronizing that with the Cloud for you so it really reduces the time it takes to develop these types of applications. So, now I'm going to change my screen share because I'm going to bring up my Visual Studio Code Editor and we'll see kind of how this came together. So, what I'm looking at now is the views, they're all of the visual components that make up an application like this. And there's a lot going on inside this Kanarra application so I can't go through all of it, however, what you'll find is we have open-sourced this. So, this is a great place to come check all of this implementation to see how this is put together and someone’s going to drop a link in the Slack here very shortly. Or not in the Slack, in the Zoom chat here very shortly. We'll also drop a link to this into our forums after the Webinar concludes. But all the information, all the files, all the source code, all the workflows, basically everything that makes up this application, you can go check out and explore and kind of see how this whole thing comes together. But I do take a moment and talk about some just specific points within this that I think are worth talking about and demonstrate some of the hurdles and bottlenecks that some people have run into. The first is just file organization, file structure. The Views capability is pretty flexible, you have to have a lot of leeway into how you would like to organize your project. And this is what I've adopted. I found this to be very successful. If you look at the folder structure over here… If you're not familiar with the CLI, this is kind of the folder structure it creates. You don't get the data tables and devices, that's added as part of the open-source project, but you get Experience and files. And within Experience, you'll get Components Layout pages, and then you also get all the files. And you can edit all these locally and then push them up to the Losant platform. I have found using Components to store or edit all of my JavaScript and CSS to be a pretty successful tool. So, I adopted that because our Experiences functionality has built-in versioning. So, I consider the JavaScript and the CSS to be a major part of a version of an application. So, I would like that all bundled together when I snapshot an Experience and continue developing. A lot of people do use the Files functionality to store that as well, and that’s perfectly fine. You'll find Files to be a little more efficient because that is backed by a CDN, however if you do put Information in files, you have to implement your own kind of versioning scheme on that. But this has worked out really well for me, and maybe it’ll work pretty well for you. So, file standard, I just prefix in with JS, prefix in with CSS, and that allows me to create a script tag. And then, our server-side rendering, when we render the components, will pull all the information out and just drop it right in the script tag. You can also update if you use Visual Studio Code. You can do a QUIC Google. I made a slight change to File Association Logic. Usually, it’s by file extension so all of our components are handlebar templates so they're going to be syntax highlighted as handlebars. But you can change users to a code that if it starts with CSS or JavaScript, it will syntax highlight appropriately. So, it’s something to look at if you do pick up this technique. The second thing I want to show is getting page data into JavaScript. This is something that might be a little difficult to just stumble upon if you're a new developer. This isn't as intuitive as it could be. But in this example, if I switch back to this application, I'm making pretty extensive use of Google Maps up here in the Overview one down here. These are all Google Maps. And really the only way to add pins or utilize Google Maps is through JavaScript. So, I need to get my information into the JavaScript plan so that my scripts can access my device's location in order to render those on those maps. So, this is a nice little trick you can use. That workflow that we just looked at is putting all the selected groups on there, and those selected groups do have all the devices with each one as another property. If you use the JSON and Code Helper, this will result in a perfectly formed JavaScript object. And if you assign that to a variable, you can just use that anywhere else in the application, any other script beneath it. So, all these scripts here that are rendering maps, they're able to reference kanarra.selected groups and get access to that information. And the last thing I want to show before we wrap up here is the component hierarchy. How do pages, and components, and subcomponents all work together to render something that’s complicated like this? This is the main page. This is my home page. This is the actual page that takes care of rendering everything here. But I made really good use of components so that my HTML doesn't get overwhelming and large. It keeps my file small, keeps them easy to maintain. So, you can see I’ve got a sidebar component and device groups component. The side bar’s everything on the left and the device groups is everything on the right. I’ve created a diagram here to kind of illustrate how all this comes together. On the far outside is that page Home. That's what I’m just showing. The sidebar component renders that nested checkbox list. I've got a device groups component, everything on the right, and it’s made up of one or more device group component. And then, that device group renders one or more device block components based on however many devices might be owned or associated with that group. So, this is kind of the visual hierarchy that I've adopted for this project. You can kind of see that here, there's those two components. And I’m going to just dive into the group and this represents just one group. I might have multiple groups each made up of multiple devices. We can see how small these components can be. The first thing I'm doing is using some handlebar helpers to determine if the entire group is healthy or unhealthy. The workflow… I didn’t show it but the workflow is actually iterating all the devices and checking some state information and then marking the entire group as healthy or not healthy. That allows me to do an indicator like this along the left side of the group. So, if I've got a lot of devices, I don't really need to pay attention to a group if it's green, however if I do have a device that has an issue, I can immediately go there and see what's going on. Then what we do is we iterate all the devices that belong to that group. And this is information the workflow is adding to each selected group object. So, I'm using each helper, all the devices, and I'm rendering for every device the device block component, and then passing in the device so that this keyword represents whatever we’re iterating over in the outer helper. So, if I go into device block itself, this one’s fairly large. There's a lot of information that makes up one of these device blocks. You've got the model. You’ve got its stage. You've got a serial number. You’ve got a picture. You've got the location, and you've got some information down here, fuel level, any [Distortion 00:34:25] codes if it’s healthy, etc. So, this is all the information that represents that. I like showing this one off because it does a great job of showing how you can use handlebar helpers in a custom view to really display information in a variety of ways. So, we've got just a straight string. So, I’m just pulling the model tag off the device and just putting it on the screen. That's right here, this model tag. Then, I'm controlling the link. So, when they click a device and you take them up to that dashboard page, but that device…a query parameter needs to be set appropriately to the ID. So, I'm rendering the ID as part of the link URL. I’ve got a really clever use of some data attributes that allow us to change the color. That's that overview, that summary [Phonetic 00:35:09] color up here, let’s me do some CSS to determine whether or not the entire device is unhealthy based on either its faulted or maintenance mode and even some business logic. In this case, I'm doing a less than for fuel levels. So, if the fuel level is less than 25%, I'm marking low fuel as one. So, you can use handlebars to actually implement some display in slightly more complicated logic like this. We’re using some composite state. So, when you do use the get device node, there's a check box. A call also includes composite state. What composite state is, is it will return the last reported value for all attributes so they can report at all different times but it’ll collapse all that down. We call that composite state so you can get and access the last known state for all attributes on that device. We also use it to populate an image. So, I store the image of that device. I put it in files so there's a folder that's called Device Images, and then I have a tag that stores where is the picture of this device. So, I can use that information to render an image and then again use some composite states down here to render those small indicators for health. And then, here's where that map is placed. I use the data tag here pulling out the location attribute. In this case, I don't… These are fixed. They never move so I don't need an attribute for location. I just put it on a tag because the location… Once a generator’s installed, it never really moves around so that lets me… I just pull that off from a tag. And then, there's some JavaScript that runs. I'm not going to get into that. This is open source so you can check that out. That pulls the location from the data attribute and then puts a pin on the map. I'm a little bit over so I’m just going to come back here and just reiterate one more time. What we've shown here is primarily that new hierarchical Tendency model where you can create this nested tree structure and then that first-class association from the devices into those groups. And then, I got a little bit into the Views where you can…it shows how to present this information on the page. And then, if you want to go check out this repository, if you really want to dig into it and see how all this comes together, feel free to. You can even log in. I’ve created a non-admin Kanarra user, that’s what I just logged in. You can go click around. You'll probably find ways to break it but this is an open-source repository so all requests welcome. And yeah, you can go play with this Experience and also see how it’s implemented. So, at this time I'll open it up the Q and A, looks like we've got some questions in the pipeline. But before I jump into that, I'll talk about some resources that we have for further learning. One is documentation, no feature goes out unless it's fully documented. And this was a major extension to our groups so all of the groups documentation has been updated. You can go check that out if you want to see all…maybe the lesser-known features that I didn't get to. Forms are a great place to ask general how to [Inaudible 00:38:17] or how do I type questions. If you're not sure how to use some functionality of Losant to deliver what you're trying to achieve, ask it on the forums. We got a fairly active community, sometimes other developers will jump in there, our internal support team is always monitoring that and helping out wherever possible. We wanted to wait for specifically this functionality before we created the Experiences Course in Losant University; however, that course is underway using actually the Kanarra application as an example and also going to be showcasing a lot of this hierarchal group structure. So, look forward to the new Experience University course here soon. And then, our blog, we continually post just random tutorials across a lot of different topics on our blog. So, that’s another great source for material. So, at this point, I am going to open this up for questions. It looks like we do have quite a few in there so let's jump into it. So, the first is the device group list with checkboxes, is that a standard feature? I wish it was. That is something I created. The repository is open source. It's done entirely with CSS and just HTML. So, if you jump into the repository, there's a link in the chat here. And on our forums, you'll be able to see that implementation to see how that was put together, so not a standard feature, but one you can certainly borrow. We used a very generous license for the Kanarra reference implementation app so you're more than welcome to borrow pieces of capability out of that and integrate into your own application if you want. The next is a… This is a good question for Dylan. How many levels of grouping can you do? So, Dylan do you know how many nested levels that we support?
Dylan Schuster: I do. Can everybody hear me?
Brandon: Yeah, I can hear you.
Dylan: Okay, great. So, there really isn't a limit on how far down the tree you can go. What you're going to be limited by is how many Experience groups are included in your sandbox or in your Losant Organization. If you have, for example, 100 groups available to you, you could go one group that has one child, that has one child, and just one child, etc., all the way down the line, all the way down to 100 levels deep if you’d want to. So, short answer, no limit on how deep you can go.
Brandon: All right, awesome. And here's a great question for Erin. So, Erin actually was the primary developer on Losant CLI which does a good job of making it easy to kind of synchronize and move around these resources. So, I think this might be an extension to the CLI but Erin you can speak to this. Will I be able to import the application I just showed into my own Losant account one day? You want to talk about that a little bit?
Erin Thompson: Yeah, sure. So, the Losant CLI makes it really easy for you to be able to download and upload things like Experiences, all your components pages files as well for CSS or different images you would like to reference within your Experience. And so, for this particular application, you could download it and utilize the CLI to then upload it into your application. There are some extra goodies in the repo that Brandon typed up for you guys, such as device setup and device recipes to set up those kinds of things, and those cannot be imported with the CLI. But I think the juicy part of that repo is the Experience itself and that can easily be done with the CLI.
Brandon: Cool, thanks, Erin. It’s definitely our intention as one of our future capabilities to extend either to CLI or somewhere else the ability to bundle up something large like this Kanarra application that includes a lot of different non-Experience resources as well as Experience resources and make that easy, almost like an application template, to import into your own Losant account. So, that's a big initiative for us for the second half of this year and going into the next year. But CLI, as it stands right now, you can use it to take everything in the Experience and files folder and dump those into your application. We've got a good question here about the random look [Phonetic 00:43:00] character. So, I was using, in my example here, the device ID in the URL parameters and also, basically, some randomly generated serial number. So, there are some areas within this application that looked a bit like random numbers and how...can you redefine those, etc. So, the answer to that… I'll take that one. Actually no, Dylan you want to take that one? I think the answer would involve using some tags essentially to implement kind of an external ID system rather than piggybacking on our direct device ID. Can you go into a little more detail?
Dylan: Yeah, tags will be one option of doing it. What I was originally thinking when I saw the question come through was that it could be on you, the Losant user, to set up your application in a way that you would use unique URL-friendly names for your resources. And you could use the workflow engine to look up those devices or groups or wherever else you want to replace an ID using that name. That puts a lot of onus on you to make sure that you're only using URL from the characters and you’re also uniquely naming your resources, as we do not enforce uniqueness on the Losant side for most resources including devices and Experience groups. So, the tags option will definitely work. You could use a short ID in that case, so whatever it is you're comfortable with. I believe there actually is a generate ID node in the workflow engine that can generate short IDs or what we call nano IDs, still not especially pretty but much shorter than the ones that you're seeing in the URL right now. That’d be another option, too.
Brandon: Yeah, perfect. Yeah, we see that implemented a lot especially when it comes to third-party or external device management services where there's an external device identifier and you want to keep using that external identifier. In almost every place where you can reference a device by one of a Losant ID, you can also reference it by a tag. So, all the workflow places where you're looking up a device ID, you would just switch that to look it up by tag. So, most places you can propagate through really any friendly name or external ID that you'd like. A really good question about user roles, and I'll actually take this one because I didn't show it. But if you do check out the repository, you may see some references to it. When we launched Experience groups, we thought of them as a user role, almost a permissions capability. So, I'll make a group and I'll call the group admin, any user assigned to the admin group gets some kind of capability. What we found very quickly and why we kind of moved groups into being a tenancy model was most users just wanted to use them to divide and organize and carve up their devices into tenants or customers or geographic regions. They weren't thinking of them really in terms of roles. However, that opened up a question about… This one is specifically is how should I do user roles? What I implemented in the Kanarra reference example was, I used user tags, and I actually put a role tag on a user, the key is called role, and the value is whatever you would like to implement from your role system. And in this case, there's actually a device provisioning registration flow as part of Kanarra. We don't have time to demo it today. Maybe on a subsequent deeper dive, we'll get into that one. But the register button, it'll show up in the top right only if your user of that role tag exists on your user and it's set to admin. And then, there’s some permission checks to make sure you just directly went to the registration page. There you have access to it. So, my recommendation right now is to use the user tags to assign roles to users that then you can check in the workflows and on Experience views. If it gets very complicated, you can also switch to data tables. I know some of our internal solutions team makes heavy use and very successful use of data tables to hold a user role model that then the user tag can kind of associate a row in this roles data table for more deeper understanding. I will do one last question here and we’ll give you guys some time back and this is a good one for Dylan, simple question. What's the future of Experiences? I know, Dylan, you got a lot of thoughts about this and I know we've been tossing around a lot of ideas. So, you want to go through some of our high-level of these concepts?
Dylan: Yeah. In short, I would say the future of Experiences is much, much easier for the Losant user to build out the Experience. When we first launched this feature, God, over a year and a half ago at this point, we primarily thought our users were going to be using application Experiences to write endpoints and hosting and building their own custom UIs. What we ended up finding out was that most of our users instead wanted to build the actual interface itself inside of the Losant system, also. So, we added in the Experience pages. I'm sure if you're on this Webinar, you're probably familiar with how Experience pages work and know that it is quite a painful experience right now to get something up and running. We want to streamline a lot of that process, the CLI is a great step in that direction. But we also want to make it a lot easier within the Losant web interface also to not only configure your endpoints to decide which pages are going to be returned and skipping out a lot of those middle steps, but also to bring some sort of drag and drop interface and sort of what's called a WYSIWYG editor, what you see is what you get, WYSIWYG editor, into the platform so that you can build out your entire experience with virtually no code at all. Probably expose a lot of common layout components and a lot of common Losant components like, for example, that group check box that Brandon displayed earlier that message group check box. Things like that that are common to be used across a lot of our users making that into a single component that could just be dropped in, and boom, you're done, that kind of thing. So, we're really looking to move in that direction now with the whole experience building process.
Brandon: All right, awesome. So, in the last couple minutes here, I've got just a couple of wrap-up slides. If you joined us today and we didn't cover something you’re really interested in covering or there’s a different topic within Losant that you're very interested in learning more about, please let us know. You can reach us on the forums. You can certainly contact us, however you want to do it, let us know what an idea might be for a Deeper Dive Webinar. And that's it. Thanks everyone for joining us. We'll be sending out a recording. There is, on the Losant website, a Deeper Dive landing page that always has access to all of our previous deeper dives so the recording will be put there. So, if you missed a little bit of this or want to invite others in your organization to see some of this capability if it's meaningful for them, please send them the recording so they can check it out as well. Well, until next time, thanks everybody, and have a good afternoon.