How can I share a lead's information with an Account?

The Sugar Customer Support Portal appears to now provide the ability to make the Leads Module (along with other modules) visible in the portal. Along with the recent enhancements to the portal (especially the latest release) definitely worth assessing as an option.

Hi Greg, I don't think it is possible to add other modules in the portal without custom code. If you were thinking of the recent 11.1 release, it's possible you were thinking of SugarLive in Sell, which added the Lead and Account tabs to SugarLive. Or is there something else you were referring to?

It is true though that the portal had some great enhancements recently, mostly for Serve. The Serve 11.1 release notes outline the new features there.

-Brenda

Brenda,

Oh - I assumed that was the case as in the Configure Portal screen it offers to select a whole range of modules these days ?

In stock Sugar, I only see Cases, Bugs, and Knowledge Base, as usual. Maybe the instance you're looking at is customized? Having more modules would certainly be cool to expand the use cases for the portal!

-Brenda

Stock standard as far as I know

Enabling other modules into Portal, even custom ones, is possible without custom code if the module has a relationship to either Accounts or Contacts and if such a relationship is the enough to fetch data properly.

In case criterias to load data from other modules into Portal is not that simple, then it is possibile to implement a specific Visibility Strategy for that module in Portal.

Hi André Lopes and Greg Barrass, I am still not sure how to enable other modules for the portal without custom code. Can you tell me how you added those modules there and if they are actually accessible in the portal when enabled? I must be missing something.

Greg Barrass and André Lopes

What is mentioned here might not be entirely accurate.

You need some custom extensions and custom views today, for modules to show up in the portal.

The portal has much more flexibility than in the past, where as Andrè correctly mentioned, with a relationship to Accounts or Contacts, the default visibility can be leveraged, but to activate it, you would still need some custom extensions and views.

I just confirmed on an enterprise version 11.1 and this is what the configuration screen for the portal looks like:

This reply: https://sugarclub.sugarcrm.com/explore/enterprise-professional/f/enterprise-professional-questions/4195/sugar-portal/21399#21399 contains quite a bit of info on how to extend the portal

Hope this clarifies what is possible and available today on the Sugar Customer Portal

Cheers

We have no custom extensions or views that we are aware of and are running Sugar on Demand. 

I think it is a corruption in our Configure Portal screen as the modules do not deploy anyway,

Enrico Simonetti is totally right about:

custom extension (to enable portal visibiility)

$dictionary['Class']['portal_visibility'] = [
    'class' => 'Module',
    'links' => [
        'Accounts' => 'accounts_link',
        'Contacts' => 'contacts_link',
    ],
];

and custom view (to enable configuring record and list view for Portal). Custom views must be placed inside core module (modules/Module/clients/portal/views/) in order to let Studio realize that module is portal enabled.

Additionally you have to enable that module into Role "Customer Self-Service Portal Role".

Finally you have to run QRR and Repair Roles.

You will be able to modify the views record and list of that module for Portal. Mind you also need to move the target module from tab "Hidden Modules" to "Displayed Modules".

On authenticating with a valid Portal User you will be able access that module accordingly.

Portal platform is "almost" as flexible as base platform is.

We had implemented pretty amazing features for some customers, like:

• Filters
• Custom dashlets
• Modules dashboards
• Subpanels
• Readonly Reports built in the base platforms
• Dynamic and wizard layout for Cases create view
• Custom and complex Portal Visibility Strategies

In short words, it is possible to evolve the Customer User experience, leveraging relationships.

Enrico Simonetti is totally right about:

custom extension (to enable portal visibiility)

$dictionary['Class']['portal_visibility'] = [
    'class' => 'Module',
    'links' => [
        'Accounts' => 'accounts_link',
        'Contacts' => 'contacts_link',
    ],
];

and custom view (to enable configuring record and list view for Portal). Custom views must be placed inside core module (modules/Module/clients/portal/views/) in order to let Studio realize that module is portal enabled.

Additionally you have to enable that module into Role "Customer Self-Service Portal Role".

Finally you have to run QRR and Repair Roles.

You will be able to modify the views record and list of that module for Portal. Mind you also need to move the target module from tab "Hidden Modules" to "Displayed Modules".

On authenticating with a valid Portal User you will be able access that module accordingly.

Portal platform is "almost" as flexible as base platform is.

We had implemented pretty amazing features for some customers, like:

• Filters
• Custom dashlets
• Modules dashboards
• Subpanels
• Readonly Reports built in the base platforms
• Dynamic and wizard layout for Cases create view
• Custom and complex Portal Visibility Strategies

In short words, it is possible to evolve the Customer User experience, leveraging relationships.

Thanks André Lopes,

One minor improvement, I would make sure to put the view(s) to the custom module's "custom/modules/Module/clients/portal/views" not on the core directory.

Cheers!

So this is a new improvement on version 11.1, because previous versions required portal folder inside core module instead!

That is a great news!

André Lopes, this is indeed odd.

Unless something has changed since version 9.2 where the portal changed implementation (which I did contribute to, personally), that was one of the changes I have implemented to allow the use of the custom folder only.

You could use this linux diff/patch, which I used at the time (2 years ago as you can see from the gist creation date), to test the addition of a new fully visible Sugar module:

https://gist.github.com/esimonetti/4690a0220895dc3f8eb2da809bcd817a

Obviously you would need the module in there first, and also the permissions correctly set on the Portal role.

Feel free to test and confirm, if this is still applicable today though!

Thanks!