We produce enterprise-software (ie, B2B) that is used by multiple companies. We are using Twilio Conversations in order to allow our users to chat with other users working within the same company. We have no plans of allowing users from different companies to talk to one another, and we definitely want to ensure that users cannot eavesdrop on conversations happening in other companies (in addition to specific conversations within the same company that they don't have access to).
When reviewing the conversations documentation, I came across the following describing services:
- Create multiple, distinct environments (such as dev, stage, and prod) under a single Twilio account
- Scope access to resources through both the REST and client APIs
- Configure different Service instances with specific behaviors
For our use-case, we are considering dynamically create a new Conversation Service for every single company. And create only service-scoped users, conversations, and participants.
This doesn't fall into the category of "distinct environments (such as dev, stage, and prod)", since all services would be used for prod. This also does not fall into the category of "configure different Service instances with specific behaviors", since we want all services to behave the same way.
The main reason we're considering having multiple services, is to better enforce data isolation between different companies. Though we don't really plan to take advantage of any service-specific features, such as allowing users to create or join conversations on their own. On the other hand, having numerous dynamically created services does make it slightly trickier to manage service configurations - any changes will require building a script to update every single service that has been dynamically created.
As a best practice, does Twilio recommend using dynamically created services for multi-tenant enterprise software? Are there any significant problems/drawbacks that we should consider?
When you are an ISV, selling your Twilio powered solutions to other customers, you will want to use Twilio Subaccounts, to partition customers resources from one another. This also applies to Twilio Conversations. Subaccounts are created under your main Twilio Account (Project). All billing is at the Project level.
You can have a separate Twilio Project for dev, stage, and prod.
More details on the benefits of subaccounts can be found at the Twilio blog posts below.
Everything You Need to Know About Using Twilio Subaccounts
Voice Architecture and Best Practices for Independent Software Vendors (ISVs)