There is no single “correct” default. The right choice depends on what you are optimizing for at each layer, security, predictability, or speed of development. Choosing the wrong default in the wrong place can either slow teams down or introduce subtle, hard-to-detect risks.

In this post, I’ll try explore the reasoning behind default-allow and default-deny, and explain when and where, each design pattern makes the most sense.

👌Default-Allow (Allow-by-Default)

Definition

If no rule exists, access or behavior is granted.

“Unless something explicitly says no, it’s allowed.”

Characteristics

• Default state = true

• Rules exist mainly to restrict

• Absence of data = allow

Example

Access control

• No rule found → user can access the page

• Rule found with IsAllowed = false → access blocked

Form fields

• All fields are editable by default

• Only specific fields are set to read-only

Why Default-Allow Optimizes for Speed

1. Fewer decisions upfront

You create a new screen:

• No access rule yet

• No role mapping

• No capability defined

The screen is immediately accessible, allowing development and testing to continue without blockers.

2. Smaller rule sets = faster change

Rules only describe exceptions.

Example:

• Block admin screen for non-admins (1 rule)

Versus deny-by-default:

• Allow admin screen for admins

• Allow reports for analysts

• Allow dashboard for managers

  (many rules)

This reduces configuration overhead and speeds up iteration.

Trade-Offs (Important)

The same qualities that make default-allow fast also make it risky at scale:

• Missing rules

• Implicit behavior

• Assumptions instead of guarantees

Used carelessly, this can lead to silent security bugs.

🫷Default-Deny (Deny-by-Default)

Definition

If no rule exists, access or behavior is denied.

“Unless something explicitly says yes, it’s denied.”

Characteristics

• Default state = false

• Rules exist mainly to grant

• Absence of data = deny

Example

Access control

• No rule found → user cannot access the page

• Rule found with IsAllowed = true → access granted

Form fields

• All fields are read-only by default

• Only specific fields are enabled

Why Default-Deny Optimizes for Certainty

1. Explicit permission = predictable behavior

Every allowed action is intentional and traceable to a rule.

No surprises, no accidental access.

2. Missing configuration is safe (fail-closed)

If something goes wrong:

• Rules not loaded

• API data missing

• New screen added without permissions

The result is safe:

• Access denied

• Fields disabled

• Buttons hidden

The system fails closed, not open.

3. Strong fit for security and authorization

Deny-by-default is foundational for:

• Access control

• Compliance systems

• Financial workflows

• Admin tools

One accidental “allow” can be catastrophic.

One accidental “deny” is usually recoverable.

4. Prevents permission drift

New features don’t automatically grant access.

Old roles don’t silently gain new power.

Silence does not grant authority.

Trade-Offs

Deny-by-default feels slower because it requires:

• More upfront work

• More configuration

• More rules

You pay a design tax early to avoid a security tax later.

🎖️ Best Practice

There is no single default that works everywhere. The key is to apply the right default per layer.

Recommended Mapping

• Security, services, and data boundaries → Deny-by-default
  (APIs, server actions, data mutations, approvals)
  If it touches data or authority, access must be explicitly granted.

• Navigation and page access → Deny-by-default
  Pages and flows should never be discoverable by accident.

• UI composition and visual behavior → Allow-by-default (controlled)
  Field visibility and layout rules benefit from faster iteration and fewer configurations.

• Field editability and business rules → Deny-by-default
  Viewing can be permissive, editing must be explicit.

The Hybrid Model (Recommended)

This keeps security predictable, UX flexible, and development fast.

Environment-Based Strategy (Optional)

• Development → Allow-by-default

• UAT → Mixed

• Production → Deny-by-default

This allows fast exploration early and strict control before release.

It often plays out like this:

1. The user wants to solve X.

2. They think doing Y will help.

3. They don’t know how to do Y, so they ask for help with Y.

4. Others help with Y, but Y turns out irrelevant or inefficient.

5. Time is wasted before anyone realizes the real goal was X all along.

The Developer’s Dilemma

In software projects, users or even product managers acting on their behalf often describe what they want built rather than what they need solved.

• X = the real problem (the why)

• Y = the proposed solution (the what)

Example

Users had a problem: they needed to find and correct failed sync records in a table that also contained successful ones. The real issue (X) was quickly identifying failed records for correction, but users proposed a solution (Y):

“Can you add checkboxes so we can select and fix the failed ones?”

The developer built the checkbox feature, but it didn’t help much. Users still had to go through every record manually and often missed some.

Then the developer asked:

“Why do you need checkboxes?” “So we can correct the failed records,” the user said.

That simple question revealed the real need. Instead of checkboxes, the developer added a filter for ‘Failed’ records and an Excel export option, allowing users to easily find and correct the failed data outside the system.

Result: The process became faster, cleaner, and solved the real problem — not just the requested one.

Active Listening Matters

Developers shouldn’t just build what’s asked, they should listen actively. That means asking “why,” understanding context, and challenging assumptions.

The developer who only hears “add checkboxes” builds a limited feature. The developer who asks “why” builds a better product.

Users Aren’t Product Designers

Users are experts in their own needs and frustrations, but they’re not experts in software design or technical trade-offs. Their proposed solution (Y) is often the most obvious one they can think of, not necessarily the most efficient or scalable.

A developer’s expertise is to uncover the real problem (X) and design the best solution for it.

How to Avoid the XY Problem

1. Ask “Why?” empathetically. Uncover the motivation behind every request.

2. Focus on goals, not features. Talk about outcomes, not UI elements.

3. Separate problems from solutions. Capture both during discussions.

4. Prototype to validate. Test ideas early to confirm real needs.

Closing

The XY problem highlights why listening to users is so tricky for developers. It reveals the gap between what users ask for and what they actually need.

Developers who focus only on the “what” risk building the wrong thing. Those who seek the “why” create meaningful, effective solutions.

But this raises a critical challenge: how do we keep communication secure when multiple users are involved? If a single key is shared among many users, it becomes a security risk. On the other hand, if each user has their own key, how can they all still access the same protected message without weakening security?

The answer lies in combining two powerful algorithms: AES (Advanced Encryption Standard) and RSA (Rivest–Shamir–Adleman).

Why Combine AES and RSA?

AES and RSA are two of the most widely used algorithms in modern cryptography, but they serve very different purposes:

• AES is extremely fast and efficient for encrypting large amounts of data.

• RSA is slower, but excellent for securely sharing keys and providing authentication.

By using them together, we get the best of both worlds: AES protects the data, while RSA ensures that the AES key itself is distributed safely.

AES is a symmetric algorithm, meaning the same key is used for both encryption and decryption.

• Strengths: Very fast, suitable for encrypting files, databases, or network traffic.

• Challenge: The key must be shared securely—if it’s leaked, the entire system is compromised.

RSA is an asymmetric algorithm, meaning it uses a key pair: one public and one private.

• Strengths: Ideal for exchanging secrets like AES keys, and for authentication through digital signatures.

• Challenge: Computationally heavy and not efficient for encrypting large datasets directly.

How the Hybrid Approach Works

The process of combining AES and RSA can be broken into two main parts: key establishment and message exchange.

1. Generate AES Secret Key
   A random AES key is created. This will be used to encrypt the actual data.

2. Generate RSA Key Pair
   Each recipient generates an RSA public/private key pair.

3. Encrypt AES Secret Key with RSA Public Key
   The AES key is encrypted using the recipient’s RSA public key.

   1. Distribute Encrypted AES Keys
      The encrypted AES key (different for each recipient, since it’s encrypted with their unique public key) is distributed securely.

4. Encrypt Data with AES Key
   The sender encrypts the plaintext message with the AES key, producing ciphertext.

5. Recipient Decrypts AES Key with RSA Private Key
   Each recipient uses their private RSA key to decrypt the AES key sent to them.

6. Recipient Decrypts Data with AES Key
   Finally, the recipient uses the recovered AES key to decrypt the ciphertext and obtain the original plaintext.

Why This Matters

• Security: RSA secures key distribution; AES secures the data itself.

• Efficiency: AES handles the heavy work of encrypting large volumes of data, while RSA is only used for small key exchanges.

• Scalability: Each recipient can use their own RSA key pair to securely receive the same AES key, enabling secure communication across many users.

Conclusion

AES and RSA aren’t rivals, they’re partners. AES delivers the speed to encrypt massive amounts of data, while RSA ensures the keys are shared securely and with trust. Together, they form the backbone of modern encryption, balancing performance with security in a way that has stood the test of time.

I might dive deeper in a future post to explore how this hybrid approach implemented spesifically with OutSystems, stay tune.

After running into this issue multiple times, I discovered a more efficient approach: storing structured JSON inside a single Site Property. This simple shift offers big benefits: cleaner configuration management, fewer properties to track, easier updates, and better grouping of related values.

Interestingly, there are 58+ community-submitted ideas related to improving Site Property management in OutSystems,ranging from versioning and logging to value grouping and description support. Clearly, this is a pain point many developers face.

The Problem with Site Properties Today

Here’s why the default Site Property approach starts to break down at scale:

1. No Organization – There's no native way to sort or group properties, making it hard to find related items.

2. Poor Grouping – Related values (like for a single feature) are scattered, not logically grouped.

3. Hard to Maintain – As more properties get added, understanding their purpose becomes harder.

4. No Logging – There’s no built-in history or change log for Site Property values.

5. Polluted Configuration Space – Single-use keys or temporary values add noise to the list. Too many for simple needs.

Why JSON?

Using JSON in a Site Property transforms the way you manage app settings. Here’s why:

Key Benefits

1. Fewer Site Properties – Group multiple values under one JSON property.

2. Logical Grouping – Keep related settings together, e.g., API configs or feature toggles.

3. Dynamic Parsing – Deserialize only what you need, when you need it.

4. Flexible & Scalable – Easily add or remove keys.

5. Simplified Versioning – Manage config as one JSON blob, easier to track changes.

The two most impactful benefits are:

• Having multiple values within a single Site Property

• Allowing additional attributes per config item (like descriptions or types)

How to Set Up JSON as a Site Property

Step 1: Create the Site Property

1. Create a new Site Property (e.g., EnvironmentVariables)

2. Set its data type to Text

3. Leave the default value blank (to avoid escaping characters in JSON)

Step 2: Define Your JSON Structure

You can define a structure two ways:

• Manually:

  Go to Data > Structures and create a new structure with attributes like Name, Value, and Description.

• From JSON:

  Create your JSON first in an editor, then in Service Studio:

  Right-click Structures > Add Structure from JSON

Example JSON:

[
  {
    "Name": "SiteProp1",
    "Description": "",
    "Value": ""
  },
  {
    "Name": "SiteProp2",
    "Description": "",
    "Value": ""
  }
]

Step 3: Use It in Logic

1. Create a server action (e.g., GetEnvironmentVariables)

2. Use JSONDeserialize to convert the JSON text to a list of structures

3. Return the result for use throughout your app

4. Optionally, expose this through a Service Action if you're in a service module

Tips

• Leave value blank in design time: this avoids escaping issues (like quotes)

• Use strings for booleans in JSON to simplify parsing

• Validate JSON before updating to avoid runtime errors

Going Further: Nested JSON for Advanced Use Cases

You can take this approach even further by using nested JSON. This enables parent-child relationships for more complex configuration scenarios.

Here’s an example from a feature I built called Quick Filtering, where saved search filters are bootstrapped from JSON:

{
  "QuickFilters": [
    {
      "Name": "Todays Report",
      "Group": "Report",
      "Description": "Open Today report",
      "Filters": [
        { "field": "Company", "operator": "equals", "value": "" },
        { "field": "DateFrom", "operator": "greaterThanOrEqual", "value": "Today" },
        { "field": "DateTo", "operator": "greaterThanOrEqual", "value": "Today" },
        { "field": "BankName", "operator": "equals", "value": "" }
      ]
    }
  ]
}

I’ll cover this nested use case in more detail in a follow-up post.

Caveats to Consider

Before adopting this approach, here are a few important considerations:

1. Parsing Overhead Every time you read the JSON, you must parse it. This introduces a slight performance cost, especially if done frequently.

2. Manual Editing Risks Updating JSON via Service Center can be error-prone. there’s no validation or syntax highlighting, so a small typo can break parsing.

3. Loss of Type Safety Unlike native Site Properties, JSON values are stored as plain text and require manual type conversion, which can lead to runtime errors if not handled carefully.

4. Character Limit Awareness OutSystems doesn’t show how many characters you're using in the Site Property value. You’ll need to monitor this manually to avoid silent cut-offs or broken JSON.

Summary

Switching to JSON-based Site Properties gives you a powerful way to streamline your configuration logic in OutSystems. It reduces clutter, adds flexibility, and makes your app easier to maintain over time,especially in large or fast-moving projects.

If you find yourself managing dozens of Site Properties with unclear names or single-use purposes, give this approach a try.

Why Handling Unused Dependencies Matter

Dead code refers to sections that are no longer executed or used. These remnants can stem from outdated features, experimental code, or debugging utilities. Over time, they bloat software, reduce efficiency, complicate maintenance, and increase the size of OutSystems modules—ultimately prolonging 1-Click Publish durations.

A Common Oversight

Often, developers leave behind temporary or "just-in-case" code, believing it may be useful later. In reality, these assumptions create unnecessary complexities, violating the YAGNI principle ("You Aren’t Gonna Need It"):

Key takeaway:
Only include what’s needed now, not what might be needed in the future.

Best Practices for Dependencies Avoid:

• Avoid : Large, bloated dependencies.

• Prefer : Smaller, specific modules with only the elements you actually use.

This aligns with the Interface Segregation Principle, where code depends only on relevant, smaller interfaces rather than massive, unwieldy packages.

Removing Unused Dependencies in OutSystems

OutSystems offers two key tools to address unused dependencies:

AI Mentor

Detects unused aggregates, SQL queries, and module actions. However, it doesn’t detect referenced elements without usage, so manual checks may still be required.

Service Studio’s "Remove Unused Dependencies" Feature

Automatically identifies and removes unused dependencies from your module.

Steps to Remove Unused Dependencies

1. Open Service Studio and navigate to each application layer (Interface, Logic, Data, Process).

   

2. Right-click the module name.

3. Select Remove Unused Dependencies.

4. Repeat for all layers.

By following these practices, you can simplify your modules, improve performance, and ensure clean, maintainable code. Don’t let unused dependencies weigh your application down!

This is a topic that keeps growing in importance as my experience deepens, and I thought I’d develop it into an article. Let’s explore what data concurrency is, why it matters, and how to handle it effectively.

What is Data Access Concurrency?

In essence, data access concurrency refers to situations where multiple processes or threads attempt to access or modify the same data simultaneously. If not managed properly, concurrency can lead to serious problems like data corruption or degraded performance, especially in systems designed for parallel operations (e.g., databases, multi-threaded applications, or cloud-based architectures like OutSystems).

Managing concurrency is crucial to ensuring data integrity, consistency, and optimal performance in these systems.

Concurrency Pitfalls: Race Conditions and Deadlocks

Before we dive into management strategies, let’s look at the conditions you want to avoid:

Race Conditions

A race condition occurs when two or more processes simultaneously access the same data, and the final result depends on the order of execution. The timing discrepancy can cause unpredictable behavior, leading to data corruption or inconsistencies.

Imagine two threads trying to update a shared record at the same time. If both execute simultaneously, they might overwrite each other's changes without realizing it, creating flawed data.

Deadlocks

A deadlock is another concurrency nightmare. It happens when two or more processes are stuck in a stalemate, each waiting for the other to release a resource (lock). This results in a system standstill, where none of the processes can proceed. In database environments, deadlocks can severely affect performance, forcing the system to abort transactions.

Using Locks to Manage Concurrency

To prevent race conditions and deadlocks, we use locks to control data access.

Locks are mechanisms that restrict access to shared resources, ensuring that only one process or thread can modify data at a time. When used correctly, they protect data integrity but must be managed carefully to avoid performance degradation or deadlocks.

Types of Locks:

• Read Locks (Shared Locks): Multiple threads can read data simultaneously, but no writing is allowed. This is useful when ensuring that read operations don’t interfere with each other.

• Write Locks (Exclusive Locks): Only one thread can write to the data, and no other operations (read or write) can access it until the lock is released.

Isolation Levels: Balancing Performance and Consistency

In database systems, isolation levels determine the visibility of changes made by one transaction to others. Different levels offer trade-offs between data consistency and performance, and selecting the right level can prevent issues like dirty reads, non-repeatable reads, or phantom reads.

Here are the common isolation levels:

• Read Uncommitted:

  • Transactions can see uncommitted changes from other transactions. This is the least strict level and offers the highest performance but at the cost of potential data inconsistencies.

• Read Committed:

  • Transactions can only see committed changes. This level is a good balance between performance and consistency, as it avoids reading uncommitted data.

• Repeatable Read:

  • Ensures that if a transaction reads data, it will see the same data throughout its execution. It protects against non-repeatable reads but can lead to performance bottlenecks in high-transaction environments.

• Serializable:

  • The strictest isolation level, ensuring full isolation by making transactions appear as though they were executed sequentially. It provides the highest level of consistency but can significantly impact performance in large systems.

Optimistic vs. Pessimistic Concurrency Control

Concurrency control can generally be classified into two approaches: Optimistic and Pessimistic. Each has its own use cases, depending on the likelihood of conflicts.

Optimistic Concurrency Control

In optimistic concurrency, conflicts are considered rare. Therefore, multiple transactions proceed without locking resources, and checks for conflicts are made only when changes are being committed. This approach works well in environments where transactions mostly don’t interfere with each other, offering better performance.

Pessimistic Concurrency Control

In pessimistic concurrency, we assume that conflicts are likely. As a result, locks are placed early in the process to prevent other transactions from accessing the same data. This approach is ideal in systems with high contention for resources, but it may introduce performance overhead due to frequent locking.

Why Concurrency Management Matters

Proper concurrency management ensures:

• Data Integrity: Preventing corruption by coordinating access to shared resources.

• Consistency: Ensuring transactions yield reliable outcomes, regardless of how they're interleaved.

• System Performance: Avoiding bottlenecks or crashes that can result from deadlocks or unnecessary locking.

In complex applications like those built on OutSystems, the performance impact of concurrency issues can scale rapidly. This makes it critical to design the data model and access layers with concurrency in mind, using the right balance of locking mechanisms, isolation levels, and concurrency control strategies.

Final Thoughts

The topic of data access concurrency is vast and continues to evolve as my understanding deepens through real-world experience. Managing concurrency isn't just about preventing conflicts—it's about finding the right trade-off between data integrity, performance, and scalability. Whether you’re working with a high-transactional system or a distributed architecture like OutSystems, mastering concurrency control can dramatically improve your application’s stability and responsiveness.

Stay tuned as I continue to expand on this topic in future posts, diving deeper into specific case studies and optimization techniques!

What is a Lottie Animation?

Lottie animations are a versatile, JSON-based animation format that allows for smooth, high-quality animations across platforms, from mobile apps to web applications. Initially developed by Airbnb, Lottie has gained widespread adoption due to its simplicity and flexibility. The biggest advantage? Lottie files are small and scalable, meaning they don’t lose quality when resized and are ideal for use in modern UI design.

Key Features of Lottie Animations:

• Multi-Platform Support: Lottie animations can be embedded into iOS, Android, and web applications with ease, using platform-specific libraries.

• Small File Size: Compared to GIFs or videos, Lottie animations are lightweight, resulting in faster load times and improved performance.

• Large Animation Library: LottieFiles, the leading resource for Lottie animations, offers thousands of free animations that can be used or customized.

• Customizable: The JSON format allows for easy editing of the animations to match your design needs, whether it’s color changes, speed adjustments, or other custom behaviors.

Getting Started with Lottie Animations in OutSystems

Before diving into the implementation, it's important to note that this tutorial is applicable to Reactive Web Applications in OutSystems. If you’re ready, let’s begin.

Step 1: Access and Download Lottie Animations

To integrate Lottie animations, the first step is to find and download an animation file in the correct format. Follow these steps:

1.1. Navigate to LottieFiles

Visit LottieFiles, where you can find a large library of free and premium animations. It’s a great place to start if you’re looking for professional animations ready to be used in your projects.

1.2. Download the JSON Animation File

• Once you find an animation that suits your project, click on it and choose the JSON format for downloading.

• 

• Save the file to a location on your local machine.

Step 2: Set Up in OutSystems Studio

Now that you have the animation file, you can begin integrating it into your OutSystems application.

2.1. Install the Lottie Animation Component from Forge

• Go to Forge: Open OutSystems Service Studio, navigate to the Forge tab, and search for Lottie Animation.

  Lottie Animation Forge Component

• 

• Install the Component: Once you’ve found the Lottie Animation component, install it into your environment.

• Manage Dependencies: After installation, navigate to Manage Dependencies within your application.

  • Search for the Lottie Animation component that you just installed.

  • Check all dependencies related to this component, and click Apply to include it in your project.

2.2. Set Up the Lottie Animation in Your Screen

Now, you’re ready to display the animation on your screen. Here’s how:

1. Upload the JSON File:

   • Go to the Data Tab and click on Resources.

   • Upload the Lottie JSON file you downloaded earlier into the resources section.

   • 

2. Add a Blank Container:

   • Drag a Blank Container onto the screen where you want to display the animation. This will serve as a wrapper for the Lottie Animation Block.

   • 

3. Insert the Lottie Animation Block:

   • Inside the Blank Container, drag and drop the Lottie Animation Block.

   • In the Lottie Animation Block’s properties panel, link the uploaded JSON file under the Animation Data property.

4. Configure the Animation:

   • You can customize the behavior of the animation by adjusting the autoplay or loop settings, depending on your needs.

   • To control the width and height of the animation, set these properties in the Blank Container rather than the Lottie Block itself, which allows for more flexibility in your layout.

5. Publish and Test:

   • Once you’ve set everything up, click Publish to deploy your application.

   • Navigate to the screen where you added the animation, and you should see it playing smoothly as part of your application.

   • 

Conclusion

Lottie animations are an excellent way to introduce visually engaging, responsive animations to your OutSystems application. With their small file sizes and multi-platform support, they are ideal for modern development workflows. By following this guide, you can easily integrate stunning animations into your reactive web applications, improving both user engagement and UI aesthetics.

Whether you’re building mobile or web apps, leveraging Lottie animations is a simple yet powerful tool to bring your user interfaces to life.

If you haven’t experimented with Lottie yet, now is the perfect time to explore its potential and elevate your applications to the next level!