The Integration Problem Nobody Talks About
We've deployed open-source platforms across power utilities for fifteen years. The hardest part isn't picking tools—it's making them work together without creating a compliance nightmare or maintenance hell. Every platform has APIs. Most have webhooks. Few actually integrate cleanly in air-gapped OT environments where you can't just ping a SaaS endpoint.
The real question isn't "which platforms" but "which integration architecture." We've seen three utilities spend six months integrating ERPNext with their existing systems, only to realize their chosen pattern violated NERC CIP-007 logging requirements. Another client built beautiful n8n workflows connecting five platforms, then discovered their webhook chain created a 40-second latency for critical alerts.
This guide outlines the decision framework we use when architecting platform integration for energy operations. It's based on actual deployments, actual failures, and actual compliance audits.
Decision Criteria That Actually Matter
Forget the vendor comparison matrices. Here's what determines success or failure in energy sector integration:
Data Sovereignty and Audit Trail
NERC CIP-007 requires complete logging of access to BES Cyber Systems. Your integration architecture must preserve audit trails across platform boundaries. When a user in Nextcloud triggers an n8n workflow that updates ERPNext inventory, you need unified logging showing the complete chain.
We've found that event-driven architectures with centralized log aggregation work. Point-to-point API calls with scattered logs fail audits. The integration pattern determines whether you can prove who did what, when.
Air-Gap Compatibility
Many utilities run critical systems air-gapped from the internet. Your integration architecture must work when platforms can't reach external services. This eliminates:
- OAuth flows requiring internet-accessible authorization servers
- Webhook deliveries that assume public endpoints
- Cloud-based message queues or pub/sub systems
- Any integration that phones home for licensing or updates
We default to local message queues, direct API calls over private networks, and file-based integration for air-gapped environments.
Failure Domain Isolation
When one platform goes down, does it cascade? We saw an outage where n8n couldn't reach ERPNext's API, which caused workflow failures, which filled disk space with error logs, which crashed the n8n instance, which stopped critical SCADA data collection.
Your integration pattern must isolate failures. Message queues help. Circuit breakers help. Tight coupling kills you.
Latency Tolerance
Some integrations need sub-second response. Others can tolerate hours. Mixing them in the same architecture causes problems. We've seen systems where real-time SCADA alerts shared an integration bus with nightly ERPNext inventory reconciliation—the batch jobs starved the alerts.
Define latency requirements before choosing integration patterns.
Maintainability by Operations Teams
Your senior DevOps engineer who designed the integration will leave. Your operations team needs to troubleshoot at 2 AM when workflows break. Complex choreography patterns with twelve microservices sound elegant but fail this test.
We bias toward architectures that operations staff can understand by reading logs and following explicit workflow definitions.
Integration Patterns We Actually Use
Pattern 1: n8n as Central Orchestrator
This is our default for utilities with moderate integration complexity. n8n sits in the middle, connecting ERPNext, Nextcloud, Matrix, OpenProject, and operational systems.
How it works: All integration logic lives in n8n workflows. Platforms expose APIs but don't call each other directly. n8n polls or receives webhooks from source systems, transforms data, and pushes to destination systems.
Strengths:
- Single pane of glass for all integrations
- Visual workflow debugging
- Built-in error handling and retry logic
- Easy to add new platforms without touching existing integrations
- Works air-gapped with self-hosted n8n
Weaknesses:
- n8n becomes a single point of failure (mitigate with HA setup)
- Can become a performance bottleneck for high-throughput scenarios
- Workflow versioning requires discipline
Best for: Utilities with 3-7 integrated platforms, mixed latency requirements, operations teams comfortable with visual workflow tools.
Real example: We use this at a 500MW wind farm where n8n connects:
- SCADA systems to Matrix for operator alerts
- ERPNext inventory to OpenProject work orders
- Nextcloud document approvals to ERPNext procurement
- Turbine maintenance logs to ERPNext asset management
Each integration is a separate workflow. When SCADA integration breaks, procurement keeps running.
Pattern 2: Event Bus with Message Queue
For higher complexity or throughput, we deploy a message queue (usually Redis or RabbitMQ) as an event bus. Platforms publish events to topics. Other platforms subscribe and react.
How it works: Each platform has an adapter (often a small Python service or n8n workflow) that publishes domain events to the queue. Subscribers process events asynchronously.
Strengths:
- Natural failure isolation—dead subscribers don't block publishers
- Handles high throughput and traffic spikes
- Time-decouples systems (a subscriber down for maintenance catches up later)
- Clean audit trail if you log all events
Weaknesses:
- More infrastructure to maintain
- Requires more sophisticated operations understanding
- Can be harder to trace end-to-end flows
- Event schema evolution becomes a problem
Best for: Utilities with high-volume data flows, many integrated systems, or strict failure isolation requirements.
Real example: We deployed this for a utility processing 10,000+ daily work orders. ERPNext publishes work order events to Redis. Subscribers include:
- An n8n workflow that creates OpenProject tasks
- A Python service that updates GIS systems
- A Matrix bot that notifies field crews
- An archival service that writes to Nextcloud
When the GIS system went down for a week due to vendor issues, events queued and processed automatically when it returned.
Pattern 3: Direct API Integration
Sometimes simplicity wins. For tight coupling between two platforms with low latency requirements, direct API calls work fine.
How it works: Platform A calls Platform B's REST API directly. Usually authenticated with API keys or OAuth tokens.
Strengths:
- Minimal complexity
- Lowest latency
- Easy to understand and debug
- No additional infrastructure
Weaknesses:
- Tight coupling means failure propagation
- Hard to insert middleware for logging or transformation
- Doesn't scale to many platforms
- API versioning becomes your problem
Best for: Two-platform integrations with low latency needs, stable APIs, and tight functional coupling.
Real example: We use direct integration between Nextcloud and ERPNext for invoice attachment. When an ERPNext invoice is created, it calls Nextcloud's API to create a shared folder and returns the link. Sub-second response required, tight coupling acceptable.
Pattern 4: File-Based Integration
Don't laugh. For air-gapped or legacy systems, file-based integration is sometimes the only option—and it works.
How it works: Platform A writes CSV or JSON files to a shared directory. Platform B polls the directory and processes files. Often includes file archival and error directories.
Strengths:
- Works with any system that can write files
- Natural throttling—file processing rate is bounded
- Built-in audit trail (the files themselves)
- Easy to replay or reprocess
- Perfect for air-gapped environments
Weaknesses:
- High latency (usually minutes to hours)
- Manual error handling
- File locking and concurrency issues
- Feels primitive
Best for: Integration with legacy systems, air-gapped environments, batch processes, or when you need guaranteed replayability.
Real example: We use this for ERPNext-to-mainframe integration at a large utility. Every night, ERPNext exports work order completions to CSV. A mainframe job picks them up and updates the financial system. It's not elegant, but it's auditable, reliable, and has run for four years without incident.
Decision Framework
Here's how we choose:
Start with these questions:
- How many platforms need integration? (2: direct API; 3-7: n8n orchestrator; 8+: event bus)
- What's the highest acceptable latency? (<1s: direct API or event bus; <1min: n8n; >1hr: file-based)
- Is the environment air-gapped? (Yes: eliminate patterns requiring internet; favor file-based or local message queues)
- What's your operations team's skill level? (Low: n8n orchestrator; High: event bus)
- Do you have strict failure isolation requirements? (Yes: event bus; No: n8n orchestrator acceptable)
Then apply these rules:
- If any platform lacks a real-time API, you're doing file-based integration for that platform
- If NERC CIP compliance is in scope, you need unified logging regardless of pattern
- If you're integrating more than one real-time operational system (SCADA, DCS, etc.), use an event bus to isolate failures
- If you have mixed latency requirements, use n8n with separate workflows for different SLAs
- If this is your first integration project, start with n8n orchestrator and migrate to event bus if needed
Common scenarios:
New utility with ERPNext, Nextcloud, Matrix, OpenProject: n8n orchestrator. Four platforms, mixed latency, operations team learning open source.
Large utility adding open-source platforms alongside legacy mainframes: File-based for mainframe integration, n8n for modern platform integration.
Utility with high-volume SCADA data feeding into ERPNext maintenance: Event bus with Redis. Failure isolation critical, high throughput.
Small wind farm needing Nextcloud-ERPNext document workflow: Direct API integration. Two platforms, tight coupling acceptable.
Platform-Specific Integration Considerations
ERPNext
ERPNext's REST API is comprehensive but has quirks. Authentication uses API key/secret pairs. The API is well-documented but sometimes inconsistent—some endpoints return different structures for single vs. multiple records.
Key integration points:
- Sales orders, purchase orders, work orders for ERP workflows
- Item master and stock levels for inventory sync
- Employee records for HR integration
- Project and task endpoints for OpenProject sync
Watch out for: ERPNext's permission system applies to API calls. Your integration user needs specific role permissions. We've debugged many "API returns empty" issues that were actually permission problems.
Nextcloud
Nextcloud's WebDAV API works well for file operations. The Talk API (Matrix bridge) enables chat integration. The recent AI assistant features use a separate API.
Watch out for: Nextcloud's OAuth implementation can be tricky in air-gapped environments. We usually use app passwords instead—less secure but actually works when you can't redirect to an authorization server.
n8n
As an integration platform, n8n integrates with everything. It has native nodes for ERPNext, Nextcloud, Matrix, and 400+ others. You can self-host completely, which is essential for air-gapped deployments.
Watch out for: n8n's execution history can grow large. In production, configure retention policies and database cleanup. We've seen instances slow to a crawl with millions of execution records.
Matrix/Element
Matrix's federation model is powerful but complex for integration. Most utilities use it as a closed system (no federation to public servers). The bot SDK is straightforward for building alert integrations.
Watch out for: Matrix's end-to-end encryption is great for security but complicates bot integration. Bots need to be in rooms before encryption is enabled, or they can't read messages.
OpenProject
OpenProject's API is RESTful and well-designed. Work packages (their term for tasks/issues) map cleanly to ERPNext work orders.
Watch out for: OpenProject's project hierarchy can be deep. When syncing to ERPNext, you need to decide how to flatten or map that hierarchy.
Compliance and Security
NERC CIP Requirements
If your integration touches BES Cyber Systems, you need:
- Audit logging of all cross-platform data access (CIP-007)
- Access control at integration points (CIP-005)
- Secure credential storage for API keys (CIP-007)
- Change management for integration configurations (CIP-010)
Our approach: Run all integration through a dedicated network zone with logging to a centralized SIEM. Store API credentials in a secrets manager (we use Vault or ERPNext's encrypted custom fields). Treat n8n workflows or integration code as controlled configurations requiring change approval.
Data Classification
Energy sector data ranges from public to CEII (Critical Energy Infrastructure Information). Your integration architecture must enforce classification boundaries.
We tag data in the originating system and enforce routing rules in n8n or the event bus. For example, CEII data from SCADA never flows to Nextcloud public shares, even if a workflow could technically do it.
The Verdict
For most energy utilities starting open-source platform integration: Use n8n as your central orchestrator. It provides the right balance of capability, maintainability, and flexibility. You can integrate ERPNext, Nextcloud, Matrix, and OpenProject with visual workflows that your operations team can troubleshoot.
Deploy n8n in high-availability mode (two instances behind a load balancer, shared PostgreSQL database). Use separate workflows for different latency requirements—don't mix real-time SCADA alerts with nightly batch jobs. Implement centralized logging from day one.
As your integration complexity grows, migrate high-throughput or critical workflows to an event bus pattern. Keep n8n for medium-complexity integrations and use it to publish/subscribe to the event bus.
Avoid direct API integration except for simple two-platform scenarios. The coupling will bite you during outages.
Don't dismiss file-based integration for legacy systems or air-gapped scenarios. It's not elegant, but it's reliable and auditable.
Most importantly: Design your integration architecture for failure. Platforms will go down. APIs will change. Networks will partition. Your integration pattern should contain failures, not amplify them. In our experience, that's the difference between an integration architecture that serves the business for years and one that becomes a maintenance nightmare.