Skip to main content
RapidDev - Software Development Agency
outsystems-tutorial

Site Properties and Environment Configuration in OutSystems

Site Properties in O11 are server-side key-value configuration values created in the Data tab. You set default values in Service Studio and override them per environment in Service Center without redeploying. In ODC, Site Properties become Settings (non-sensitive) or Secret Settings (encrypted, for API keys). Read Site Properties in Server Actions only — they are not accessible from Client Actions.

What you'll learn

  • How to create and read Site Properties in O11 for server-side configuration
  • Overriding Site Property values per environment in Service Center without redeploying
  • The difference between Site Properties (server-side) and Client Variables (client-side)
  • Using Site Properties for feature toggles and third-party API base URLs
  • How Site Properties map to Settings and Secret Settings in ODC
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Beginner8 min read20-25 minOutSystems 11 and ODCMarch 2026RapidDev Engineering Team
TL;DR

Site Properties in O11 are server-side key-value configuration values created in the Data tab. You set default values in Service Studio and override them per environment in Service Center without redeploying. In ODC, Site Properties become Settings (non-sensitive) or Secret Settings (encrypted, for API keys). Read Site Properties in Server Actions only — they are not accessible from Client Actions.

Site Properties and Environment Configuration

Every real OutSystems application needs configuration values that differ between Development, QA, and Production: API base URLs, feature flags, batch sizes, timeout values. Hard-coding these creates deployment headaches. Site Properties are OutSystems' answer — they are named server-side variables that you set once in Service Studio, then override per environment in Service Center without touching code. This tutorial covers creation, reading, and the important ODC differences.

Prerequisites

  • Service Studio connected to an O11 environment (or ODC Studio for the ODC section)
  • Access to Service Center (environment URL + /ServiceCenter) with at least Change & Deploy permission
  • A Reactive Web App with at least one Server Action

Step-by-step guide

1

Create a Site Property in the Data tab

In Service Studio, click the Data tab (right panel). Expand the tree to find Site Properties. Right-click Site Properties → 'Add Site Property'. Set the following in the Properties Panel: - Name: PaymentAPIBaseURL - Data Type: Text - Default Value: 'https://api-staging.payments.example.com' - Description: 'Base URL for the payment gateway API. Override per environment.' - Is Secret: No (leave unchecked for non-sensitive values; check for passwords/API keys) Create a second Site Property for a feature toggle: - Name: EnableNewCheckout - Data Type: Boolean - Default Value: False - Description: 'Set to True to enable the redesigned checkout flow' TrueChange validates Site Property definitions immediately.

Expected result: Two Site Properties appear in Data tab → Site Properties: PaymentAPIBaseURL (Text) and EnableNewCheckout (Boolean).

2

Read a Site Property in a Server Action

Site Properties are accessible only from Server Actions (and Data Actions). They cannot be read from Client Actions. Open any Server Action in the Action Flow Editor. To reference a Site Property in an expression, type its name with the Site. prefix: Site.PaymentAPIBaseURL Site.EnableNewCheckout Example: in a Server Action that calls the payment API, set the base URL dynamically: Start → Assign: RequestURL = Site.PaymentAPIBaseURL + '/v2/charge' → HTTP call node → End For the feature toggle: Start → If: Site.EnableNewCheckout → [True] → navigate to new checkout → [False] → navigate to old checkout → End In the Action Flow Editor, drag an Assign node from the Toolbox. In the Assign properties, click '+' → Variable = RequestURL (Text), Value = Site.PaymentAPIBaseURL + '/v2/charge'.

typescript
1/* Assign node values using Site Properties */
2RequestURL = Site.PaymentAPIBaseURL + "/v2/charge"
3UseBatchSize = Site.ProcessingBatchSize
4
5/* Feature toggle If condition */
6Site.EnableNewCheckout
7
8/* Composite expression */
9"Max batch size: " + IntegerToText(Site.ProcessingBatchSize)

Expected result: The Server Action compiles with no TrueChange errors. At runtime it reads the Site Property value configured for that environment.

3

Override Site Property values per environment in Service Center

After publishing your module, navigate to Service Center (your-environment-url/ServiceCenter). Log in with administrator credentials. Path: Factory → Modules → search for your module → click it → click the Site Properties tab. You see a list of all Site Properties with their current effective value and the default value set in Service Studio. Click the Edit (pencil) icon next to PaymentAPIBaseURL. Change the value to 'https://api.payments.example.com' (the live production URL) → Save. The change takes effect immediately — no redeployment needed. This is the key benefit of Site Properties: operations teams can toggle features and update configuration without involving developers. Repeat for each environment (Dev Service Center, QA Service Center, Prod Service Center) with appropriate values.

Expected result: PaymentAPIBaseURL now shows the production URL in the Prod environment Service Center. The next server request reads the new value without any code change or redeployment.

4

Use Client Variables for client-side persistent configuration

Client Variables are the client-side equivalent of Site Properties — they persist across screen navigation within a session (stored in browser localStorage). Create: Data tab → Client Variables → right-click → Add Client Variable. - Name: UserPreferredLanguage - Data Type: Text - Default Value: 'en' Read and write from Client Actions (not Server Actions): - Read: ClientVariables.UserPreferredLanguage (in any expression within a Client Action) - Write: Assign node → ClientVariables.UserPreferredLanguage = 'fr' Differences from Site Properties: - Client Variables are per-user/browser (not global like Site Properties) - They persist across screen navigation but are cleared when the user clears browser storage - They are NOT accessible in Server Actions - Never store sensitive data (passwords, tokens) in Client Variables — localStorage is readable by JavaScript

typescript
1/* Reading Client Variable in a Client Action */
2If: ClientVariables.UserPreferredLanguage = "fr"
3 [True] --> navigate to French content
4
5/* Writing Client Variable */
6Assign: ClientVariables.UserPreferredLanguage = SelectedLanguage
7
8/* NEVER do this - security risk: */
9Assign: ClientVariables.AuthToken = ServerAction.BearerToken /* WRONG */

Expected result: UserPreferredLanguage persists as the user navigates between screens. Refreshing the browser or returning in a new tab retains the value from localStorage.

5

Migrate to ODC Settings and Secret Settings

In ODC, Site Properties are replaced by two new concepts in ODC Portal: **Settings** (equivalent to non-sensitive Site Properties): - Created in ODC Studio: Data tab → Settings → right-click → Add Setting - Read in Server Actions: Settings.PaymentAPIBaseURL (same syntax) - Override per stage (Development, Test, Production) in ODC Portal → Apps → [Your App] → Settings tab **Secret Settings** (equivalent to Is Secret Site Properties): - Created in ODC Studio: Data tab → Settings → right-click → Add Secret Setting - Encrypted at rest, never exposed in logs or UI - Managed in ODC Portal → Apps → [Your App] → Secrets tab - Access: Settings.PaymentAPIKey (same syntax as Settings) Key difference: In O11, Is Secret Site Properties are masked in Service Center but not encrypted at rest. In ODC, Secret Settings are fully encrypted using AWS Secrets Manager.

Expected result: ODC app reads PaymentAPIBaseURL from Settings and PaymentAPIKey from Secret Settings, with values configured per stage in ODC Portal.

Complete working example

SiteProperties_usage_examples.txt
1/* ============================================================
2 SITE PROPERTIES (Data tab Site Properties)
3 ============================================================
4 Name: PaymentAPIBaseURL | Type: Text | Default: https://api-staging.payments.example.com
5 Name: EnableNewCheckout | Type: Boolean | Default: False
6 Name: ProcessingBatchSize| Type: Integer | Default: 100
7 Name: AdminEmailAddress | Type: Text | Is Secret: Yes
8 ============================================================ */
9
10/* SERVER ACTION: ProcessPayment */
11Start
12 --> If: not Site.EnableNewCheckout
13 [True] --> Raise Exception: FeatureDisabled
14 Message = "Payment feature is currently disabled."
15 --> Assign:
16 RequestURL = Site.PaymentAPIBaseURL + "/v2/charge"
17 BatchSize = Site.ProcessingBatchSize
18 --> HTTP Request: URL=RequestURL, Headers=[Authorization: Bearer + Site.PaymentAPIKey]
19 --> End
20
21/* CLIENT ACTION: LoadUserPreferences */
22Start
23 --> If: ClientVariables.UserPreferredLanguage = ""
24 [True] --> Assign: ClientVariables.UserPreferredLanguage = "en"
25 --> Assign: CurrentLanguage = ClientVariables.UserPreferredLanguage
26 --> End
27
28/* SERVICE CENTER PATH TO OVERRIDE:
29 Service Center Factory Modules [ModuleName] Site Properties tab
30 Click pencil icon change value Save
31 No redeployment needed.
32
33 ODC PORTAL PATH:
34 ODC Portal Apps [AppName] Settings tab (or Secrets tab for secret settings)
35*/

Common mistakes

Why it's a problem: Trying to reference Site. properties in a Client Action

How to avoid: TrueChange will show a red error: 'Site Properties are not available in Client Actions.' Move the Site Property read to a Server Action and pass the value as an output parameter to the Client Action.

Why it's a problem: Storing API keys in a Text Site Property without Is Secret = Yes

How to avoid: Non-secret Site Properties are visible in plain text to anyone with Service Center access. Enable Is Secret for any credential or API key. In ODC, use Secret Settings which are encrypted with AWS Secrets Manager.

Why it's a problem: Using Client Variables to store authentication tokens or user roles

How to avoid: Client Variables are stored in browser localStorage and are readable by any JavaScript running on the page. Never store security-sensitive data in Client Variables. Use server-side session checks and pass roles via Server Action output parameters.

Why it's a problem: Confusing Client Variables (persistent, per-browser) with Local Variables (lost on navigation)

How to avoid: Local Variables exist only for the lifetime of the current screen. Client Variables persist across navigation within the browser session (localStorage). Use Local Variables for temporary form state, Client Variables for user preferences that should survive navigation.

Best practices

  • Never hard-code environment-specific values (URLs, API keys, toggle flags) in action logic — always use Site Properties so they can be changed without redeployment.
  • Mark sensitive values (passwords, API keys, connection strings) as Is Secret in O11 so they are masked in Service Center. Use Secret Settings in ODC for full encryption.
  • Always fill in the Description field on Site Properties — it is your operations team's only documentation when changing production values.
  • Use Boolean Site Properties for feature toggles (EnableNewCheckout = True/False) rather than Text 'true'/'false' — Boolean type is type-safe and avoids case-sensitive comparison bugs.
  • Never read Site Properties from Client Actions — they are server-side only. If you need a Site Property value on the client, return it as a Server Action output parameter.
  • Keep a documentation record of all Site Properties and their expected values per environment — the Service Center UI shows current values but not the history of changes.

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

ChatGPT Prompt

Explain OutSystems Site Properties. How do I create them in the Data tab, reference them in Server Actions using the Site. prefix, and override their values per environment in Service Center without redeploying? Also explain how this differs from Client Variables and how Site Properties map to Settings and Secret Settings in ODC.

OutSystems Prompt

Add environment configuration to my OutSystems module using Site Properties. Create: (1) PaymentAPIBaseURL (Text, default 'https://api-staging.payments.example.com'), (2) EnableNewCheckout (Boolean, default False), (3) ProcessingBatchSize (Integer, default 100). Show me how to read Site.PaymentAPIBaseURL and Site.EnableNewCheckout in a Server Action using the correct expression syntax.

Frequently asked questions

When does a Site Property value change take effect in Service Center?

Immediately. Site Property changes in Service Center take effect on the very next server request — no redeployment, restart, or cache clear is needed. This makes them ideal for feature toggles and emergency configuration changes in production.

Can I read a Site Property value in a Screen Aggregate filter?

Yes. Aggregates run server-side, so you can reference Site. properties directly in filter expressions. For example: Employee.DepartmentId = Site.DefaultDepartmentId. This is a common pattern for multi-tenant apps where the default values differ per environment.

What is the difference between Site Properties and Session Variables in O11?

Site Properties are global server-side values shared by all users and all sessions. Session Variables are per-user server-side values that exist for the duration of one user session (O11 Traditional Web only — not available in Reactive or ODC). Use Site Properties for global config, use Client Variables (localStorage) for per-user client-side state in Reactive apps.

Can multiple modules share the same Site Property value?

No — Site Properties are module-scoped in O11. If two modules need the same value, create the property in one module (typically a Foundation layer module) and expose it via a Server Action (as a Function that returns the value) or Service Action for other modules to consume. In ODC, Settings are app-scoped similarly.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Need help with your project?

Our experts have built 600+ apps and can accelerate your development. Book a free consultation — no strings attached.

Book a free consultation

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.