How do I get a Skuid Action Sequence to do different things based on some other things?

How do you wire a complex logic into a single, concise, maintainable Skuid Action Sequence? Advanced Salesforce Developer Simon Lawrence has answers on how this works on Skuid’s no-code platform. 

As far as blog titles go, this probably isn’t the most technical I have ever written, but it is exactly what I remember thinking as I was presented with getting a complex Skuid Action Sequence to do one or two specific different things based on some attributes of a model.

As a (hopefully) clear example, imagine if you had an Action Sequence being executed when you clicked a button, that among things like saving some models, activating a model condition, invoking a couple of component actions and then if one of the Models on the page was saved with a certain check-box value, created and saved a new audit record with a timestamp in it as well; how might you wire that all into one, concise, maintainable structure?

Now, up until recently, my mind would turn to automation tools for that sort of thing; When Model A was updated I could fire a Trigger or Process Builder to evaluate the checkbox and if necessary save a new Audit record. That would totally work, and this is great, but there are a few downsides. Obviously with Triggers, we are coding ourselves into a higher level of maintenance, and even with Process Builders, we are scattering our automation all over the place. If there is one thing Salesforce is not short of, it’s places to hide bits of functionality.

If we are doing everything else in this button press in Skuid, why not also conditionally make the Audit record on save?

The longer you use Skuid, the more amazing features you uncover, we all know that right? Well through 2018 I have discovered, and become increasingly interested in the event driven aspect of the Action framework, and these conditional logic branches.

If I was faced with the above requirement of saving a new Audit record with some values in it whenever an Opportunity was saved, with a certain Check-box ticked… I would follow something like these following screenshots..:

1. Firstly, you can tether Skuid “Actions” onto the data “Actions” of a model, such as when they are saved or deleted.

2. We can define what events we want to trigger our sequence, you can have multiple sequences for the same actions, and multiple actions firing the same sequence!

3. Now, from the Actions tab, we can add an Action element which is “Logic > Branch”

4. Here – for one of the very few times in Skuid – the GUI-builder falls a little short, because you can’t just click away and build a powerful set of conditions, we have to revert to our former Excel/Formula Field selves and write a formula that governs entry to the branch:

We can pick the Model on which the formula is based though, because Logic branches can be included in any Action Sequence, so it might not always be as obvious as from one fired from a Model Event. In this case, we say we only want to enter the branch if the Is_Tracked__c field is true, which is simple enough.

We then use the plus arrow on the Branch element to create new actions within it

And they nest in beneath it like so:

And just like that, when rows in our Opportunity Model are saved, only if their “Is_Audited__c” checkbox is ticked, Skuid will create (populated) Audit records and save them.

If you have an up-to-date (v11.2+) version of Skuid too, there is another sexy option on the logic branch for what to do next –

So you can end execution if you logic branch is perhaps determining an end-game for that action, or you can just let execution flow on to continue doing all sorts of other things (including other logic branches!)

So consider the following fairly complex action sequence that is fired on the instant an Opportunity record is saved:

1. First off, if the Opportunity is Tracked, we create and save and audit record. After this branch, we continue execution.
2. Whenever the Opportunity record is saved, we clear out some other model, or do anything else – in all cases.
3. Now, if the opportunity isn’t marked as complete – we show a specific pop-up to the user. On this action, we elect to “Not run any other actions” and the experience halts with the popup.
4. If the last branch was not met (ie. the “Opportunity is complete” logic did not fire) we instead open a sliding panel. This has executed kind of like an “else” to the branch in No.3.

How cool is that then? All this done in Skuid – in one place, and thus it is super accessible and customisable by future users without the need for code, or even Cloning/Activating/Deactivating a dozen Flows.