Hi @Youcef Mammar kouadri ,

You should implement validation on both the client and server side.

Filtering depends on the scenario. If you are filtering a small list that is already loaded on the screen, client-side filtering is perfectly fine. However, when filtering database records, it is generally better to apply the filters directly in the Aggregate or Data Action to avoid retrieving unnecessary data.

If a flow requires multiple server-side operations, for example creating two related resources, it is better to wrap that logic inside a single Server Action rather than making multiple server calls from a Client Action.

One common mistake for beginners is moving too much logic into Client Actions simply because it feels easier. Anything security-sensitive, business-critical, or affecting persistent data should ultimately be handled and validated on the server side.

Also try avoiding creating long flows, try isolating the actions as much as possible.

Hello.

VALIDATIONS

A simple rule I would like everyone to remember is:
-validations in the client action are to be fast (no server communication needed). You want them to be nice to the user experience.
-validation in the server action are to be safe. The user can't manipulate those.

so yes, some validations should be on both sides while others only in the server.

FILTERING

Depends on the size but if you have all the data in the client, don't go back to the server just to filter. Filter locally. (Unless the filter is based in some information you can't send to the client, but that would be rare).

UI RELATED

That will probably be client-side.

Hi @Youcef Mammar kouadri

As a general rule in OutSystems 11:

Client Actions = UI and interaction logic (runs in the browser/device)

Server Actions = Data access and business logic (runs on the server)

Use Client Actions for:

 Input validation and immediate user feedback
Showing/hiding widgets
Opening popups
Navigation between screens
Local calculations
Client Variables manipulation
Event handling (button clicks, input changes)

Examples:

Check whether an email field is empty

Enable/disable a Save button

Validate date formats before submission

Filter an already-loaded list on screen

Use Server Actions for:

 Database CRUD operations

 Business rules

 Integration with external systems/APIs

 Security-sensitive validations

 Data aggregation and processing

Examples:

Create or update Employee records

Check if Employee Number already exists

Calculate annual leave entitlement

Send data to ERP or HR systems

Fetch data from the database

Important Beginner Lesson: Validate Twice

A common mistake is putting all validation in a Client Action.

For example:

Client Action checks:

- Hire Date ≤ End Date

- Required fields completed

When Save is clicked:

- Call a Server Action

- Server Action performs the same critical validations before saving

Why?

Client-side logic can potentially be bypassed. Business-critical validations should always be enforced on the server before data is committed.

Hi @Youcef Mammar kouadri ,

Simple rule: if it needs the database or enforces a business rule, it's a Server Action. If it's just UI behavior or something you can safely do with data already in the browser, it's a Client Action.

So for your case:

• Client Action → field validation (empty, format), enabling/disabling buttons, showing/hiding sections, filtering a small list you already loaded, formatting inputs.
• Server Action → anything touching the DB (create/update/delete), checking duplicates, enforcing rules like "one manager per department," permission checks, calculations on sensitive data.

Basic flow: Client Action validates the easy stuff → calls a Server Action to do the real work → Server Action returns result → Client Action updates the screen.

Common mistakes beginners make:

• Only validating on the client (can be bypassed via REST, so also validate server-side).
• Calling a Server Action inside a loop — do it once with a list instead.
• Filtering/sorting big lists on the client — let the server do it with proper filters.
• Not handling exceptions in Server Actions, so users see raw errors instead of clean messages.

For your Employee Management app: keep name/email validation and UI toggles in Client Actions, and put employee creation, duplicate checks, and any department/manager rules in Server Actions.