Updating "Last Email" and "Last Call" fields in the Accounts and Contacts Modules

In my Accounts and Contacts Module I created fields named: "Last Email to (Account or Contact)" and Last Call With (Account or Contact)".  The fields are set with calculated formulas that read: maxRelatedDate($archived_emails,"date_sent") -and- maxRelatedDate($calls,"date_entered").

The field is updated any time the Account or Contact Record is saved.

I've recently discovered that scheduled reports that "encourage" sales folks to keep in contact with Accounts and Contacts are not accurate because logging a call or sending an email doesn't trigger the field update.

I'm trying to find a way to trigger a no-op update of the Contact and Account records so the field gets updated when a call is logged or email archived and the reports will therefore be accurate.

Any ideas?

P.S. (We don't have any custom code in our installation - everything is done with Studio and BPM).  Thanks.

Parents
  • Hi ,

    The behavior you're seeking is the default behavior with how Sugar handles related calculation fields. If the only way the field is updating is by doing an explicit save on the account or contact record, then it is likely you have a config option 'disable_related_calc_fields' enabled on your instance. This configuration cannot be toggled in the UI, so it's possible Sugar Support may have enabled it for you from a prior support issue to prevent performance degradation with how related calculations can cascade through modules on updates. 

    If you don't recall having this configuration enabled, I recommend filing a support case with Sugar Support to see if it is enabled, and if so, they may have record of why it was enabled so you can determine the best path forward. 

    Chris

  • Thanks Chris!  Yes!  That's the answer!  (As it works out, that wasn't the answer) I have other processes that created the problem of cascading updates that impacted performance about six years ago and the resolution was to disable the related calculations.

    Now that I know, I'll look back at the processes that were triggering the cascading calculations to see if I can work around this.

    Bud Hartley | Cape Foulwind, NZ (and Oregon, USA)

Reply
  • Thanks Chris!  Yes!  That's the answer!  (As it works out, that wasn't the answer) I have other processes that created the problem of cascading updates that impacted performance about six years ago and the resolution was to disable the related calculations.

    Now that I know, I'll look back at the processes that were triggering the cascading calculations to see if I can work around this.

    Bud Hartley | Cape Foulwind, NZ (and Oregon, USA)

Children
No Data