You’re right to notice the apparent conflict:

• The documentation shows an example where App B directly consumes a Block (and its Client Variable) from App A. Share a Client Variable between apps
• Architecture best practices say: avoid side references between End‑User Apps; End‑User modules shouldn’t depend on each other, only on Core/Foundation modules. Reuse blocks between end-user modules

The doc example is intentionally simple to show how to share a Client Variable technically, not how to architect a real solution. For production systems, you should still follow the Architecture Canvas rules.

Recommended architecture pattern

1. Use a Core / CW module for the shared Client Variable

Instead of App A exposing a Block that App B consumes, create a separate Reactive UI module in the Core (CW) layer that:

1. Defines the Client Variable (or a set of them) in Client Variables.
2. Exposes a public Block (or public Client Actions) that read/write this variable.
3. Is consumed by all End‑User apps that need this data.

This way:

• There is no End‑User ↔ End‑User reference (no side reference).
• All End‑User apps depend “downwards” on a Core module, which is aligned with the Architecture Canvas. [[Re-Usable WebBlock collections place in architecture<>https://www.outsystems.com/forums/discussion/90625/passing-client-variables-between-modules/]] Reuse blocks between end-user modules

In practice:

• Create a Core UI module, e.g. MyProject_CW_SessionContext.
• Add Client Variables there (e.g. CurrentUserRole, TenantContext, etc.).
• Create Blocks / public Client Actions that:
  • Initialize the variables (e.g. on OnInitialize or via an InitializeContext action).
  • Provide a standard way for End‑User apps to read them (Expressions or Actions).

All consuming apps:

• Add a dependency to MyProject_CW_SessionContext.
• Use its Blocks or Client Actions whenever they need to access/update the shared client state.

Note: Even though the official doc example puts the Block in “App A”, you’re free (and encouraged) to put it in a Core module instead. The underlying mechanism is the same; only the layering differs.

When not to use shared Client Variables across apps

Before going to shared client state, consider whether you actually need to:

• If the data is server-side context (user profile, permissions, tenant, etc.), prefer:
  • Session Variables (Traditional) or
  • Server-side context tables accessed via Service Actions.
• If apps communicate mainly via URLs, consider query parameters or tokens instead of shared client state.

These approaches:

• Are more explicit and testable.
• Avoid complex client synchronization across multiple apps.
• Often have better maintainability than many shared Client Variables.

Answering your questions directly

What is the recommended architecture to share Client Variables between Reactive apps without bad side dependencies?

• Create a dedicated Core/CW Reactive module to host the shared Client Variables and the Block(s)/Client Actions that expose them.
• Have all End‑User apps reference this Core module, not each other.

Should the shared Block and Client Variable be in a Foundation/Core module?

• Yes. Place them in a Core (CW) module that:
  • Has no End‑User screens.
  • Only exposes reusable UI and client logic.
• This is the same pattern used for reusable Web Blocks collections and was validated in similar scenarios. [[Re-Usable WebBlock collections place in architecture<>https://www.outsystems.com/forums/discussion/90625/passing-client-variables-between-modules/]] Reuse blocks between end-user modules

If you describe what kind of data you’re sharing (user context, preferences, filters, etc.), I can suggest whether Client Variables in a Core module are the best fit or if a server-side pattern would be cleaner.