Hi @Joel Ferrer de Mello ,
I will suggest you place the structure in a Core Service Module since it will be shared across multiple modules (Financial, End User Services, Internal User Services). This ensures reusability, consistency, scalability, and separation of concerns, making it easier to maintain and update without redundancy. By keeping it in a core module and exposing it as a public structure, other modules can use it efficiently without duplication. 

Thanks

Hey @Joel Ferrer de Mello ,

In addition to @ABHIJITH G 's response, you can check best practices regarding Outsystems and its architecture: Here & Here .

Hi @Joel Ferrer de Mello 

Given that your Output Structure (Id, Success, Message) seems to be a generic response type used across multiple modules , the Core Service Module would likely be the most appropriate place to define it. This ensures that it’s consistently available for all other modules, and any changes to it are centralized, making your application more maintainable. 

Regards ,
Rajat

@Joel Ferrer de Mello As above comments suggest core server module correct, i want to add one more Point to that which come under the best practices of outsystems, if that structure, server action or any other public elements which are use in different modules and at the same used in different application then create a separate application which acts a core layer application.

thank you.

Thanks Rajat Agrawal, Mihai Melencu and ABHIJITH G .

It's great to be able to count on you.

Hi @Joel Ferrer de Mello ,

I recommend placing the structure in a Core Service Module since it will be shared across multiple modules (Financial, End User Services, and Internal User Services). This approach ensures reusability, consistency, scalability, and separation of concerns, making maintenance and updates more efficient while avoiding redundancy.

By keeping it in a Core Service Module and exposing it as a public structure, other modules can utilize it efficiently without duplication.

Let me know if you need any further clarification.

Hi Joel,

Even tough multiple replies, with basically the same response are marked as solution, I think there are two options and it depends on the purpose and usage of the public structure:

Use a Foundation Module if:

• The structure is generic and reusable across multiple applications.
• It does not depend on business logic or specific service implementations.
• You want to improve modularity and reduce dependencies on core service modules.

Use a Core Service Module if:

• The structure is closely tied to a business service (e.g., a structure representing a database entity or API response specific to a service).
• It needs to be modified alongside other service logic.
• It is only relevant within the scope of that service.

My recommendation is that if the structure is meant to be shared across multiple modules and applications, put it in a Foundation Module. If it is tightly coupled to a specific business service, place it in a Core Service Module.

In your case, I don't think the structure is closely tied to a business service, so I would have chosen a Foundation Module.

Regards,

Daniel