Is there a reason that you are using the AJAX toolkit to do your updates? This would be a lot easier with the Skuid Action Framework, or with the Skuid JavaScript API if you can’t use the Action Framework:

SINGLE ROW SCENARIO

var oppModel = skuid.model.getModel(“Opportunity”);
oppModel.updateRow(oppModel.getFirstRow(),{
   Field_One__c: null,
   Field_Two__c: null
});
oppModel.save().then(function(result){
    console.log('save finished. Did everything succeed? ’ + (result.totalsuccess ? ‘yes’ : ‘no’));
    if (result.totalsuccess) {
        // Do the next update (now that the trigger has finished, ideally)
       oppModel.updateRow(oppModel.getFirstRow(),{
          Send_Date__c: skuid.time.getSFDate(new Date()),
          Send_Single__c: true
       });
       oppModel.save().then(function(result2){
            console.log(‘2nd save finished!’);
       });
    }
});

MULTIPLE SCENARIO

var oppModel = skuid.model.getModel(“Opportunity”);
var updates = {};
$.each(oppModel.getRows(),function(i,row) {
   updates=row.Id] = {
      Field_One__c: null,
      Field_Two__c: null,
      Send_Date__c: skuid.time.getSFDate(new Date()),
      Send_Single__c: true
   };
});
oppModel.updateRows(updates);
oppModel.save().then(function(result){
    console.log('save finished. Did everything succeed? ’ + (result.totalsuccess ? ‘yes’ : ‘no’));
});

Yeah, we generally have the same logic in Salesforce buttons so we try to keep the code roughly similar on the Skuid side for maintainability (would be very nice if we could just include the javascript SF buttons in Skuid pages to avoid all the duplication, but that’s a separate issue).

I can give this approach a try, though your multiple scenario doesn’t quite match our use case (we’re updating the same Opportunity twice in a row).  Assuming we can call oppModel.Save twice in one snippet, then we should be ok.

I updated my “single row scenario” snippet example to have a second update and save call immediately after the first one finishes — that should be totally fine.

Thank you! This did the trick (once I tracked down a failure due to calling getSFDate instead of getSFDateTime).