Skip to Content (Press Enter)
How is your experience with the OutSystems Community?
2026-02-20 07-01-51
SANG BUI VAN
13Views
3Comments
Solved
Best Practice for Passing Runtime Context Across Multiple Server Actions
Question
Architecture
Best Practices
Logic
Development

I'm coming from a C#/.NET background and trying to understand what the equivalent pattern would be in OutSystems. In C#, it's common to keep shared runtime data inside an object



The runtime context is stored once and all methods can access it without passing the same parameters repeatedly.

In OutSystems 11 & ODC, when implementing a business process with multiple nested Server Actions, I often find myself passing the same inputs through several layers of actions:

like
`

CustomerId

IsPriorityOrder

CountryCode

ExecutionMode

`

 I've considered using Site Properties. However, Site Properties seem intended for configuration values that don't change often, not for runtime context or temporary execution state.

How do experienced OutSystems developers typically handle this scenario in larger applications? 

  • Do you simply pass parameters through the call chain?
  • Do you use a Context Structure? 
  • Something else?

At what point does parameter propagation become a design smell in OutSystems? 

Thanks! 🚀

0
0
23 Oct
Copy Link
2024-10-12 12-11-20
Kerollos Adel
Champion
Solution

Hi @SANG BUI VAN

I think the safest approach would be to use a shared Structure, but we should first review the architecture and existing references to understand the impact of this change. Since the Structure is shared, updating it in one place could trigger refreshes across all the dependent modules and potentially require additional adjustments.

Another option is to pass the parameters individually, which is straightforward and explicit, but it could become cumbersome if there are too many parameters.

So, I’d recommend reviewing the existing dependencies first, then deciding which approach would be the least disruptive and easiest to maintain.

See solution in context
1
0
24 Oct
Copy Link
2026-02-20 07-01-51
SANG BUI VAN

Thanks for your insights! I agree that using a shared Structure is a reasonable approach.

I also think the depth of nested Server Actions and repeated parameter propagation could be considered in an architecture best-practice checklist, perhaps with a recommended maximum nesting depth for a business process flow.

0
0
25 Oct
Copy Link
2024-01-31 05-29-41
Akshay Deshpande

Hi,

For this scenario, I recommend using a Structure (e.g., OrderContext) to group related runtime values such as CustomerId, IsPriorityOrder, CountryCode, and ExecutionMode.

Pass this Structure as a single input parameter to the Server Actions that need the context.

  • Maintainability: Adding a new field is easier than modifying multiple action signatures.

  • Reusability: The same Structure can be used across multiple actions.

  • Performance: Don't expect a measurable performance improvement just from using a Structure.

Note that OutSystems doesn't automatically share local variables between Server Actions. You still need to pass the Structure explicitly.

Avoid Site Properties for request-specific runtime data; they are intended for configuration.

References:

1
0
23 Oct
Copy Link
2024-10-12 12-11-20
Kerollos Adel
Champion
Solution

Hi @SANG BUI VAN

I think the safest approach would be to use a shared Structure, but we should first review the architecture and existing references to understand the impact of this change. Since the Structure is shared, updating it in one place could trigger refreshes across all the dependent modules and potentially require additional adjustments.

Another option is to pass the parameters individually, which is straightforward and explicit, but it could become cumbersome if there are too many parameters.

So, I’d recommend reviewing the existing dependencies first, then deciding which approach would be the least disruptive and easiest to maintain.

1
0
24 Oct
Copy Link
2026-02-20 07-01-51
SANG BUI VAN

Thanks for your insights! I agree that using a shared Structure is a reasonable approach.

I also think the depth of nested Server Actions and repeated parameter propagation could be considered in an architecture best-practice checklist, perhaps with a recommended maximum nesting depth for a business process flow.

0
0
25 Oct
Copy Link
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.