When is low-code in epilot no longer enough?

epilot low-code takes utilities, municipal utilities and grid operators a long way. The platform covers a lot of their workflows through configuration, without anyone writing a line of code. This article looks at the points where classic software development is needed again, and how it fits alongside epilot rather than working against it.

It was written by Marcel R. G. Berger. I have been a software developer and software architect for more than 20 years and work with epilot as an external consultant and developer for apps and customisations. The article is for IT leads who are rolling out epilot or already run it, and who have to decide whether a requirement still fits into configuration or calls for an interface of its own.

What does epilot deliver as a no-code and low-code platform?

epilot is an excellent no-code and low-code platform that maps a large share of a utility’s workflows without programming. Data models, journeys, automations and portals are configured, not developed.

For many organisations that is the fastest path to stable processes. Configuration is easier to change than code, business teams can follow it, and platform updates arrive without extra effort on your side.

epilot also offers several integration paths of its own. According to the integrations overview in the epilot developer documentation, these include the Integration Toolkit for ERP systems, a Batch API, webhooks for real-time events and public APIs for custom integrations with full control.

So the question is not whether epilot can integrate. The question is when an integration becomes so specific that it needs code of its own.

How do you spot that low-code is reaching its limit?

Low-code reaches its limit when a requirement needs logic outside the platform that can no longer be configured sensibly. In practice, the same signals keep coming up.

• A large part of a process runs outside epilot, for example in a specialist system that stays in use.
• Surrounding systems such as other CRMs, databases, ERP, billing or grid systems need to exchange data with epilot, and there is no ready-made connection.
• Data has to be transformed, merged or checked on its way between two systems.
• An event in epilot should trigger an action in another system, and the result should flow back into epilot.
• A connection has to handle errors cleanly, be repeatable and be monitored in operation.

If none of these apply, configuration is almost always the better choice. If one or more do, it is worth looking at an interface of your own.

What if processes run outside epilot?

If processes run outside epilot, that part stays in the specialist system, and an interface makes sure both sides see the same data. epilot does not have to model anything it is not meant to model.

That is exactly the situation in my current project at a grid operator in Hesse. Many processes there are not mapped in epilot and run outside the platform instead. That is why several third-party systems are connected to epilot through individually developed interfaces. How this is built is described in the in practice section on the home page.

The attitude matters here. This is not about working around epilot. It is about using epilot where it is strong and connecting the remaining systems so that processes run reliably across system boundaries.

Which surrounding systems typically need connecting?

The systems that need connecting are usually the ones that have been running in the organisation for years and are not going to be replaced. At utilities and grid operators, these are mainly the following groups.

• ERP systems and billing
• grid systems and other specialist applications in network operations
• other CRMs alongside epilot
• in-house databases holding master data or historical data

For ERP systems, epilot offers a standardised route of its own: the Integration Toolkit. The Integration Toolkit documentation states plainly that the toolkit does not remove the need for middleware; it standardises the interface between epilot and that middle layer.

That middle layer is exactly where custom development comes in. The more surrounding systems are involved and the more their data formats differ, the more logic ends up there.

How to connect ERP, billing and grid systems step by step is covered in the article Connecting ERP, billing and third-party systems to epilot.

When do data transformations become too complex for configuration?

Data transformations become too complex for configuration when they merge several sources, contain business rules or have to be provably correct. At that point the logic belongs in code that can be tested, versioned and reviewed.

Simple mappings, one field here and one there, configure well. It is a different story when, say, a record from epilot first has to be enriched with data from a database, then converted into the format a specialist system expects, and checked for completeness before any of that.

A mapper does exactly this work: it maps fields, converts formats, validates the data and handles errors. How such a mapper is put together is the topic of the article Mappers between epilot and surrounding systems, built with Quarkus.

How do events in epilot trigger actions in other systems?

Events in epilot trigger actions in other systems through webhooks. When an event occurs, epilot sends an HTTP POST to a configured address, and a service of your own then carries out the necessary steps in the surrounding systems.

The epilot webhooks documentation puts it like this: the Webhooks API lets you subscribe to events in your epilot account, and when an event occurs, epilot sends an HTTP POST request to your configured webhook URL. It gives entity:created as an example of such an event.

The receiving service first checks that the request really comes from epilot. epilot signs every webhook request, and the webhook security page explicitly advises always verifying signatures before processing a payload.

Then the actual work begins: translating data, triggering an event in another system and, where needed, writing the result back into epilot as information. That chain is the typical core of an epilot integration with surrounding systems.

What matters when receiving these requests in detail is explained in Processing epilot webhooks securely. How data flows the other way is covered in a REST API interface for epilot.

Why does an integration need rules for load and retries?

An integration needs rules for load and retries because every API has limits and every network fails now and then. Without those rules, data gets lost or processed twice.

The rate limits page in the epilot documentation explains that the API responds with HTTP 429 when a limit is exceeded and uses the Retry-After header to say when to try again. For larger volumes, epilot points to the Batch API and the Integration Toolkit.

Configuration can only express a limited amount of this. In a service of your own, these points are simply part of the craft:

• retries with back-off that respect the Retry-After hint
• idempotency, so a repeated call does not create a duplicate record
• a clean log that shows which record went where and when
• monitoring that raises a flag when a connection stalls

For grid operators, this part often matters more than the field mapping itself. A process that crosses system boundaries is only as stable as its weakest link.

Low-code or classic development: which fits what?

Low-code fits workflows inside epilot, classic development fits logic between epilot and other systems. The overview below helps with the call.

Requirement	Low-code in epilot	Classic development
Workflow lives entirely in epilot	usually fits	rarely needed
Surrounding system with a ready-made connection	fits if the standard is enough	when the standard is not enough
Surrounding system without a ready-made connection	reaches its limits	interface of your own
Merging data from several sources	reaches its limits	mapper with tests
Event should trigger an action in another system	configure a webhook	service that receives the webhook and acts
Traceable error handling in operation	limited	logging, retries, monitoring

The table is not a rigid rule. It does show that the limit rarely lies in epilot itself, and almost always at the point where data leaves the platform or comes into it.

How much logic should stay in epilot?

As much as possible. Anything that can be configured cleanly in epilot should stay there, because configuration is visible to business teams and evolves along with the platform.

Only what happens between systems belongs in your own interface: translating the data, talking to the surrounding systems and handling errors. That split keeps both sides lean. epilot stays clear, and the integration code stays small enough to understand, test and maintain.

A good rule of thumb: if a rule only exists because of epilot, it belongs in epilot. If it only exists because another system expects something different, it belongs in the mapper.

Does a developer replace epilot’s consulting team?

No. A developer does not replace epilot’s consulting team, they work alongside it. For the rollout and the standard scope, epilot’s consulting team remains your point of contact.

I pick up where epilot’s standard ends: interfaces to your own systems and individual extensions. I work with epilot as an external consultant and developer for apps and customisations. Work on the epilot platform itself is carried out only in cooperation with epilot.

For you, that means a clear split. epilot is responsible for the platform and its configuration, and the side that builds the custom integration is responsible for that integration. The services involved are listed in the section what I do for epilot customers.

How do you get started once you hit a limit?

You start with a short conversation about your systems and workflows. That shows whether configuration is enough or whether an interface of your own makes sense.

1. Intro call: free and non-binding, 30 minutes on Microsoft Teams.
2. Individual quote: after the call you receive a quote tailored to your systems.
3. Implementation: interfaces or the app get built and put into operation with your systems.

What each of these steps looks like in detail is described in the article on how an epilot integration project runs at a grid operator.

The code belongs to you. Why that matters especially for grid operators is explained in the article Who owns the integration code?. Answers to further questions are in the FAQ on the home page, and you can pick a slot directly in the booking calendar.