Implementing a Multi-tenancy Model
Go Deeper with Even More Losant Assets
Building a Multi-Tenant IoT Application - the Architecture
- A step-by-step tutorial for how to architect a multi-tenant IoT application.
- Use Losant’s Experience Groups to represent a tenant hierarchy.
- Experience Groups allow you to create an association between users and devices as well as assigning users to specific access.
- Losant provides you the ability to test your device associations.
Implementing a Multi-Tenancy Model
Craig Baldwin: Hello, everyone. Welcome to today's Losant — Take a Deeper Dive webinar, we're going to be talking about Designing and Implementing your Product's Multitenancy Model. Today's hosts are myself — my name is Craig Baldwin. Hello, to the partners that are out there on the call right now. I’m the Partnerships Director at Losant. We also have Brandon Cannaday who's the Chief Product Officer. Joining us for the Q&A is going to be Dylan Schuster, Director of Product Platform. Before we get into the webinar, I just want to mention a couple of housekeeping items. One, this webinar is being recorded. So, if you need to catch up on something afterwards for those of you who weren't able to catch us live, this recording will be sent to you within a couple of days. We will also have it on YouTube and our Deeper Dive page on the website probably before the end of the week. In case you want to ask some questions, by all means, we encourage that as much as possible. You have two opportunities to do so at your disposal. You can use the Q&A feature within Zoom webinar, you can also use the chat function. We're going to be monitoring both of those throughout the webinar, so please go ahead. Use either. We'll queue all of those questions and at the very end, I’ll come back and we'll work our way through them or Dylan will help us out. Let's talk about the Losant Enterprise IoT platform. For those of you who are already partners, customers or developers, you know these quite well. end-user Experiences, Visual Workflow Engine, Data Visualization, Devices and Data sources and Edge Compute. What you'll find today is the Visual Workflow Engine and End-user Experiences will be a big part of setting up the multitenancy for your application which is very much core to our offering and what we enable for customers and partners. These are some of our customers who take advantage of that feature set to develop applications of their own and take them to market — Verizon, Hewlett, Packard Enterprise, Weg and Proctor & Gamble just to name a few. For partners that are on today, we appreciate you. We're happy to see you. If you're not familiar with the Losant partner program, I encourage you to check that out on our website. You can also reach out to me directly at any point afterwards or one of our team members but we have strategic partners, solution partners and technology partners. If your company thinks that you may be a fit for one of these, we're happy to engage in conversation and see how we can bring you into the ecosystem. With that, I want to toss it over to Brandon Cannaday so he can be your specialist in today's Deep Dive and take you through building your multitenancy model.
Brandon Cannaday: All right, thank you, Craig. Welcome, everybody. I’m going to share my screen real quick and you should see a slide here. Craig, just shout at me if you don't see that. Before I wanted to get too deep into the technicals, I thought it was worth a little bit of time to lay some groundwork. Really get us all on the same page for what we mean by multitenancy and what that means to you. First and foremost, what is multitenancy? I kind of just took Wikipedia’s definition, that's that top bullet point. I think that describes it pretty well. From the highest level, it's really thinking about a single instance of your software serving multiple tenants. What a tenant is can change based on the type of application. Most of the time within Losant — that second bullet point — a tenant is a user or a group of users. That group of users could be a company, one of your customers, and they're all sharing access to their specific devices within a single Losant application. If we look at the diagram on the right, we've got one Losant application. Each square represents a device. We've color coded them to represent tenants within that application. No matter how many users or customers are logging in to your Losant application, they are restricted. They only get access to the devices associated with them — their user, their customer, their tenant. Now that we know what multitenancy is, the next question is — why would you want to use this specific architecture? If we think about something like a OEM or an industrial equipment manufacturer bringing to market an IoT service that goes along with the equipment they sell, most of the time, these IoT services are web-based products. You can think of them like any other web service you might be familiar with, Netflix, Gmail, you're all logging into one instance of that software and you're only seeing information for you. You're the tenant. For a company wanting to offer an IoT service, making that available remotely is a big advantage. You want your customers to be able to log in from anywhere in the world. So, you really want to centralize that product, that service. You want everyone to be able to log in to one Endpoint and access their information. One of the other big advantages here is the ongoing maintenance of this product. The two diagrams on the right, we've got kind of a single tenant model versus a multitenancy model. Single tenancy is absolutely the correct choice in some circumstances. In some solutions, single tenant works. But if you think about an IoT service, especially if you're an industrial equipment maker, you could have hundreds or thousands of customers. If each individual customer has their own instance of this solution, doing ongoing updates and maintenance becomes very operationally challenging. If you've got a new feature, you got a bug fix — in this case, the example here, security updates, if you need to apply that to all of your customers in a single tenancy model, you have to update and push those changes to each individual application. Keeping those in sync, making sure they don't separate from each other can get really difficult. Versus a multitenant application, where you've only got one instance, you've got one code base, one instance of the application to maintain. If you apply an update to that, since all of your customers are accessing that one instance, all of those updates are deployed essentially, instantaneously and simultaneously to all customers. That's one of the biggest advantages to adopting a multitenancy architecture, is it greatly reduces the overhead and difficulty of that ongoing maintenance of your application. I really wanted to cover what tenancy is not. Multitenancy or a tenancy model describes what devices are associated to what users but tenancy is not access control. Tenancy model does not describe the level of access that each user within that tenant has to their devices. I’ll give you an example. Maybe you've got a user that wants to edit the properties of a device. The tenancy model just says — yes, that device is associated with that user. It's part of their tenant. But nowhere does it say does that user have the ability to actually edit the device. Do they have read/write access, do they have read only access, are they an admin? User access and roles can also be done in Losant but that's not the purpose of today's webinar. We're really going to focus on the tenancy model and how to architect various tenancy models in Losant. We'll definitely follow up with some access control educational material at some point. I just wanted to get that across so that you were kind of clear what we're building today. Within multitenancy, there are several different models. What's nice is regardless of the model that you want, Losant's Experiences functionality and specifically the Experience Groups functionality delivers all of them. Really these are kind of the three multitenancy models that are most common. You've got a one-to-many, which is basically a consumer IoT product one user, they've got their set of devices. You've got a many-to-many, that is a very common architecture for B2B applications. You've got a group of users, which is usually going to be like a business, a group of users within that business. And then you've got hierarchical many-to-many this is where things get interesting where you've got a tenancy model to represent complex organizational structures, could be supply chains, could be distribution channels or could be customers with interesting organizations within that one tenant. This is where I’m going to spend my time in today's webinar. We're going to briefly look at each of these and how to architect them within Losant. Starting with the one-to-many. This is really the simplest form of tenancy model to one user associated to one or more of their devices. This is really common in consumer IoT products. Think about maybe you bought a Nest thermostat. You're going to log into the Nest app, you're going to add that device under your account and really, your account's the only one that can access that device. It can work for very basic B2B applications but for the most part, not particularly designed for B2B. Let's take a look at an example of one of these applications. Everything I am showing today started from our industrial equipment monitor application template. That template actually comes with a hierarchical many-to-many tenancy model built in but I’ve modified it slightly so we can look at how it can be applied to these other models. Let me log in real quick as just a user. This is an example of that one-to-many. I’m just going to log in as user one and see what this application looks like. On the left, we've got that user's devices. These devices are restricted to only this one user. No other users in the system will be able to see these three devices. The dashboard on the right is an overview showing some aggregated information still restricted to these three devices. If I click on one of these, we're going to see a details dashboard showing information for just one device. This is a simple application but it does a great job of demonstrating the core two purposes of a tenancy model in Losant. The first is to query the list of devices associated to a user. Which devices as me, this tenant, should I have access to? The second is verifying access to a specific device. If the user says — I want to see details about a specific device, we can go back and use that tenancy model to verify that the ID they parsed in is supposed to be viewable, it's accessible in some way by that user. If we jump into Losant — what I’m going to do is kind of split my screen here. We can see how the Losant side of this comes together to represent what we're looking at on the right. For a one-to-many implementation, what I would recommend is making a group per user. In this case, I’ve got two users in the system and I’ve made a group for each user. All of the hard part of this device association is handled by Losant. It's all down here in the Users and Groups menu. A group, the primary purpose of a group in losing is to create an association between users and devices. In this case, each group only has one user but it can be associated to any number of devices and that gives us that one-to-many. I’m looking at user, this group for this user. You can see I’ve got the one user associated with it. If I click the Properties tab, you can see what I’ve done is associated all devices with this group's ID. I like using a tag here as a device association because that makes it a lot easier to onboard new devices. Every time I onboard a new device, I can just tag it with this ID and it'll automatically be associated with this group. Losant will take care of that. It'll pick up that new device automatically. A little pro tip — if you ever need to get the ID of a resource, they are always available in the URL. We get this question a lot — where can you find the ID of something? In this case over here up here, we've got the ID of our application, we're inside the experience for this application. We're inside the collection of groups. Right there, is the ID of the group. If you ever need to get the ID of a resource and you're looking at it in the portal, always look at that URL bar. Let me jump over really quickly and check take a look at one of these devices. Another pro tip here — you can add custom columns using this little button right here. What I’ve done is I’ve actually added the group tag column. I can see that information right in my device list. I can move it up and down. Maybe I want to be the first column. This shows me I’ve got three devices tagged for one group and two in another group. Basically, I have these two users — one has access to three devices, one has access to two devices. If I go into a device, we can see how that's added to a tag down here. Nothing really special on the tag definition. I just created a new tag, I named it Group. You can name it whatever you want and then the value of that tag is set to the ID of that group. So that's really setting up the tenancy model but now we need to use that model. If we look back at the user interface, there's really two things that we're doing here. One, is querying it for the list of devices and the other is verifying that the device a user requested can be accessed by this user. What I'm going to do now is jump up back over to Losant and we're going to go into the workflow that kind of powers a lot of this activity. This is the workflow that is behind the home or the root endpoint. If I go back over here, you can see I’m just requesting "slash." There's no endpoint, just home. If I refresh. We'll see over here, I do get a debug log entry. Very important, super helpful, anytime you're working in Losant is to always have some log information available. Always have access to the payload or the context that you're working on so you can kind of see the data that this workflow operates with. This workflow triggers whenever that home endpoint is requested. There's my Endpoint. The very first thing we're doing is querying that tenancy model. This is one of the primary purposes of setting up those users and groups and creating those associations. What's really cool here is we added the ability to query devices by an Experience user. I’m basically telling Losant — Hey, Losant, give me every device and here's an Experience user to make that query against. What it's going to do is going to go back to this user's and group's configuration, it's going to iterate through every group that that user is a member of. It's going to inspect every device association and it's going to build up that entire list for you and give it back to you as a result of this node, handling a lot of complexity automatically. Where this thing came from, this experience.user.ID, that's another kind of automated data that Losant provides for you. Every time you make an authenticated request against an Experience Endpoint, Losant will put the details of that user on the payload for you. In this case, I’ve got the ID right here at Experience, User ID. All I got to do is parse the ID of the currently authenticated user and Losant will take care of finding all of those devices for me. Now, I’m not going to get into rendering that list. We've got a couple of great webinars on that. One is our Advanced Templating webinar and one is our Experiences Overview. If you want to find some details about how to render that list, how to take this list of devices put it on the screen, we've got some great material out there for you. The next operation we need to do against this tenancy model is verifying access. If I mouse over the debug output — if you've never done this, this can be really helpful — when you mouse over debug output, you can see in the workflow, it actually highlights the path it took. You can see this request came through. There was a device provided as a query parameter, then we need to verify the ID they provided is accurate. We need to query that tenancy model. The device verify node accepts a Device ID and accepts a User ID. What it's going to do it's going to go right back once more to that group hierarchy you created, it's going to handle all that hard stuff for you. It's going to take that Device ID. It's going to iterate through every group that this user is a member of and it's going to check all those device associations and see — does this ID match any of those associations. If it does, it's going to return "true" and take the right path. And if it doesn't, it'll return "false" and take the left path. Because there's nothing preventing a user from basically typing any ID they want up here, they can type any anything they want. That's fine. That's a great style for making web applications, providing IDs in the URL. But on the workflow side, we do need to authorize access to that device. This is where I can touch briefly on why this is not an access control feature. Basically, the applications I’m showing are all read-only. I’m just saying — yeah, they can look at this device. But let's pretend this was a post or a patch where they might be wanting to change the properties of a device. Well, nothing down here is actually checking that but this is where you'd insert that. You're querying the tenancy model saying — yes, the device they want to operate on is part of their tenant. You've got some opportunity here to add those extra nodes saying — okay, what action do they want to perform? Let me go ahead and check whatever access control rules you have to make sure they can perform that action. This workflow is really powering the list of devices and making sure they have access to this device they want to view this dashboard for. This dashboard is a very basic device dashboard using a device context variable. I’m not going to get into that. The last thing I do want to show for this tenancy model is how to set up a dashboard using an Experience User context variable. I just went back to the overview page and you can see this dashboard has the same list of devices that this user has access to. The map is putting all those devices on the dashboard. These gauges are all aggregating those multiple devices together. Somehow, we have to tell the dashboard what user I should be displaying devices for. Let's quickly jump back over to Losant. Let's go to the devices list. We're going to go to the overview dashboard. Here's that same dashboard. If you're new to Losant, dashboards are created inside the platform and then through Experiences, they can be published through to the end-user through our Experience pages. But if I edit the settings, go to the Context tab. You can see what I’ve created is an Experience User context variable. Context allows us to parse information into a dashboard. If I’ve got 10,000 users, I’m not creating 10,000 dashboards. I want to create one dashboard and I want to be able to parse the user into that dashboard. Since they're all looking at the same dashboard, they've got the same type of devices. You can create that dashboard once. Now, when you're looking at the dashboard in the Losant platform as a Losant developer, you have access. You can just change the user all you want. You can just flip users, update it, see what this looks like through the lens of any of your customers. But that's certainly not what you want to do when you publish this [Inaudible 00:20:32]. You don't want one customer just to be able to change the context of a dashboard. You want to tightly control that. What I’m going to do is show how that context is provided to a Dashboard Experience page. I’m going to go to my Edit, under the Experiences menu. I’m going to look at the dashboard overview page. Here, what I have is the dashboard type page. I’m showing the overview dashboard. And then right down here... Once again, let me refresh this page so we can go back to the overview. I just wanted to refresh that so we can get a log entry. These log entries are critical for seeing what's going on behind your Experience. Right down here is where this context variable is provided to the dashboard. And I’m setting that Experience User context variable. You can name these whatever you want. If you recall from when I went to the dashboard settings, I named it Experience User. And then I’m parsing it the ID of the currently authenticated user. Just like in a workflow where Losant will automatically add details about the experience user to the workflows payload, we will also automatically add it to the available context whenever you render a page. In that render log, on the context on the right side of the screen, I’ve got Experience User and that ID right there. All of the device association between users or groups of users and their devices is all set up once in this Experience and group, our users and groups section. And then in many other places in Losant, we can start using that association to automatically handle a lot of hard work that would have to be done otherwise. With that, we've basically wrapped up the architecture behind a one-to-many type application. If I switch back to the presentation, let's move on to the many-to-many where you have a customer that might be a business and you have a group of users all accessing multiple devices. This is really common. This is your kind of starting point for a B2B application. This is really what Losant is designed to deliver. You'll notice a lot of our functionality is really designed around the concept of you making an application and you're selling it to other businesses. In that case, what I’m going to do is just change my implementation to support a many-to-many. What's interesting is there's really nothing we have to do to support this. We've already laid the groundwork. We've already got our groups. We may not want to name our groups after individual users. What I’ll do is I can just change the name of these, represent a company. In this case, the application I’m selling, maybe it's generators. I’m a generator manufacturer and I’m selling these generators to hospital chains. What I can do is change my groups to representative hospitals. Now there's still only one user in each group. But if I go in Tekton Health, what I can do is just add another user. I can say — well, user three is now also a member of Tekton Health. What I’ve done is just basically immediately transitioned from a one-to-many to a many-to-many architecture. Now I’ve got two users in one group associated to multiple devices. I can demonstrate that if I switch back to this application. If I log out, I’m currently logged in as user one. I see these three devices. Take note of one of them starts with ACZ. If I log out. Log back in as user 3, which is the new user I just added to that group, I have access to the exact same group of devices — remember that device started with ACZ. Now, I’ve got basically any number of users associated, all sharing access to that tenant's group of devices. In this example, the tenant is a company. The tenant is Tekton Health, the devices are associated with that tenant and that tenant has any number of users beneath it. All other implementation remains the same. I don't have to change any other details about this application. When I go query the list of devices to render here, I’m still just making a query using the Experience User ID. Losant's still going to come back. It's going to check the group or groups that that user is a member of. It's going to check all of the devices associated that group and that's what's going to be put in that list. The verify function works the same as well. If I click on an individual device, the Device ID that's parsed in just like before, when I ask Losant — is this device part of my tenant? It's going to check the group that I’m a member of. It's going to come down here, check the association of all devices against that group. If the ID that is parsed in matches any of those, it's going to return "true." There's really nothing we have to show beyond this for the many-to-many. A lot of the work was put in place for the one-to-many with just a very slight tweak for the many-to-many use-case. Let's jump to kind of the complex one, the interesting one — hierarchical many-to-many. This is where you get a group of devices or a group of users, kind of same thing in terms of a tenancy model. You have a tenant at the top and that tenant will have any number of users. But what's unique is that association becomes adopted. You're able to build this hierarchy of device association. In this case, the devices down here are directly associated with this group. But since these two groups have a Parent Group up here, that device association is automatically adopted. If I’m a member of this top group, I am automatically associated with all of these devices because I am a parent of those two children. That kind of automatic association being adopted up a hierarchy like that offers some very interesting and powerful models that you can put in place. We see them a lot in what I will show is this third bullet point, large and distributed customers. I’ll expand this hospital use-case and show what happens when a chain of hospitals is geographically distributed. Can also be very helpful for supply chain. You may have organizations higher in the supply chain that need visibility into those devices beneath them. And then also, maybe you've got complex sales, distribution or support channels where your resellers, your distributors, they may need visibility into their clients, their customers' devices. There could be distributors between distributors and you can kind of build these really complex nested organizations. Let's switch to a different version of this application. I’ll quickly click on this About screen. We can see a visual of how this tenancy model is put in place. At the top is kind of our technology, the solution builder — in this case, the manufacturer of all of these generators. We sell these generators to hospitals. Think about those big generators that sit behind hospitals. These hospitals have regions and each region is then a single site or multiple sites per region. At each site is where the devices actually live, one or more generators per actual location. If you're a facilities manager at the very bottom at a specific site, you really only need access to your equipment, the generators at your site. If you're a regional facilities manager, you probably want to have visibility into all generators across all sites in your region. And then you could be a global facilities manager where you need to get visibility into every device across every region and every site. And then finally, as the OEM, as a solution provider, you have to support this system. You may have support technicians. They will need visibility into all of that equipment, all those devices. If a customer contacts you and says — hey, there's a problem either with the software solution itself or there's a problem with the generator, I need support. Getting access to any customer's historical information for your support technicians can be a super powerful feature. Let's go back and let's log in as somebody at the very top of this organizational structure. This application also does a great job of showing how to extend our application templates. The other applications I just showed were the industrial equipment monitor template and the only thing I changed was the group structure. In this case, we started from that but then we added a lot of capability that I wanted in my specific solution. I wanted these little cards to show each device but starting from a template can lay a lot of that groundwork for you and then you can just focus on some of the user interface aspects that might be important for you. In this case, we've got this tree on the left. This is a UI component that allows somebody to navigate between groups and subgroups that they might be parents of. But it also allows us to quickly demonstrate what happens if somebody logs in at a group somewhere further down in the tree. Let's say I am a facilities manager at San Bruno. If I were to log into this app, all I see are these four devices. However, if I go up a chain and I log into California Northern, I’m a regional facilities manager. Now, I have access to quite a bit more devices because I’ve got many facilities in a single region. All right, let's jump back into Losant and see how something like this comes together. Really, it boils down to the group structure. All of the work that we just put in place, the querying devices and verifying access to devices remains unchanged. All we're really doing is changing how we organize our groups. In this case if we look at a group at the very bottom, you can see I’ve got an example — user — part of that group. This would represent a facilities manager at a single site. If I go to the properties on that group, you can see the device association. In this case, I use the name of the group instead of the ID. This can be helpful for debugging. As you're in Workflows or Experience pages and you're looking at the details of a device, seeing the name of the group is a little easier to work with than the ID but it does introduce a little bit of brittleness because what happens if the name of that site changes? Customer could come back to you and say, "Well, we've renamed that hospital something else." It's not the end of the world. You can go and update all these tags. But using the ID will never change so that can be a little bit more of a bulletproof implementation. If we go back to a single device, we can see again, how that tag is made. Essentially identical to before. We've got the group tag with the name of the group it's in. But what's interesting is in this hierarchy, devices are only associated at the leaves, at the very bottom. In San Bruno, you can see we have a device association. If I go up to California Northern and check out its properties, you'll see there are no devices directly associated with this group. It's because this group is using that adoption mechanism. If I’m a member of California Northern, I will automatically be associated with all of the individual associations for these groups. That's what introduces a lot of that power. If we click on one of these devices, we're going to see a very similar implementation that we saw before. List of devices on the left and the dashboard for that device on the right. Just like before, just to prove that the implementation is essentially the same between the two, let's check out the workflow for this endpoint. In this case, the endpoint is /devicedetails and then the Device ID is passed through a query parameter. If we go check out that endpoint. The workflow is essentially the same, organized a little bit differently but here's that device verify node checking the value of the ID parsed in through the query parameter, comparing it against the currently authenticated user. Now, that we have a nested structure, this is where Losant takes care of a lot of that complexity. It's going to start from whatever group you're in and it's going to start traversing that tree. You can nest that structure as deep as you want and Losant will keep on traversing, looking at every association for every group beneath you and see if any of them match what you're trying to verify here. And then we also have that Git device node to populate that list on the left and there is an exact same thing — Querying by experience user ID and parsing in the Experience User. No matter what tenancy model you're adopting, either the one-to-many, many-to-many or the hierarchical many-to-many, the implementation, the workflow, the Experiences, they're essentially done all the same. All of the power is handled for you right here in the Experience Groups. This is where you want to focus whenever you're thinking about designing a tenancy model, you want to do some research in our group structure and see how you might map it to this implementation. Let's head back to this. That point, really, I’ve covered what I wanted to cover in this Deeper Dive. I wanted to show in Losant, how to architect these three types of tenancy model because these are the three most common that we see amongst our customers. Like I said, Losant is designed to build these B2B IoT products and services. We see a lot of the many-to-many and the hierarchical many-to-many. As long as you're aware that those groups exist and how to associate, assign users to those groups and associate devices to those groups, you have a lot of power at your disposal to implement and architect these tenancy models. Finally, what's next is we're going to have to start provisioning some devices. What I showed was a lot of creating this stuff directly through the portal. That works in the early development time, early development phases, your proof of concept, but when you get into production, you're going to want to start automating those steps. Automating, provisioning and onboarding the devices is really domain specific. Everyone wants to do it a little bit differently. It really depends on the type of application you're building. That functionality is usually implemented inside your Experience as well. Your Experience isn't only limited to customers logging in and viewing information about their devices. A lot of that operational automation is also implemented in Experiences. You might have an admin or technician that has access to an entirely different user interface that allows them to provision this stuff. Next week, we're going to get into some details. I would really recommend joining this webinar. Dylan’s going to do one type of on-demand provision or automated provisioning essentially using QR code. You can think about... You see a lot in consumer products but we do see it a lot in industrial as well where there's a code printed on the device and through a mobile interface, a technician or the end customer can scan that code and that's what creates the association between that device and that user, provisions that device to that user. I didn't get into the nitty gritty of implementation in this one. That wasn't the point. I wanted to focus on architecture but we have some great Deeper Dives that I would definitely recommend if you want to really dig into the implementation side of everything I showed here today. The first is building application Experiences. This is a great one hosted by Dylan. Covers really, end to end of what it takes from starting from raw data all the way to building that end-user experience kind of like the one I have shown. One we did fairly recently is Advanced Templating. Templating is everywhere in Losant. Anything anytime you see those double curly braces, that's templating. It's a required part of building an Experience. We had a webinar hosted by Heath that really dives into how to do that and show some really advanced use-cases. And then Nested Experience Groups — this is one we did a while ago when we launched the that hierarchical model in our groups. This one can provide a little bit more information about experience groups in general. If you do want to see the implementation behind that, actually, this application right here, we do have that open source that's in GitHub right here. This is an application template that you can import into your Losant organization and inspect all the details about that implementation. Now, this is a little bit large for a sandbox. So, if you have a Losant organization, you can import it. If you don't have a Losant organization and you're thinking about trying Losant, feel free to go to losant.com, contact one of our representatives and we'd be happy to set you up with a trial organization that provides enough resources to hold this example application. Just has quite a few devices that are all being simulated — a little bit too big for a Sandbox account. With that, I’m going to hand it back to Craig to finish up. Craig.
Craig Baldwin: Thanks, Brandon. One second. I’m going to go ahead and share my screen. The first thing I want to touch on is as Brandon said, we do have some upcoming webinars. The Provisioning Methodology Utilizing QR codes is on March 9th. And then on March 23rd, we have an upcoming partner, Making Predictive Maintenance Reality with Losant and Elipsa AI. We definitely encourage you to mark those on your schedule. You can sign up if you haven't already at losant.com/deeperdive. But be a part of those. The Provisioning one especially, is one that we get very, very, very often. So, this will be great content for those of you who are actually building one of these applications. Jump back just quickly. The other thing is for those of you who have joined us before, we have lots of other great resources and materials. Janet, our Marketing Director actually posted in the chat a bunch of applicable resources. Brandon mentioned a few — documentation, university. The Deeper Dive series is fairly robust at this point and covers a lot of these large topics in detail. And then we have some hands-on tutorials and forums which will always be your best resource for sort of the how-do-I questions. Some of them may have been asked and answered previously, some might be for the first time and then our support and engineering team can jump in and help you out. We do have a few questions that we received as a part of the webinar today. The first one is actually from me to be honest with you and this is a question that we get a lot. Because it's one thing for me to see tactically, how Brandon might have gone about this process but to really understand from a scalability perspective, if I have hundreds or thousands or tens of thousands of users as an example, as a part of that of course, I probably have many different organizations represented by those users. Is there really anything special that I need to do as a developer or as a customer working my way through this to accommodate for that type of scale or is it really just the same methodology and scale will all be handled on the back end? Brandon, do you mind getting into that a little bit?
Brandon Cannaday: Yeah, absolutely. I guess there are two versions of scalability. There's certainly technical scalability and then operational scalability. In terms of technical scalability, that's what our platform will handle. I showed two customers, not very challenging from a scalability perspective but those Experience Groups really have no technical limit. If you onboard 1,000, 10,000 customers, you can just keep adding experience groups. Now, you'll hit a sanity limit. Customers on the call probably hit many of those. We do have just kind of safety limits that prevent somebody from accidentally creating millions of resources when they didn't mean to but that's just... Many of those is just a quick contact to support saying, "Hey, I just hit my limit on Experience Groups. Can you can you increase that for me?" In terms of technical scalability, there's really nothing you have to worry about. That's what our platform is there to solve. In terms of operational scalability, how do you manage tens of thousands of customers. That's really where that tailored experience, that management experience is going to come in and that's what we see our customers adopt. It's tough for us. We can't predict, we can't provide in most cases, a management interface that works for everyone. As part of the end-user experience that you're creating to deliver that customer facing application, there is usually another experience that you're creating that is usually internally facing. So, your technicians, your sales team, who's ever onboarding new clients, they're probably interacting with an internally facing version of this Experience and they have different set of fields. "Hey, I need to onboard a customer." Well, I’ll go to myexperience.com/admin/onboard. It's a form and it has fields specifically for that customer. What that's going to do in the backend, is it's going to create and create that Experience group automatically make that device association automatically. Technical scalability, no concerns there. Operational scalability, start thinking about — what do you want your internal team support people, what's the most appropriate interface for them to manage your customer base? And then that's kind of a second Experience that you'll be creating.
Craig Baldwin: Awesome. Thank you, Brandon. That was a really comprehensive answer. This question that came in is a little more tactical but another one that we get quite a bit to be honest. It relates to — obviously, you build out what might be a multitenant application. You showed us an example with the Kanarra example. I saw, I believe in that particular application, the URL that still says Losant. If I actually want to make that my own URL, so really kind of the last step of white labeling, so to speak, my application, using the Losant tools, can I do that and if so, how would I go about that? Dylan, do you mind jumping in on that one?
Dylan Schuster: Yeah, I can handle that. Yeah, you're correct. What Brandon was demonstrating showed the standard staging domain that we assigned to all applications, which is just the application ID losant.com. You have a couple options there. Actually, if you want to give me control of the screen, I can actually walk through it really quickly. Give me a second here. Let's share. There we go. Okay, you should be seeing my screen here. This is actually a preview of what you'll be seeing next week in the webinar I’m hosting on Device Provisioning. But to answer the question about domains, you'll see down in the menu down here, Domains and Slugs, you'll find inside of any application. The only restriction we have is that if you are creating inside of a sandbox, we will not allow for a custom domain, a fully custom domain. You can still create a branded slug. By slug, what I mean is down here, if I were to add — we'll call it dylansgreatwebsite on losant.com. I would then be able to access my Experience from that application, from that slug right there. That's like the first level of branding. I think what you were asking about specifically was actually adding a domain. In that case, what you can do is basically type in any domain that you want right here, that you own of course. Let's say dylansgreatexperience.com. Optionally, you can add a SSL key insert. You're almost certainly going to want to do this. You can get those from your registrar when you've actually purchased the SSL and drop those the key in the cert inside of here, which is going to make for a secure connection over HTTPS as opposed to HTTP. It's not quite as simple as simply typing in. You are going to have to go to your registrar and actually enter the — what's called a CNAME or possibly an A record depending on if you want to use www or just the root to configure and point the domain over to our servers. We've got some great guides in our documentation on how to do that. Actually, Brandon wrote something very... It's kind of tangential of that. A guide that we just published in our documentation about putting Cloudflare in front of one of these domains. This actually came from a user request in our forums — about white labeling certain IPs to only allow certain IP addresses or black listing IPs against these domains, also putting some throttling and rate limits in front of the domain before it ever actually hits the application experience. All that said, there's some outstanding guides in the documentation. I actually used it myself, the actual guide in the documentation personally to set up a domain on something I was working on. So, I know they work. They're very, very useful. I would go check out their docs.losant.com and you'll find them in the navigation, a place where we will guide you through all of the steps to set up a domain not just inside of your Losant application but also with your registrar as well.
Craig Baldwin: Awesome. Thank you, Dylan. Let me go ahead and share my screen again for everybody. Another question that we had was actually relating to notifications alerts. It's very common that we want to provide a particular view or access, I should say, to a particular organization or user. I imagine that same type of thing applies to notifications and alerts, events maybe even. Can you talk a little bit about how multitenancy relates to that alerting and notification piece of what Losant has or offers today? Brandon, maybe you can tackle that.
Brandon Cannaday: Yeah, absolutely. Yeah, notification and alerting, probably one of the most important aspects of every IoT product or service that gets created. The options are pretty far and wide. I would say the very first thing to look at would be user tags. In Losant, we have a few kind of first-class properties on a user, email, first name, last name and that's basically it. Then the tags, just like device tags, allow you to add any additional information on that user including phone number or SMS. That is, I guess, the communication channel to reach that user. That's step one, is using user tags to provide some contact details about that user. Then when you have an alert and you need to contact a specific user, what you'll do is that device will come through. That device is tagged with the ID. So, the reason of using group ID tag is a good one, it's tagged with the group right in the Workflow, then you can get details about that group, including all the users. The simplest way is looping over every user and sending the details about that alert. You might want to create an event in Losant. Losant has a concept of events just 100% designed to track exceptional occurrences like that but that's just tracking, not so much alerting. You can loop over every user in that group and send them an alert but you can also use tags to control alerting. You may not want every user all the time to receive events. You can add additional tags that allow your business logic to constrain or focus who gets alerts when. Maybe a tag could be a time range. Losant has a time range node. You can pull a tag off, put it in time range node and go through every user and if they're outside that time range, you don't send an alert. If they're inside, you do send an alert. All the functionality is there. A lot like most other things in Losant, it is quite flexible. Especially an alerting mechanism, changes a lot between applications. The model is there, the fields are there to store and track all this and allow you to design alerting scheme that fits your business case perfectly.
Craig Baldwin: Thanks, Brandon. Another question we just received relates to data and this is one that again we see often for our own customers. But if I think about someone building in their organization, they have an application for their customer set how easy is it to essentially section off that data. Let's say a customer of theirs leaves but they want access to the data that they paid for. How easy or difficult is it to provide that data to the final customer as a part of that application given this multitenant model that is set up for people to use as part of using Losant. Brandon, you want to take another crack at?
Brandon Cannaday: Yeah, sure. That is really straightforward especially if it's in kind of a rare occurrence like this where maybe, yeah, one of your customers is leaving and, "Hey, please give me an export of all my data." It goes back to this architecture that I recommended here, is using those device tags to associate a group with devices. Because alternatively, you could associate devices individually based on ID. Sometimes, that's the right approach but using that tag gives you a lot of capability elsewhere in Losant. If you go to the devices list, we added some excellent bulk device capability. You can actually request a data export for a group of devices. You can restrict that group to that tag. If that's a tenant, you've got the group ID that represents that tenant on the devices. You can just say — hey, Losant, request a data export of every device that matches that tag. We'll work for a while because it could be a substantial amount of data. That'll kick off a job and then you'll get an email saying — here you go. Here's a download link to that zip and then that's what you can provide that user.
Craig Baldwin: Awesome. Thanks, Brandon. We did get a question that's probably for me. It says — Losant looks awesome. Do you have any partners that can help build my solution for me? The answer is definitely yes. There are more than a couple options for you but the easiest one is to go to losant.com, select the partner tab and there, you can see a list of partners. Our solution partners are likely who you would want to look at but you can also reach out to us directly and we can go ahead and channel you or funnel you to the right partner depending on your needs, what you're trying to build, for what industry and of course that big thing that everybody talks about — budget. We have a lot of different options available that, if you cannot build this internally and need some external help, whether it's the Losant solutions team or our partner ecosystem, we have many experts who are trained on Losant and have built many applications in the past. I think we have one more question. Give me a second to get to it. Here's an interesting one that I honestly haven't thought about which is — if for whatever reason, a user of an application is not available. I think the example that's been presented is about an operations manager and they were supposed to receive a notification but for whatever reason, they're on vacation — and a new user needs to be added to that application and quickly and probably by the admin or the developer or the maker of that application. Is it easy to just go ahead and add another user that can then route that information or rather have access to the information and make a decision on it out in the field especially for some of the operational end users that usually interface with these applications? Dylan, maybe you could tackle that one.
Dylan Schuster: Sure. Is it easy? Generally speaking, yes. I guess the answer to your question depends on if this is being added in the Losant application side, which is as easy as what you saw Brandon do before just creating a new user and assigning them to a group. More likely, I’m guessing that this use case is speaking about from the Experience side, from the customer side, is it possible to create a user and to associate them with the group? It certainly is. You would have to expose that in your application experience and when you look into an Experience workflow, you'll see a whole category of nodes related to Experiences. I believe one of them, there's a user create node where you can create a user in a workflow engine and optionally also, assign them to a group. We do have a library template that demonstrates how to build a form into an application experience and take input from a user and take some action on behalf of that input. I guess what you would do in that case is you would create a page inside of your application experience that allows for registering of new users. You'd have to supply an email address, the first name, last name. You could set a temporary password for them. And, using the workflow engine, you could behind the scenes create that user and also assign them to the group and then that user could go through your also built in the Experience login flow and log in and take charge at that point.
Craig Baldwin: Awesome. Thank you, Dylan. That is actually all of our questions. We're going to go ahead and wrap up here. As I mentioned earlier, please don't forget to join us on March 9th for Provisioning via QR codes and then Predictive Maintenance with Elipsa AI on the 23rd. As always, if you have any questions, please reach out to the team directly. You can utilize the website. You can always also use my email firstname.lastname@example.org and we're happy to route you to the right resource or go ahead and answer that question directly. With that, we say goodbye. Thanks, everyone. Hope you have a great day.