I have been blogging about examples in which business logic hooks in Sugar CRM are used to customize a system and safeguard the customizations from possible changes to the core SugarCRM code. Here is another example from W-Systems' client files.
A custom module in the client’s system has a custom drop-down list of “reason codes.” The module also required users to choose from two additional drop-down lists to specify which type of reason code was chosen in the first drop-down list. Since each reason code always represents the same two drop-down options in the other two drop-downs, it is a waste of time for the rep to set the second two drop-down fields when they could be set automatically. Nevertheless, the extra two fields are needed for reporting purposes and are desirable to have on the detail view.
We removed the two extra fields from the edit layout entirely but left them on the detail layout, where they are still reportable just as before. We added a business logic hook to the before_save event. Now, based on the value set in the Reason field, the system automatically sets the other two fields to the corresponding values that the reason code represents. When a user selects a reason code and saves the record, the system sets the other two items automatically. The system is now easier to use, and data integrity is enhanced. Was it necessary to use a business logic hook to make this minor change in Sugar functionality? No. Did it make the customization easier and safer? You bet it did!
Do you have a technical question about SugarCRM? Post your question in a comment and I'll try to answer it here. Alternatively, Contact Us and I'll respond by email.