Install one Suite CRM for several companies ?


Is it possible to install one instance of Suite CRM for several profile users or do I need to install one Suite CRM for each user ?

Hi Gilles,

SuiteCRM is a web based application which can be accessed by any user through the web. You can add an unlimited number of users to SuiteCRM via Admin -> User Management and each user can logon and create/modify records and utilise the CRM.



yes I understand what is a web solution. My question is : I want to install suite CRM with 2 users from two differents companies …

I don’t want each one see the customers and datas from other one

Hi Gilles,

You could install 2 SuiteCRM applications, or you could utilise Security Suite to separate users by company.



Hi Gilles,

If you have two companies and no information is to be shared between them, the easiest (and best) thing to do is to install two instances of the CRM. One for each company.

Having multiple companies with different users is possible with Security Suite and I have done it with (so far) 4 companies. However, it is a pain and the reason I did it in this case is because all of the companies share Accounts and Contacts but perform different stages of the workflow being managed.



This is something I’ve wanted in Sugar for seven years. It would have been very simple for the developers to have done when the system was first written but doing it now would be almost impossible. Right now every SQL search uses a user-id as part of the search criteria:

Select * from accounts where user-id = ‘joe’

Had Sugar been developed with a bit more thought it could have been made multi-company by adding a company ID field to every record so the code would be:

Select * from accounts where user-id = ‘joe’ and company-id = “somecompany”

When we wrote our order-entry and reporting system for micro-businesses it is what we did and we have lots of companies (mostly self-publishers) on one large database (that is mirrored and backed up real-time to 3 different data centers on 3 different continents.)

I once looked at integrating the massive SugarCRM with our much, much smaller, maybe even re-writing the 150,000 lines of JAYA PHP using Sugar as a ‘base’ but as soon as I saw how badly (i.e. non-structured) the code was we gave up. Had they used a single class for query formation it could have been done but they have queries created and MySQL accessed from a zillion places in the system.

One simple company-ID field in every table would have done it… but they didn’t have the forethought back then so if there is a way to make Sugar/Suite multi-company without a massive re-write I don’t know what it is. If anyone has an idea, please post it. I’d love to use Suite as a base for our Jaya123 system if it is possible… although to be honest the Suite system has most of what Jaya123 has in it… except the royalty system of course.

Jev77 - hindsight is always a wonderful thing, don’t be too hard on the decisions those who went before us made!

After all, there are pros and cons of having many companies in one system:

  • when one company wants to move their hosting to another place
  • security / data protection laws - is it really secure that just a little bit of SQL determines what a company sees: a small software bug and your clients see each others data!
  • Agile software development says to take one step ata time, not to design today for every possible future usage profile.
  • keeping each companies data in their own seperate database is more scalable: users who create huge databases can have their database moved more easily to another server;

Having said that - you may wish to consider investigtaing this route to get what you want:

If the database in use is MySQL, there is a cool tool (open source) called MySQL Proxy: (maybe similar tools exist for other databases).

It may allow you to do multi-company but without any change to the SuiteCRM code base - or at least minimal change.

MySQL proxy - acts as a proxy between your application, and MySQL: so with initial install, every query your app makes goes through MySQL proxy: but transparently. Everything still works as expected.

But you can then configure MySQL proxy to do active things on

  • inbound queries: eg replace add ‘and company_ID = XYZ’ to the end of every SQL request. before passing to MySQL
    - or even redirect some queries to a MySql server on another box, or to a different database on the same box
  • returned results: eg, change eg the Account_ID field, based on values you get from querying a holy dfferent database

So in your case, maybe this could work:

  • Create for each client, a seperate SuitecRM Mysql back end: so they are all stand-alone databases -that’s easy, it;s the only way to set up multiple companies right now
  • use MySQL proxy: to redirect queries to the correct client’s backend MySQL
  • add some code to SuiteCRM: so that when creating User_IDs: that the field’s first digits are really a new ‘uber-company’ value: that way, knowing the user_ID, you know which uber-company they are at
  • add some code to SuitecRM: to add to every query, the users_ID that requested it:
  • write some code for MySQL proxy: that takes the user_ID extracts the uber-company ID and then directs the SQL to the correct database.

Those steps are all straightforward to do - except:

  • add some code to SuitecRM: to add to every query, the users_ID that requested it:

Which maybe pretty much impossible… I don’t know SuiteCRM code well enough.

Maybe you can think of a neater way… which can let MySQL proxy know the right uber-company each request is for?


PS - MySQL allows comments to be included in the SQL: so you could pass info to MySQL Proxy in those comments:

It would have been very simple for the developers to have done when the system was first written

I’m not sure I agree with this. Adding multitenancy to Sugar/SuiteCRM would have been easier when building it compared to adding it now but suggesting that designing for multitenancy would have been very simple seems incorrect.

Fair enough, adding a company id to the tables that need it and querying that is simple enough (although I can imagine it becoming a pain when choosing which tables are shared or not) but there is a lot more to SuiteCRM than just the data that’s in the tables. If companies want to add their own modules then decisions need to be made regarding how these are called/where they are stored. The editviews would need to be somehow stored in a company specific manner. Let’s not even think about custom fields. I’m not saying these could not be done but rather arguing that designing and implementing such things would definitely not be simple.

The alternative to designing for customisation would be to prevent companies customising which means you lose a large part of the power of SuiteCRM - that you can adjust it to your business and not the other way round.