When to create a small reusable Action in Flow Designer (and when not to)

Nayara Gomes da · Monday

Flow Designer makes it easy to orchestrate business logic without writing large scripts.
However, as flows and subflows grow, a common question arises:

Should I keep all logic inside the subflow, or should I create a separate Action?

This article shares a real-world scenario and a practical decision framework to help you decide when creating a small reusable Action is the right choice — and when it is not based in my experience.

The common dilemma

In many implementations, developers start adding logic directly into a subflow using:

Conditions
Lookups
Script steps (when available)

At some point, the subflow becomes:

Harder to read
Harder to maintain
Harder to reuse

The temptation is either:

to keep adding logic “just this once”, or
to over-engineer everything into separate Actions.

Both approaches can cause problems.

A real-world example: extracting the year from a date

In a project, we needed to compare:

the year of a case creation date (created_on) - in the default HRSD
with the year returned by an external system (ISO date string) - returned of a action

The same transformation was needed:

in multiple subflows
with different date formats (ISO, dd/MM/yyyy, DateTime objects)

At first glance, this looks like a very small piece of logic.

So… should it live inside the subflow?

When NOT to create a separate Action

You should avoid creating a new Action when:

The logic is used only once
The transformation is very specific to that flow
The logic is trivial and unlikely to be reused
It does not improve readability

Example:

Simple field mapping
One-off condition checks
Flow-only orchestration logic

In these cases, keeping the logic in the subflow is perfectly fine.

When a small reusable Action makes sense

Creating a small Action is the right choice when all of these are true:

✔ The logic transforms data
✔ The logic is format-dependent or error-prone
✔ The same logic may be reused in multiple flows
✔ Encapsulating it improves readability

In our case:

Date formats were inconsistent
Flow inputs could be String or DateTime
Errors like substring is not a function appeared
The same comparison logic was needed more than once

That was the signal.

Example: a micro Action that solves the problem

Action purpose

Extract the year from different date formats safely

Inputs

created_on_case (String / DateTime)
dataStatusAPI (String – ISO format)

Outputs

yearCase
yearAPI
shouldCreate (Boolean)

Script step add in action:

(function execute(inputs, outputs) {

if (!inputs.data_input) {
        outputs.yearApi = ' ';
        return;
    }
     var dateAPI = String(inputs.dataCase);
     var dateCaseString = String(inputs.data_input);

     outputs.yearApi = dateCaseString.substring(0, 4);
     outputs.yearhrcase = dateAPI .substring(0, 4);

})(inputs, outputs);

Now the subflow simply calls the Action and uses the output, without worrying about date formats and if you need more logic that involve date/time you can add inputs and outputs and pass in the flow/subflow that you want.

Benefits of this approach

✔ Cleaner subflows
✔ Reusable logic
✔ Easier debugging
✔ Fewer silent runtime errors
✔ Better separation of concerns

Most importantly, the business logic becomes explicit, instead of hidden in ad-hoc script snippets.

A practical rule of thumb

If the logic transforms data and can be reused, it belongs in an Action.
If the logic orchestrates steps, it belongs in the Subflow.

This simple rule helps keep Flow Designer solutions scalable and readable.

Conclusion

Creating small reusable Actions is not over-engineering — when done with intention.

By identifying transformation logic early and encapsulating it properly, you:

reduce technical debt
improve maintainability
and make your flows easier to reason about

Sometimes, a 15-line Action can save hours of debugging later. Hope this help you to solve any problem or make you have an idea to solve.