Brainstorming: SuiteCRM-based SuiteCRM Portal?


currently many people provide a portal into SuiteCRM, either based on Joomla (AOP Advanced Open Portal), or on Wordpress, or custom-made.

However, I’ve always wondered why we need to reinvent the wheel, why not just let the customers log in to SuiteCRM itself, and show them a stripped-down version of the CRM?

  • using SecuritySuite settings, lock down the CRM to show only a handful of modules and features: for example Cases and Documents.

  • maybe have a special mode for the menus, so they show differently

  • maybe have some easy way of turning a big group of Contacts into users, so they could be sent a password and log in

  • what else would we need?

  • security concerns?

I’m in brainstorming mode here, so please join the discussion and say whatever comes to your mind. Thanks

I am very interested in this!
Especially :

Also interested on this. A SuiteCRM only solution would be better.
I think some years ago CMS was the main are for companies and then all the other software must connect to that.
This provided the feel of an integrated tool (sometimes simple embed) and single sign on.

Now users simply prefer to have a place that point them to where they can have the things they need.
Single side on is also a tendency just for IT’s (also easy to sell to company managers) but in the end they are not useful for the end user:
If the single sign on looks easy life using passwords in the real life issues ruins all of these integrations.
For the IT is a plain drama: different systems require different updates for each system and an update to each integration tool. And do remember different servers and IPs and sub-domains.
In the end users get a poor service after the first year the system is implemented.

Its not that fancy… but its more usable: a portal with links to each site/tool a company uses without integrations.
If you want to trick the user just work on the visual side of each solution!

Note: KnowledgeBase was merged into AOPortal for the version 3.0 (beta)

One of the areas where I think Portals can be useful is to let users edit their own contact information, to update emails or other addresses.

Another use would be to let them fine-tune their subscriptions. For example, tick a few checkboxes of the kinds of content they might be interested in, and this would include/exclude them from Target Lists.

These are things where base SuiteCRM functionality doesn’t seem to be enough. SecuritySuite settings don’t let you select parts of a Contact’s record that are editable, and parts that aren’t. So if a customer was to be allowed to edit his own record via the Portal, he would need to be presented with a different screen. But still, it would make sense if that screen was designed inside SuiteCRM, not Joomla.

What I was always concern about something like this is that you will have to create users for them, and in suitecrm when you want to assign something to someone ALL the users are listed there, so the customers will be there too, maybe there’s a way to pre filter this, I have done in in the pop up box but not in the ajax call

best regards

Mike, that is a very valid point you make there.

Generalizing, I think that Security Settings only give you

  • menu-level restrictions (which options to show)
  • record-level restrictions (which records you can view/edit/delete)

But don’t let you specify

  • field-level restrictions (keep some fields unavailable)
  • how to populate lists (basically, record-level restrictions of some related data like users to assign, etc)

It seems to me that using a “SuiteCRM-based SuiteCRM Portal” is

  • something that is not ready yet
  • something that will require dedicated development of each and every screen (like most current portals) - this is just a consequence of how different it is to handle internal users vs customers


  • if you’re going to develop a portal, one screen at a time, it would still be better to do it from the same framework you already have and use, not from an extra layer of Joomla or Wordpress.
  • an internal Portal would highly simplify installation and maintenance
  • if we were to start this, we would start by replicating current Portal functionality (which isn’t that much): Documents and Cases.
  • in Studio, this could be just another kind of view you would build: Detail View / Edit View / List view, and now, Portal view