Best Approach for Multi-Tenant

I have an app that we have a lot of tenants; what is the best practices for ensuring that tenants only see their chats?

For example, our customers may communicate with multiple users, which is used like health providers.

  • Doctor’s office A can only chat to their patients. Doctors office A has multiple users who can chat with patients.

Im in healthcare too and working on some of the same things you are/will be working on. There is a lot of different approaches I imagine. From what I see so far I think you will need to setup a roles and permissions that can be applied to the different users and groups that are created. Im guessing using some of the standards that already exists for roles and permissions and create an administrative tool as well to be able to monitor and change. If I find anything else or come up with a good implementation I can reach out at a further time. Are you US based or another country?

1 Like

Yes I am US based.

I think the biggest thing I am trying to figure out are the types of messages that aren’t “assigned” to a user at the office yet. So a patient initializes a chat with a doctor’s office. I just want to make sure when I pull a list of all chats in that office, only the users for that office see it.

I think the patient must be part of the “group” channel and you wouldn’t have any issue there, then there would need to be somebody from the office to initialize the 1 on 1 interaction. Okay so there is 1 on 1 and 1 to N types of interactions. Ive been looking at the docs and found this maybe it is helpful.

Group channel

  • Private 1-on-1 conversations, such as clinical consultations and Instagram-style Direct Messages.
  • Public 1-to-N conversations, such as small group discussions among students.
  • Invitation-only chats with a handful group of users.

I am also wondering if it makes sense to have a unique app per tenant.

This can be avoided. I believe.
Trust me I am just getting into it myself but when I interact with others I tend to discover more than if I am just looking around and reading. FYI

So how do you securely pull only “open channels” for a specific “tenant”. I guess you can query that via the metadata?

For example if I put tenant id on the metadata

Honestly I think Understanding the way the UIKit Works is a stepping stone and keeping things simple and manageable until we have enough understanding of everything to move towards more customizable implementations. Work within the framework until things make sense. Then its up to our own creativity.
Open channels i dont believe work that way.

Open channel

  • Short-lived live events, such as concerts and streaming.
  • News-feed type messaging to massive audience, such as Twitter-style feed.
  • Events that don’t require a permanent membership.

Gotcha, so in cases like this it would really be the need for a completely custom UI and the UI kit is just for getting started with basic examples.

Would you use the React SDK to build your own UI or is it only for the UI kit specifically.

The React SDK/UIKit is only for web based so I wouldnt want to use for anything too complex at this point. Im staying away from ReactNative as well for this project and want to focus on the Android and iOS.
The UIKit comes with default UI Components, which some of are overridable if not all of them, I haven’t made it that far.

Hi @Jonathan_Marbutt , Welcome to Sendbird Community!

You may utilize our Desk feature in order to achieve your use case.
I believe that you would try to build the customer-support related functionalities to a client app.

Please refer to the following. You can get more details about our Desk feature.

2 Likes

Thanks I will take a look, I have contacted my contact about pricing for desk, hopefully it won’t price us out. Is it possible I can have it turned on for my account?

Desk is currently offered only in Free-trial and Enterprise plan. Other than that, you need to talk to our sales team.
If possible, could you DM me your application ID or submit the support ticket via [link] ?(Sendbird - Contact Sales)

Did you ever build something with sendbird for this? I am revisiting this again. Trying to decide a few things:

  • Unique App per Clinic/Tenant
  • When a patient starts a chat with a clinic, does this have to be to a specific user? or should there be a user like “ACME Clinic”
  • How to manage it so employees of the clinic can answer any chat? Is this what the desk feature does?

And lots of things I don’t know even what to ask.

@Miyoung_Han do you have any input?

Hello @Jonathan_Marbutt,

  • I would highly recommend using the approach of a unique application per tenant. This removes any of the client side work that has to be done to ensure that the tenant only sees the information related to them.
  • You must use unique users. Sharing a single sendbird user amongst users is not something Sendbird supports and is against our usage agreement.
  • Desk could be useful in this instance. There are also alternative options depending on the UI/interface you opt to build for them to access chats in general.

Thanks @Tyler we are essentially building a chat system for clinics to talk to their clients. Desk looks interesting but can it be embedded in our application for the agent side?

So the thing I haven’t figured out is what to do in this case:

  • Patient logs into their portal
  • They start a chat with the clinic

Do we create a group chat? 1:1 with someone in the clinic? What if no one is available to start the chat at the clinic?

Can we put a subject on a channel?

This is where I get lost.

At the moment, desk cannot be embedded agent side. We are working to release an agent SDK that would allow you to do so.

In terms of how you manage your chat, thats honestly up to you. You could create your own type of check function that sees who’s online/logged in and determine who you route a chat to based off that.

In terms of the subject, there are a number of ways you could achieve this but I’d recommend something like the data object on the channel and then render that the way you desire on the client side.