Skip to main content
Nintex Community Menu Bar

Lately I’ve been needing to run some logic after the user has completed changing some things, but before the model is saved.  I’ve tried the row.updated event, but it triggers as soon as an item changes rather than when user user says to commit.  And models.saved is after the object has been committed.  Is there an event I can get when the model is about to be committed - like after the user clicks SAVE and before the actual save is sent to SFDC?

As an example use case, I want to detect when the user enables a checkbox and then set some audit logging in another field (such as the ID of the user who changed it).  I don’t want to overwrite the old value if the user should just check and uncheck the box (which is what would happen on row.updated events).  And I’d prefer not having to commit the data twice, which is what happens when I use models.saved (and, I no longer have access to the original values, which means I have to manually save values when the object is loaded).

Any other way to get a “before save” event?

Thanks,

- Chris

Hi Chris,

I had the same use case and implemented using workflow rules.  The rule criteria was ‘Evaluate the rule when a record is created, and any time it’s edited to subsequently meet criteria’.

Irvin


This is a good idea, I’m going to change it to be an “Idea” status, we’ve considered publishing “before” events corresponding to each of the “after” events that we currently publish, allowing you to intercept and modify the various requests that are made to Skuid Models and Components. 


Irvin - thanks for the idea, and yes workflow would work for some of my use cases.  Personally I dislike using workflow when the logic is tied to a Skuid page as it “hides” the logic, but function trumps elegance!

Zach - thanks for adding it to the ideas queue.  Not sure “before” makes sense on many of the events, but it would be awesome for save.

For now, I have a workaround for those interested.  I added a Page Title and my own Save/Cancel buttons (with appropriate JS to manage their state to represent when Save is acceptable, etc).  I then implemented by own Save and used skuid.events.publish to publish my own “before save” event, then called save on the model(s) I needed to be updated.  Then in my other code, where I needed to worry about a field changing, I used skuid.events.subscribe to be aware of the before save event and make my model changes.  This way, when the Skuidify team does add a before event, my code is already structured to accept it easily and just drop by own save/cancel buttons and publish event code.

- Chris


Zach - Yes please 🙂  Having before/after would be a welcome addition to Skuid!

Chris - Depending on your use case, you could use a custom button in the page title set to run multiple actions.  Using the action framework, you could trigger various activities that would occur before a save.  Then, you could handle the onerror of the save itself and “undo” if the save failed for some reason.  This doesn’t handle the use cases where save is initiated from somewhere other than a button.  There are some solutions for those scenarios but they involve a lot of coordination and custom code.  Having the “before save” event would cover the spectrum of possibilities.