I am wondering about best practices for managing the following use case. Our organization has multiple end users from different companies, all of which are our customers. We would like to provide an experience login for each user and limit each user to see only those devices that pertain to them. They all have the same workflow configuration and same layout of pages, but there may be some small variations in for each user as to which elements of the Dashboard Pages they see (probably handled through context variables).
Does this require creating different Organizations, or can they be managed under one master Organization with individual users from different companies (all of whom are customers of the master Organization)? I am thinking both about segregating the data, and also maintainably of the workflows without creating a lot of duplication.
This is a great question, and is a reference architecture we should definitely document. Hereās a high-level overview of our recommended best practice for deploying a multi-tenant app from within a single Application Experience.
We recommended a single application to own all devices for all clients. This application also hosts your end-user experience.
Each Experience User is added to a Experience Group for the client they belong to.
That same group name is added as a Device Tag to each device owned by that client. For example, the tag key could be āclientā and the value is the groupās name.
Whenever a Experience Page is requested, the workflow backing it automatically gets the user information, which includes the Groups they belong to. You can then query all devices with the āclientā tag equal to the group that the user belongs to.
You can now display a list of all devices the user has access to and also verify the user has access to see data from a device by comparing the userās group name to a specific deviceās āclientā tag.
Great guidance. Yes having documentation and example would be a big help for multi tenant.
Do you also have any recommendations on managing client-to-client variation in Dashboards and Pages (or possibly workflow variations for alerts) to reflect client preferences? Iām thinking of some OOP principles to have a base dssifn and over-rides for certain things (like logos and which gauges are exposed).
Generally custom Data Tables are a great place to store any configuration differences between clients. Then when a workflow runs, you can query the required row of configuration data based on the deviceās āclientā tag or the user group. The workflow can then perform different operations based on that configuration.
In terms of dashboards, you can use Context Variables to pass a wide variety of information into dashboard blocks. Itās most commonly used to pass a Device ID into a dashboard so you donāt have to build a dashboard for each individual device. However, you can also use it to pass it labels or different thresholds for the indicator block, etc. The context variable values can be stored in the Data Table and then passed into a Dashboard Experience Page based on the currently logged in user.
I was wondering if you had any suggestions on extending that reference architecture to include Experience Users who might belond tomore than one Client? I.e. a client might have multiple locations and some client users might need to certain all assets and other client users might want to see only those that relate to their location.
I might recommend switching to User Tags instead of User Groups for this. This way you can add a āclientā tag and a ālocationā tag. Tags, like Groups, will be automatically available in the workflow payload.
Then in the Get Device node, you can do a Tag Query for all devices that have a āclientā and a ālocationā tag that matches the authenticated userās tags.
Iāve tried everything I can think of to use standard dashboard pages to automatically display a list of all devices an experience user has access to. I donāt think this is possible with any of the existing blocks. Can you correct me if Iām wrong?
I think I would need a Custom Experience Page, would you agree?
I know this is a 2 yr old topic, but Iām running into this type of āstructuringā now as we speakā¦so, am I understanding correctly youād recommend just a single application like below
for āall clientsā? I may be confused here, but for example Iām envisioning a different application based on āprojectsā (so Project X from client X will have its own App, Wkfls, Exp pages, etc, Project Y from client Y will have a different App, Wkfls, Exp pages, even maybe a different MQTT integration). Is this a correct strategy? Can you comment/clarify a bit on what do you mean on point #1 vs my current āstrategyā explained above? Thx,
I believe your approach is correct: different applications per āprojectā. It sounds like your projects are quite a bit different between each client.
The recommendation for a single application is when youāre delivering an identical solution to multiple customers. An example would be a generator manufacturer building an application in which all of their customers could log in and view details about the generators theyāve purchased. This would work best as a single Losant application using Experience Groups and Users to separate those customers into tenants.
The alternative is to clone the application for each end-customer. This approach will become a maintenance headache as the number of customers grow - youāll have to apply bug fixes and new features to many, essentially identical, applications.
Ah! That makes perfect sense. So, for example, for our āindustrialā and medium-to-large projects, keep applications separate as these will have >10 devices and very ācustomizableā features. But, say, our small-to-household individualsā packages of <10 devices for home, keep these small āpackagesā in the same application and, as you say, separate them using the XPG and UX since the āpackagesā will be the same for all, correct?
That sounds accurate. If you have a high amount of customization between customers, then Iād recommend using different applications. If every customer gets basically the same thing, then Iād recommend a single application.
Ok, next question: what would be the best route (if I have multiple āsmallerā project users on the same APP, XPG, etc) to ādiscriminateā what each can see (based on their GROUP, GROUP ID) on the ālayoutsā and/or ācomponent-drop-down menuā (see below). As it stands and having only one root / login, password, profile change and logout pages within the APP, XPG, they ALL will see whatever I included in the ācomponent-drop-down-menuā, of course if they click on an option NOT AUTHORIZED to be seen by their GROUP, GROUP ID privileges, then they will STAY on the HOME page/nothing will happen. But they ALL can still see ALL pages/links:
Trying to see what would be the simplest, best way course of action in this case. I donāt just simply want GROUP101 member (in this example) to NOT BE AUTHORIZED to ārenderā the component-linked page of GROUP113, but also not to be able to āseeā it in the component listā¦ hopefully this is not too confusing Any thoughts, suggestions?
The Huddle Room Monitor Template has a similar implementation you can view as an example. Thereās a menu item that is not rendered based on the value of a user tag.
To make this a little more scalable, you could add tags to the Experience Group that indicates which menu items should be available. This is helpful if you have several groups that all get the same menu items.
Experience Group tags, however, are not automatically available in the context. This means youāll have to grab the entire group object using the Group: Get Node in the workflow.
Then the template could look something like this:
{{#if pageData.group.groupTags.showMenuFoo}}
<li>Menu for groups with showMenuFoo = true tag.</li>
{{/if}}
Any thoughts, suggestions? 
, Thank you !