Overrides vs. Actions, Part 1 - Understanding Overrides: The “Eager” approach

Implementing custom commands in Module Suite is not just about the logic — placement inside the Content Script Volume defines visibility and behaviour. Two mechanisms control this: Overrides and Actions. Overrides use an eager-execution model, ideal for static conditions and bulk actions, while actions are lazy-loaded, designed for dynamic, resource-intensive checks. Choosing the right approach ensures both performance and usability. This two-part series starts with Overrides, followed by Actions.

Table of contents

Implementing custom commands in Module Suite for OpenText Content Management is not just about writing the command logic: Where you place your scripts inside the Content Script Volume is what determines when, where, and how those commands appear to end users.

This decision has a direct impact on:

  • Performance, whether your system stays responsive as users navigate.
  • Usability, whether commands appear in the right place and at the right time.
  • Functionality, whether users can execute commands in bulk or only on single items.

The two key mechanisms for controlling command placement are Overrides and Actions and understanding how they differ is critical for delivering a smooth user experience while keeping your system efficient.

This is the first part of a two-article series: here we’ll explore Overrides, their eager-execution model, how to target them precisely, and when they should (and shouldn’t) be used. In Part 2, we’ll turn to Actions, the lazy-loading counterpart designed for dynamic conditions.

Setting the stage: Why structure matters

Before diving into Overrides, it helps to understand where they sit in the bigger picture.

All custom commands in Module Suite are managed within the Content Script Volume, specifically under the CSSmartView folder. This folder is the backbone of how Smart View is extended: it tells Content Management what new capabilities exist and where they should surface in the interface.

Inside CSSmartView, you’ll find four key folders, each playing a distinct role in shaping how custom functionality behaves, from defining the actual command logic, to controlling visibility rules, to customizing how nodes are displayed:

  • Commands — Define what a command does when executed. This is the implementation of your custom logic.
  • Columns — Create custom dynamic columns to display additional metadata or calculated values in Smart View.
  • Overrides — Control when and where commands are automatically available on nodes, based on static conditions.
  • Actions — Make commands visible dynamically, running logic on demand when a user opens a node’s context menu.

Overrides: The “Eager” Approach

How overrides work

When a page loads in Smart View, every script inside the Overrides folder is immediately evaluated for each visible node. The system builds an Actual Override Map (AOM) linking overrides to nodes.

Which means that If your folder displays 50 nodes, and your override targets them, your script runs 50 times. That’s why override logic must be lightweight and efficient.

Targeting nodes precisely

Overrides let you control visibility with a structured folder hierarchy

  • S[Subtype] → Targets by subtype, making your command appear on all nodes of a specific subtype, anywhere in the system.
    • S144 = all documents
    • S0 = all folders
  • D[DataID] → Targets a specific node and its descendants.
    • D1258 = node 1258 + everything inside it
  • Combine D and S for more precision.
    • D1258:S144 = all documents inside folder 1258 (and its children).

Pros and cons of overrides

Pros:

  • Supports multi-node (bulk) actions.
  • Perfect when visibility depends on simple, static conditions (e.g., subtype or location).
  • Commands appear instantly in UI elements (e.g., action bars).

Cons:

  • Heavy logic (DB queries, workflow checks) runs once per node → can slow down navigation.
  • Not suitable for dynamic or complex conditions.

Real-World Example

You want an “Approve Document” command available for all documents. Since visibility depends only on subtype, place your script under Overrides > S144.

Users can even bulk-select multiple documents and approve them at once — with no performance issues.

Key Takeaway

Overrides are your best choice when:

  • Visibility rules are static (subtype, folder, hierarchy).
  • Bulk actions are required.
  • You can keep logic lightweight.

For dynamic or complex conditions, though, Overrides may create performance bottlenecks. That’s where Actions come in — and we’ll cover those in the second article of this topic. Stay tuned!

Button Text

Continue reading

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse var

Part 2 - Understanding Actions and the “Lazy-Loading” Approach

Contact us

Suggested articles

See all
Button Text

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

In Part 1 we looked at Overrides, the eager model that runs checks on every node at page load. They’re great for simple, static rules and bulk actions, but heavy logic can hurt performance. Actions take the opposite, lazy-loading approach, running only when a user opens a node’s context menu. Let's explore how Actions work, when to use them, and their trade-offs.

Button Text

AI-enhanced video transcript and task automation system

At AnswerConsulting, we tackle the everyday chaos of unstructured meetings. Insights get lost, minutes are manual, and follow-ups often fall through. Our solution — built on OpenText Content Management with Module Suite — brings structure back, turning talk into transcript — and transcript into actionable knowledge. Powered by speech-to-text and LLMs (we're agnostic to your setup), it goes beyond minutes: capturing sentiment, tasks, and speaker dynamics.

Button Text

Extending OpenText Content Management APIs with Module Suite

OpenText standard APIs provide a solid foundation for system integration. Module Suite APIs complement them by simplifying complex logic, improving resilience, and reducing maintenance. Together, they enable faster projects, smoother migrations, and lower total cost of ownership. Learn how combining both approaches delivers more effective, future-proof integrations.