Overrides vs. Actions, Part 2 - Understanding Actions: The “Lazy-Loading” Approach

In Part 1 of this series we explored Overrides, the eager approach where visibility logic is evaluated for every node at page load. Overrides are perfect for simple, static conditions and bulk operations — but they can quickly become a bottleneck when logic grows complex.

This is where Actions come in. Actions take a lazy-loading approach: instead of running checks upfront for all visible nodes, they execute only when a user opens a node’s context menu. This makes them ideal for scenarios where visibility depends on dynamic or resource-intensive conditions.

In this article, we’ll dive into how Actions work, when to use them, and the trade-offs to consider compared to Overrides.

Actions: The “lazy-loading” approach

How actions work

Scripts placed under the Actions folder are evaluated only when the user clicks the three-dots menu (context menu) on a node. At that moment, the system decides whether the command should be visible for that specific node.

This ensures that page load performance remains unaffected, since no additional checks are executed upfront.

When to use actions

Actions are the right choice whenever command visibility depends on conditions that are:

• Dynamic — e.g., current workflow state, lifecycle stage.
• User-specific — e.g., checking if the user has a certain role or permission.
• Data-driven — e.g., querying metadata, performing database lookups, or running external validations.

Because the script runs only once per node (and only on demand), you can safely include more complex logic without degrading overall navigation performance.

Pros and cons of actions

Advantages

• Perfect for complex or dynamic logic.
• Zero impact on initial page load speed.
• Keeps the user interface responsive, even on pages with hundreds of nodes.

Limitations

• Does not support multi-node (bulk) actions, since evaluation happens only for the single node whose menu was opened.
• Users may experience a slight delay when opening the menu if the logic inside the action is heavy.

Real-world example

Imagine you want a “Submit to Legal Review” command that only appears if:

• The document is currently in the Draft workflow state, and
• The logged-in user has the “Legal Approver” role.

Both checks involve querying workflow state and permissions — operations that are too expensive to run on every document at page load. By placing this command under Actions, the logic executes only when needed, keeping the system fast and responsive.

Best practices for actions

• Use Actions for expensive checks (permissions, workflow states, metadata lookups).
• Keep logic focused: even though Actions are lazy-loaded, heavy queries may still slow down the context menu.
• Don’t rely on Actions when bulk processing is required — that’s what Overrides are for.
• In complex solutions, combine Overrides and Actions: use Overrides for static visibility rules, and Actions for advanced dynamic checks.

To sum up: Overrides vs. Actions - A quick comparison

With Overrides and Actions, Module Suite gives you two complementary tools for controlling command visibility:

• Overrides → Eager, bulk-ready, best for static rules.
• Actions → Lazy-loaded, flexible, best for dynamic conditions.

By understanding when to use each, you can design custom commands that balance performance, usability, and functionality — delivering a smoother experience for both users and administrators.

‍