Best Practice for Saving Data/Toggling Modes

[MikeMeilleur]

Hi folks!

We are working on a couple of custom objects that interact with the record data, but also update data in the background via a REST call.  Is there a best practice for how to handle the data on the screen and the record modes themselves?

For example, while in Edit Mode, a user clicks a custom object button, it runs a process, and then updates some data in the database.  Now the data in the database and the data on the screen is different.  If they hit Save at this point, they are presented with a conflict resolution screen.

In short, is there a way to refresh the contents of the record screen while in Edit Mode once the REST call has been completed?  That would be ideal.

Thanks!

[DavidPetty · Accepted solution]

Mike, any particular reason you're updating record on the backend and not directly to the record itself?

I don't know of anyway to refresh the record while in edit mode.  But you could try to save the record, put it to view mode, run you REST code and put the record back into edit mode.

[MikeMeilleur]

So the button kicks off a process external to Archer and when the process has been completed, a GUID is returned and saved to the database.  This GUID is used to drive other downstream work items.

Are you recommending that instead of saving to the database, we populate the field directly with the GUID that is returned, and force a hard save to the record?

[DavidPetty]

Correct.  Just update the field directly in the open record and save.

[MikeMeilleur]

That makes sense.  Is it best to use the $CM.setFieldValue() to do so?

Trying not to re-invent the wheel. :-)

[DavidPetty]

If the field is a text (not text area) field, use this function, https://community.rsa.com/message/938589?commentID=938589#comment-937830 

[MikeMeilleur]

Thank you, sir!