Recently I found myself reviewing a behavioral issue in SugarCRM that coincidentally had affected another user a few months prior.
While reviewing the matter, it became evident it fit in nicely with the list of reasons it is generally not a good idea to use a single install of SugarCRM for multiple businesses, commonly referred to as a multi-tenant implementation.
This time around, the issue revolved around email and the manner in which messages link themselves to records in SugarCRM. In general, SugarCRM utilizes the email addresses associated with a record to determine which records should be linked to the message. Thus, the FROM, TO, CC and BCC addresses on a message are all relevant because if the address is associated with a record in SugarCRM -- be it an account, contact, or other -- the email message will automatically associate itself with that record. Said message would, for example, appear on the History subpanel of the contact with the matching TO address, as well as that of the contact with the matching CC address. Herein lies the potential problem.
Within an implementation intended to conform with multi-tenancy standards, the record with the TO address may not be accessible to a user that does have access to the record with the CC address. Perhaps the records represent individuals in different territories or serviced by different business units, etc. Whatever the reason, it is possible that a given user of the system does not have access to both records that correspond with the two email addresses.
Regardless, the email message is linked to both records and History information could be exposed to unintended users. Take note that security issues of this type often times cannot be addressed as they are a direct result of the architecture of SugarCRM.
Thus, once again, one should heed the warning that problems may arise (sometimes not readily apparent), if one chooses to use the system in a multi-tenant manner.
Welcome to cheleguanaco's blog (AKA Angel Magaña), a small corner of the blogosphere dedicated to my insights on SugarCRM which I hope you will find helpful.
Agreed again. Multi-tenant SugarCRM is asking for issues. You need independent databases, and the cost of a second database on the same server is probably nothing. I can't think of a good reason to try this.
ReplyDeleteThis really depends on the situation. We implemented SugarCRM as a multi-tenant solution for a group of companies that often work with the same contacts and accounts. Often times they share leads for an opportunity in a way that many companies profit from each opportunity. Putting them on their own databases didnt make sense at all. Using teams and roles effectively has been a key to the success of this implementation.
ReplyDeleteThat said, if the tenants do not have much, if anything, in common then it makes no sense to keep them on the same database.
Just another perspective :)
I have exactly this dilemmas. We have two companies one is a catering service and the other rent marquee tent, table and chair. So we often shared customers and this for the same contract. Since the beginning of our approach for the implementation of SugarCRM we thought we would go with a single installation. But now I see possible problems for billing and email correspondence. I do not know what to do!
DeleteIs it possible to create a common CRM platform which will be used by different business entity in the same industry...For Eg: Create a platform for Salons wherein the business flow will be the same but contact and leads will be unique to each entity. So this is multi tenant multi business but same industry ...Is this possible by any chance in SugarCRM/SuiteCRM
ReplyDeleteIs multi tenancy possible at DB level? Means DB level physical segregation of data for each client.
ReplyDeleteMeans I have created a product over SugarCRM, now selling at SaaS. So I want to have one SugarCRM installation having one DB per client. Each client will access product from a subdomain URL.
If possible how?