How To Store The Date of A Field Change?

I would like to store the date when the RLI Sales Stage changes. I've tried various techniques including Custom Calculated Fields and SugarBPM, but I can't quite find the right method to accomplish this. I've looked at several solutions, but can't seem to make them work...

Any thoughts out there? Thanks ahead of time! VO

Parents
  • I have not worked with RLIs but I assume you can work with logic hooks. In which case, I would use a simple before save logic hook.

    I do this in Cases to record the date of the last Status change:

    I created a field in cases case_last_status_change_date_c of type DateTime

    then in the before save logic hook I compare the status to see if it changed:

    function before_save ($bean,$event,$arguments){
       $today = $GLOBALS['timedate']->nowDb();
       if($bean->status != $bean->fetched_row['status']){          
          $bean->case_last_status_change_date_c = $today;
       }
    }
    
    

    (I use a variable for the timestamp because I use it elsewhere in my before save logic too)

    FrancescaS

  • Hello Francesca,

    I have drawn an after_save logic hook for this case and it works.

    Do you suggest switching in the logic hook drawing above from after_save to before_save in the starting On Data Change operator?
    Is there a reason for that?

    Thanks,

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • Dmytro,

    In programming terms "it works" !== "optimum solution" ;)

    As you are setting the value for the date on the same bean as the status change, using an after_save hook here will at the very least save the record twice, wasting processing. In fact there is also a strong chance of getting into an infinite loop here as well so that is also something you need to take into account.

    Better practice to use before_save for things like this as it is the correct tool.

    Thanks,

    JH.

Reply
  • Dmytro,

    In programming terms "it works" !== "optimum solution" ;)

    As you are setting the value for the date on the same bean as the status change, using an after_save hook here will at the very least save the record twice, wasting processing. In fact there is also a strong chance of getting into an infinite loop here as well so that is also something you need to take into account.

    Better practice to use before_save for things like this as it is the correct tool.

    Thanks,

    JH.

Children
  • Hi John

    "it works" !== "optimum solution"  depends on the scope-  if to expand programming scope to business scope, optimum could be another Slight smile


    Thank you, I followed your suggestion and changed after_save on before_save in the flowchart and regenerated ZIP with a click


    Here it is:
    TrackRLISalesStageChange_beforesave.zip



    The infinite loop might not happen until the checked field is updated and saved again  - but anyway, if the designer miss this, there are mechanics that prevent infinite loops after some iterations

    Thank you!

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • Combined with your earlier instructions on creating the Sales Stage Change Date field, this seems to be working in my development instance. Is there anything I should know about the code, such as expiration or SugarCRM upgrade maintainability, before I put this into my production environment? 

  • Nice to hear that :)

    Okay, here is some information:

    1. ZIP extension generated in Logic Builder does not require anything but compartible Sugar platform itself to operate. It does not make any outbound calls by its own or anything like that , it also store neither PII nor any customer data.

    2. As ZIP manifest says, configuration is compatible with all Sugar flavors, both SugarCloud and OnPrem, starting version 7.9 and till the latest one.

    According to the 4years of upgrade experience, configuration extensions generated with Logic Builder pass health checks successfully - there were just a few occasions that demanded to refresh ZIP by regenerating it in the Logic Builder environment to ensure new Sugar version compartibility - all these cases were related to some methods depricated in Sugar.
     
    For the ready-to-use solutions that I share in the Club for the free usage, I will do refresh myself - on the first clubber's inquiry - and upload refreshed ZIP in the Club in response (as you see, refresh takes a few min)
    I say "will do" because so far, there was no necessity to do that regarding any of configuration I have shared here in the Club.
     
    3. ZIP includes the flowchart drawing - that drawing the configuration is generated from.
    Therefore anyone who has access to Logic Builder environment can extract a flowchart drawing from zip (its a JSON text, feel free to ask me how to get it), import it to Logic Builder environment, adjust logic there and generate own version of solution as a new ZIP - with a click

    4. The configuration could be uninstalled any moment - apply regular Uninstall for ZIP in Module Loader for that. This approach also works if the task is to substitute old configuration with a new one - uninstall previos and installl new one

    Let me know if any questions that remain unanswered

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient