Best practices for new cases & Linking to contacts

Suman Bandopadhyay - Can you and Caleb reach out to Glenn on this?

Hi Glenn

AFAIK, the Case belongs to an Account ("Rystad energy" account on the screenshot), not to the Primary Contact.

Lemme explain this conclusion.
First, The Primary Contact could be even not that person that submitted the Case - even a person from another company, so if you open the Primary Contact record view, you may not find the case listed on its Case subpanel.

Second, if to employ e.g. Customer Portal , you will see that all Contacts of Account have access to all the Cases of the Account they belong to. While the "primary contact" of the case may even not have access to the case if the Contact belongs to another Account...

I'm trying to say that if to try building Cases-based support service around the Contact entity rather thanAccount, that may require some configuring efforts.

However, specifically regarding the question:
IMHO linking contacts to the case via subpanel would provide more advantages - if to open the contact record view, it is possible to observe all the cases along with the activities of different types - on the corresponding subpanels for the contact record.

In the meantime, if you like the Primary Contact field, it is easy to configure a simple logic hook with a low code tool (Logic Builder) to get both - contact on the subpanel and contact in the Primary Field.

So, the logic hook would perform the following: On the Contact set as Primary Contact, to link it to the Case's via subpanel automatically (and unlink the previous primary contact, if necessary)

Makes sense?

Hello,

Okay, here is the true reason why the low code approach is in big demand worldwide for flexible CRMs as Sugar is - I've spent just 20 min for covering the subscriber's user story with configuring  - easy-peasy!

Here is the flowchart is drawn in the Logic Builder configurator, it could be easily read by following the white line - whenever Primary Contact ID is changed for the Case (the new value is not equal to the previous) to link the new Primary Contact to the Case with regular subpanel relationship then unlink previous Primary Contact

I test it out on demo instance and therefore I hope this could help not to bother anymore about the different ways the users may use to relate contacts with cases- primary contact or subpanel

Here is the zip for an admin to install logic hook via Module Loader:
OnPrimaryContactIsChanged.zip

I hope this helps and let me know if any questions

Hi Dmytro, 

Thanks for spending so much time on this but really we are wanting to just find out the best practice within SugarCRM for cases and contacts without making any customizations. Suman Bandopadhyay - are you able to confirm?

Thank you both

Hi Glenn, 

Currently the logic hook mentioned by Dmytro is the only way to keep the two in sync. Having said that we are looking into how we can bring the two in sync in the standard product.

Thanks,

Suman

Glenn,

The Primary Contact field was primarily introduced with improvements to Sugar Serve and is populated when a customer logs a case through the Self Service Portal. Cases created via email do not automatically populate this field. when using BPM you can leverage either the Primary Contact field or all Contacts (its a bit cryptic the way its displayed in BPM (the 1 to 1 is Primary Contact, the m is the contacts in the Subpanel).

We have a mix of customers using the portal and case emailing so we have the mix.

Personally, I think best practice is to use Primary Contact for portal population and Contacts subpanel for Case Email/manual creation. I originally was looking at populating the Primary Contact field until I learnt how it was intended to be used and then resisted the temptation.

Regards

Greg Barrass