Using “Find Usages in All Modules” Effectively in OutSystems

Many large OutSystems O11 applications are still actively used and maintained, often within a DevOps operating model. In these environments, developers frequently work on applications originally built by other teams. As a result, refactoring and impact analysis are common activities.

Entities are typically defined in a Core Services (CS) module and reused across multiple Business Logic (BL) and End User and other modules.

During maintenance or refactoring, the “Find Usages in All Modules” feature is an essential tool for performing impact analysis — especially when determining where an Entity Attribute is being set or updated.

However, not all implementations are detected by this functionality.

This article demonstrates how different server action implementation patterns influence whether attribute usage is discovered by Find Usages, and how following OutSystems best practices improves maintainability and traceability.

Example Setup

For this example, the Order and Orderline Entities are defined in the Order_CS module, where the public CRUD server actions are generated.

The Orderline Entity contains a PriorityId attribute. An Orderline may receive a priority during creation, but the priority can also be adjusted later as part of the order processing flow.

Press enter or click to view image in full size

Assume there is an issue with an Orderline that has an unexpected Low priority. The developer needs to determine where and when the PriorityId was assigned.

The first step is to use “Find Usages in All Modules” on the PriorityId attribute.

Press enter or click to view image in full size

Priority Logic in the Business Logic Layer

In the Order_BL module, in this example, three server actions are related to priority handling:

• GetPriority — determines the priority for an Orderline and returns a PriorityId
• UpdateOrderLinePriority (Assign-based)
• UpdateOrderLinePriority (Expanded-record-based)

Both update server actions perform the same functional steps:

1. Determine the priority
2. Update the Orderline record

In real-world applications, this logic would typically be consolidated into a single server action. For this example, the separation is intentional to highlight the impact of different implementation approaches.

Implementation Patterns

Pattern 1: Assign Before Update (Best Practice)

In the first server action, the Orderline record is populated using a dedicated Assign. The PriorityId attribute is explicitly set using the value returned by GetPriority, after which the record is passed to the Update server action.

This approach aligns with OutSystems best practices for:

• Readability
• Debugging
• Impact analysis

Press enter or click to view image in full size

Pattern 2: Expanded Record Parameter

In the second server action, the record parameter of the OrderlineUpdate server action is expanded.

All attribute values, including PriorityId, are passed individually, with PriorityId being set directly from GetPriority.

Although functionally correct, this pattern has important drawbacks from a maintainability and traceability perspective.

Press enter or click to view image in full size

Impact on “Find Usages in All Modules”

When searching for usages of the PriorityId attribute:

✅ The Assign-based implementation is found

❌ The expanded record parameter implementation is not found

This means that attribute assignments performed via expanded record parameters are invisible to Find Usages, reducing the reliability of impact analysis.

OutSystems Best-Practice Conclusion

From a maintainability and architecture standpoint, attributes should be assigned explicitly using Assign nodes, rather than being set implicitly through expanded record parameters.

This approach is recommended because it:

• Ensures attribute assignments are detected by “Find Usages in All Modules”
• Improves readability by clearly showing which attributes are being set
• Simplifies debugging by allowing inspection of the fully populated record before persistence
• Enables inline documentation using comments next to Assign nodes
• Supports clearer separation of responsibilities within server actions

In scenarios where a record does not yet exist and all attributes are provided via an expanded parameter; the recommended approach is to:

1. Create a local variable of the record type
2. Populate it using Assign nodes
3. Pass the local variable to the Update server action

Although this introduces a minimal memory overhead, it significantly improves code clarity, traceability, and long-term maintainability — key principles in OutSystems architecture best practices.