sugarondrupal.drtsg.net

I've reviewed and discussed this issue too many times with several customers. I don't want to say that SugarCRM Self service Portal is bad, I don't think so, but I agree with them in that it's not as flexible as they need. Everytime I try to argue that the purpose of that portal is heavily defined and it works as it should, they answer me that "it doesn't work as they want". This flexibility is going to be a requirement also in SugaronDrupal project.

Lets describe a little bit current SugarCRM portal functionality first, and then we can deviate to what is, in my opinion, a more flexible way. For that I will relate some conversations and currently implemented registration -> lead -> convert to Contact workflow.

So, The SugarCRM portal includes a "Login page" (for already registered users) and a "Registration page". Here, a new "registered user" is created in SugarCRM as a Lead. "Contacts" are the only SugarCRM objects able to login into the Self Service Portal. To be able to login, a SugarCRM user should create a "username" and a "password" for them in its "Contact edit" page, and also check the "Portal active" option. Now, a currently existing contact is able to login.. good. but what happends to Leads? a Lead just fills a form with some information. If the Lead is valid, and at some point could already be converted in a "Contact", then a conversion operation should be performed by a SugarCRM user. Up to here, everything looks fine for me and my interviewers. Now, to finish having a new web site user, a SugarCRM user should look for that "Brand New Contact", again edit it (has previously edited already in the conversion part) and put the self service portal username and password and check the 'active' property. This will happen for any new person being registered in the website.

I've tried several approaches to solve this "workflow issue". As the ConvertLead layout is not available in the Studio, I had to manually modify the SugarCRM setup. I personally hate this approach, as requires more manual manipulation on each SugarCRM update. Once I did already change the ConvertLead layout to include portal username and password fields, and worked pretty well for one or two upgrades, then suddenly broke up the site and we had to revert changes (never did it again). The next approach was to use the sugarondrupal concept, creating specific fields for the username and password, and then changing some code in the Portal application to query for these new fields instead of login using SugarCRM portal username and password fields. This approach is still working. But lastly I hate to touch SugarCRM code but for very special cases, and the self service portal is not on of them. I preffer much more to setup a Drupal site and use other workflow for the "Lead to Contact" conversion without the need of requiring to set username and password for the SugarCRM user.

Actually, this is the way I'm doing lastly, and the way that will be introduced in the SugarOnDrupal module. This is a list of ideas and concepts about this new workflow:

- User credentials will be stored in Drupal. Users register using the Portal site (in this case a Drupal site). Leads and contacts will do require to register. If you don't want to allow free registration, you may still need to add these users somewhere, and that "where" is still Drupal, you will have to create Drupal users.
- Validation should be considered for the registration process.
- By default, the "email" of the registration will be used for the "link" between Drupal and SugarCRM, so any group/list email address should be avoided for Contacts and Leads.
- There's a Authentication query, that does a Match and performs validation with SugarCRM. Following the sugarondrupal concept module, this string will still ask SugarCRM if the user is able to login or not, and this could also be used for other things. (time based login: from 8:00am to 16:pm, or under certain circunstances: only allow login if a case is still "Active").. whatever you want to twist..
- by default registered users may login.. of course.. even if they are leads.. you may avoid Leads login using the authentication query.
- If the email address used for registration exists as a Contact in SugarCRM, lets the user be a contact.. with email verification you can be sure that the user is your Contact.
- If the email address is not a contact, then create a Lead in SugarCRM.. If you convert to contact in SugarCRM later the credentials will still be valid and would login the site.

More or less this is the idea.. It may look terrific of "defaults" and "complex" the first time, but once used and configured it is very flexible.. But for the SugarCRM user it is more simple. Just forget about the Portal login, each user/customer/lead is responsible of their account.

Of course, I didn't say anything about what is the difference in Drupal between a Contact and a Lead if both are able to register, create an account and login in the site.. but this will be in other post :)