How To Store The Date of A Field Change?

Hello Vince
You can set "on" the "Audit" flag for this field in the Studio. After that, all changes will be logged, and you can see the history of changes in the Audit Log (access from the drop-down ("Edit" button)).
Is this option appropriate for you, or would you like to see this date as a separate RLI field and use it further?

Regards!

Hello Vince,

Agree with Mykola about the field changes tracked automatically in the Audit Log.

Nevertheless, as Sugar Admin, I feel you are looking for smth more friendly for building out further CRM processes automation, aren't you?

As for me, achieving this is not about Dev Practice that demand dev efforts

Three steps:

1. Add a date field sales_stage_change_date_c for RLI module via Studio



2. Goto Module Loader and deploy field population logic:
TrackRLISalesStageChange.zip

3.Enjoy!

For the note - Sugar behavior configuration provided in the ZIP is the following:



If any questions I would be happy to help

Cheers!

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,

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.

Hi Dmytro,

As per my understanding, in the before save logic hook we can compare the new bean values and before values by using the fetched row. This might be the reason why @Francesca Shiekh has used the Before Save logic hook.

We cannot use the fetched_row property in the After save method in the Logic hook.

Hope this information helps.

PK,

https://www.bhea.com

Hi John

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

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!

Hi Poojitha,

Thank you - so far as I see, both before_save and after_save perform the same in the interface...
Let me double-check with logging and get back regarding this here

Technically you can use the fetched row property in the after save method by fetching it into a protected static variable at the time the before save runs, then referencing that variable in the after save.

The problem with that in general is that it can be dangerous to change the value of a field in the after save, as it will have to trigger a save which repeats the after save. So you have to make sure your conditions have a way to avoid the loop. You are also doing two saves instead of one, and re-executing all your before and after save logic hooks at each save, so lots more processing.

Dmytro's application probably takes all that into consideration.

No builders that  ever could be  comparable to the pure code creation performed by experienced developers - builders are always about the  ability to get solution fast and for the reasonable cost and than to maintain it yourself (just like I switched to before_save and didn't spend time on creating another package)

Basic tech skills of the admins allows to avoid logic mistakes  when dealing with triggered events

In case of an infinite loop is mistakenly designed in a flowchart, yes, there is a stopper for the runtime. 

Not sure wether any stoppers in the code when infinite loop is written manually, perhaps,that might be a kind of developers warranty efforts in case that happends.