espocrm-development

Business logic in EspoCRM must reside in Service classes, not in hooks or controllers. Services handle domain operations, EntityManager manages all data access, and dependency injection wires components together. This separation keeps your code testable and maintainable across custom modules and integrations.

Always use EntityManager for all data access operations in EspoCRM. Never bypass it with direct database queries or Container access. EntityManager enforces metadata consistency, handles relationships correctly, and integrates with the ORM layer—essential for custom entities, relationships, and lifecycle hooks.

EspoCRM uses metadata-driven configuration to define entities, relationships, and service behaviors. Rebuilding cache after metadata changes ensures the framework reflects your new structure in all components. Skip this step and your custom entities, fields, or API endpoints won't recognize the updates.

Hooks should delegate business logic to Service classes rather than contain it directly. Use dependency injection to access Services from hooks, and let Services call EntityManager for data operations. This pattern keeps hooks thin and preserves the service-layer architecture across custom modules.

No—direct Container usage violates EspoCRM's dependency injection pattern. Inject only the specific services your code needs. This prevents tight coupling, makes testing easier, and ensures your custom modules integrate cleanly with the metadata-driven framework.

Start with the architecture documentation and understand the metadata-driven design. Create Service classes for business logic, use EntityManager for data access, and expose APIs through controllers that delegate to Services. This foundation applies to integrations, custom modules, relationships, and lifecycle event handling.