How Systems Integrate

Business Systems in the Innopo Modular Systems Framework (IMSF) are designed to be independent and reusable, but they do not exist in isolation. To form a complete platform, systems must integrate with each other and with the shared application infrastructure in a predictable way.

This page explains how systems integrate at different layers: frontend, backend, data, configuration, and workflow. The goal is to make integration feel like composition rather than custom wiring.

Integration Principles

All systems follow a small set of integration principles so they can plug into any project without custom glue code for each one.

• Convention over configuration: Systems follow consistent naming, routing, and folder structures so the host application knows where to find things.
• Clear boundaries: Each system encapsulates its own UI, logic, and schema. Integration happens through defined entry points, not by editing the system internals.
• Non-invasive: Systems do not modify global state in unexpected ways. They consume shared services (e.g. auth, database) through defined interfaces.
• Composable: Multiple systems can coexist in the same project without conflicting with one another.
• Version-aware: The project always knows which version of each system it is integrating.

Frontend Integration

On the frontend, systems integrate into the project’s existing layout and routing structure. Each system exposes its own pages and components, which are mounted within the project’s UI shell.

How frontend integration works:

• Systems provide pages or route segments that can be registered in the host app’s routing tree (for example, under a /appor /dashboard layout).
• Components inside a system are built using the same base UI library (e.g. shadcn), so they visually match the rest of the platform.
• Systems expect a shared layout shell (navigation, header, content area) and render their content inside that structure.
• Systems can expose reusable components (for example, widgets, panels, or forms) that the project can place in different contexts.

From a user’s perspective, the platform feels cohesive, even though multiple systems are providing functionality behind the scenes.

Backend Integration

On the backend, systems integrate by registering their server actions, APIs, and services into the project’s runtime. Each system manages its own logic but uses shared infrastructure such as the database client, authentication, and configuration utilities.

How backend integration works:

• Systems expose server actions or route handlers for operations like creating records, processing workflows, or triggering automations.
• These backend functions receive requests in a consistent format and use shared services (for example, a common database client).
• Systems do not directly call each other’s internal functions. If a system needs data from another system, it does so via the shared data layer (for example, reading from tables defined by that system’s schema).
• Side effects (emails, notifications, scheduled jobs) are triggered via shared utilities, so they can be monitored and maintained centrally.

This keeps backend integration consistent and avoids tightly coupled dependencies between systems.

Data & Schema Integration

Each Business System defines its own data models and migrations. During project assembly, these schemas are merged into a single project-level schema that the application uses at runtime.

Key aspects of schema integration:

• Systems define their own Prisma models, enums, and relations under a clear namespace or naming convention.
• When systems are installed into a project, their schema definitions are merged into the project’s unified schema file.
• Migrations for each system are applied in a controlled sequence so the database remains in sync with the combined schema.
• Relationships between models from different systems (for example, a user and a quote) are defined using clear, documented references.

This approach allows systems to be developed independently while still sharing a coherent data model when assembled into a project.

Configuration Integration

Systems often require configuration values such as feature toggles, environment variables, or integration keys. To keep configuration predictable, systems follow a consistent pattern.

Configuration patterns:

• Each system exposes a typed configuration interface (for example, a TypeScript type) that defines what can be configured.
• Default configuration values are provided by the system, so it can work with minimal setup in development environments.
• Projects override configuration values at the workflow or environment level, not by editing the system’s source code.
• Required environment variables are documented inside the system and validated at startup.

This ensures that configuration remains transparent and auditable, and that systems can be reused across different projects without confusion.

Workflow Integration

Systems provide generic capabilities. Workflow integration is how those capabilities are arranged into a sequence that matches the partner’s real process. This happens in the workflow layer, not inside the systems themselves.

Workflow integration patterns:

• The workflow layer decides when to call system actions andin what order.
• Business rules (for example, eligibility checks, pricing formulas, or approval conditions) are implemented in workflow logic, which then uses system APIs or actions to carry out operations.
• Systems provide the building blocks (forms, automations, storage), while the workflow layer determines how users move between these capabilities.
• If a workflow spans multiple systems (for example, onboarding then quoting), the workflow layer coordinates the transitions.

This separation keeps systems reusable and keeps partner-specific logic isolated and easy to reason about.

Authentication & Permissions Integration

Most systems rely on shared concepts of users, roles, and permissions. Integration with the authentication system ensures that each system respects access control consistently.

How this works:

• The authentication system provides user identity and session context to all other systems.
• Systems check permissions via shared helpers or middleware, not by implementing their own access logic from scratch.
• Role-based views and actions are handled through consistent checks in the UI and backend layers.

This makes access control predictable and reduces the chance of inconsistent permission behaviour between systems.

How Systems Avoid Conflicts

Because multiple systems can exist in the same project, integration must be designed to avoid conflicts between them.

Conflict-avoidance strategies:

• Consistent naming conventions for routes, components, and models.
• Scoped styles that rely on shared design tokens rather than global overrides.
• No direct modification of other systems’ models or internal logic.
• Shared utilities (for example, notification senders) instead of each system creating its own global implementation.

This allows systems to be assembled in different combinations without unexpected behaviour.

Summary

Systems integrate into projects through clear, well-defined entry points at the frontend, backend, data, configuration, and workflow layers. They rely on shared infrastructure and conventions instead of custom, one-off connections. This makes it possible to combine multiple Business Systems into a single platform quickly, while keeping each system independent, maintainable, and reusable across future projects.