hack [hāk]

-verb (used with object):

  • To cut, notch, slice, chop, or sever (something.)
  • To damage or injure by crude, harsh, or insensitive treatment; mutilate; mangle.

-computing jargon:

  • A quick job that produces what is needed, but not well.
  • To alter the intended function of a computer program to suit your needs in a skilful way.

-Sage CRM Support:

  • Completely unsupported method of enhancing the product that may break (itself or the core product) with upgrades.

What makes a hack a hack?

Basically when it relies on the product working in a particular undocumented way.  For example, client-side scripting can achieve many useful things by fiddling with the HTML in the browser, however, the way that the user interface is implemented in HTML by CRM is not documented and therefore is subject to change.  SageCRM reserves the right to change the internal workings of the product at any-time to improve the product; and we do this all the time!  So whenever you create a customization that relies upon an undocumented working of the product you are introducing a risk of that customization breaking (either itself or the whole product) with upgrades.

When to use a hack?

Officially?  Never!  Always use the supported UI & API methods of customizing CRM.  This is so you can guarantee that your customization will continue to work with patches and upgrades with minimal rework & testing required.  Also you have Sage's help & support in fixing problems should they arise upon patching or upgrading.  SageCRM only supports the latest patch level on the last three major releases of the product, so if a customer is tied to an old patch because of the regression testing required for upgrading your unsupported customization they have effectively lost their support from Sage; and this is not good for anyone involved!
Note: CRM patches are released quarterly with major versions approximately once per year.  Sage does not support customizations; they support the ability to make customizations and the API’s.  The Sage CRM Level 3 Support team will not troubleshoot custom code in a support case, that is a chargeable service.  Consult your local PSG team for help with your customizations.

If it’s not supported why do you blog about hacks?

Sometimes a client-side feature, that is not available in the core product, could be very useful to a customer.  Sometimes the cost of testing, and possibly re-writing, a hack at each patch/upgrade is less than the benefit of the customization to the customer.  Often such features are a convenience to the end user and it does not matter a great deal if the feature is removed entirely if it breaks.
From my experience from working in the CRM Support team I know that people hack CRM all the time, rather than discourage it entirely I’d like to educate people to the risks involved and hopefully show, by way of example, low risk approaches to non standard customizations.

Guidelines

  • Always attempt to use the APIs and customization features available in the core product first.
  • Never rely on a client-side hack to enforce any kind of business logic or security.  (This should be done in server-side scripts: create/validate & table level scripts.)
  • If your hack adds critical functionality to the product seek advice in the form of a customization review from your local PSG teams so they can give you an assessment of the risks you are introducing.
  • If you are using your hack all over the place it may make a great feature for the core product and we’d love to know about your idea.   Please log an enhancement request through your support channels and the feature may very well end up in the next version of CRM!