Managing experience users for different clients

[paul_wareham]

Hi Folks -

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.

Any thoughts would be much appreciated.

Thanks!

[Brandon_Cannaday]

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.

1. We recommended a single application to own all devices for all clients. This application also hosts your end-user experience.

2. Each Experience User is added to a Experience Group for the client they belong to.

3. 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.

4. 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.

5. 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.

[paul_wareham]

@Brandon_Cannaday

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).

[RWB]

@paul_wareham

Great guidance. Yes having documentation and example would be a big help for multi tenant.

I also would love to see this, it’s my application setup also.

[Brandon_Cannaday]

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.

[paul_wareham]

Hey @Brandon_Cannaday

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.

Thanks!

[Brandon_Cannaday]

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.

[paul_wareham]

@Brandon_Cannaday

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?

Thanks much

[Brandon_Cannaday]

I’ve elaborated on this architecture with step-by-step instructions here:

Display a list of devices based on experience user group

I’m attempting to use an experience dashboard page to generate a list of devices matching a device tag value. The value is obtained from an experience user group. Each experience user belongs to a customer group, and each device has a Customer tag to match with the user’s Group. This defines a list of devices that are authorized to be viewed by that user. I have tried to use the Device List, State Table, and GPS blocks but I am running into the same issue. I don’t think I can template in th…

[Jose_Cruz]

@Brandon_Cannaday

We recommended a single application to own all devices for all clients. This application also hosts your end-user experience.

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,

[Brandon_Cannaday]

Hey @Jose_Cruz,

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.

[Jose_Cruz]

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?

[Brandon_Cannaday]

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.

[Jose_Cruz]

Awesome. Great feedback, greatly appreciated !

[Jose_Cruz]

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?

[Brandon_Cannaday]

The context that your page template has available contains the Experience User and the Experience Groups they are members of.

So if you want to show menu options to only GROUP113, you can surround the menu item with:

{{#eq experience.user.experienceGroups.[0].name 'GROUP113'}}
  <li>Menu Item for Group 113</li>
{{/eq}}

You can see the available context in your render log whenever the page is loaded:

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.

[Brandon_Cannaday]

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}}

[Jose_Cruz]

@Brandon_Cannaday UPDATE: all above worked like , Thank you !