Reporting
Before
- CSV is exported manually
- data is copied into Excel
- the report is adjusted
- the file is sent by email
After
- data is fetched automatically
- data is validated
- the report is generated
- the report is sent or stored automatically
Integrations and automation
Stop moving the same data manually between systems
I connect systems and automate manual workflows so data does not need to be copied, exported, checked and entered in several places every week.
That can include repeated data entry, manual reports, file exchange, status updates or other administrative steps that currently depend on an employee.
Does any of this sound familiar?
Integrations only make sense when they remove a concrete piece of manual work or reduce the risk of errors in an existing process.
- We enter the same customer data in several systems.
- Data is exported manually to Excel or CSV.
- An employee creates the same report every week.
- Order or customer data is copied between platforms.
- Information is forwarded manually when a status changes.
- We spend time checking whether data matches across systems.
- One system is missing information that already exists in another.
- Files need to be downloaded, processed and forwarded repeatedly.
- A process depends on someone remembering to perform a specific step.
From manual work to an automated flow
These are illustrative workflows. The actual solution depends on the systems, data and rules the company really uses.
Customer data
Before
- customer is created in system A
- details are copied manually
- customer is created in system B
After
- customer is created in system A
- data is validated
- customer is created automatically in system B
Status changes
Before
- status changes in an internal system
- an employee notices the change
- customer or team is informed manually
After
- status changes
- the workflow starts automatically
- the relevant system or person is notified
Data across systems
Before
- data exists in several places
- employees compare it manually
- differences are found later
After
- data is synchronised according to defined rules
- differences are validated
- errors are recorded and can be handled
What can be integrated and automated?
The solution type follows the workflow. APIs, webhooks and other technical mechanisms only become relevant after it is clear what actually needs to happen.
System-to-system integrations
When information needs to move between existing platforms such as CRM, accounting, booking, e-commerce, internal systems or other third-party solutions that provide the required access.
Data synchronisation
When the same customer, product, order, inventory, status or reporting data exists in several places. Synchronisation can run one way, both ways, on events or on a schedule.
Automated workflows
When one event should trigger several steps. For example: new customer → validate data → create in another system → send an internal notification → record the result.
Scheduled jobs
When a process should run automatically at fixed intervals, such as fetching data, generating a report, checking status, synchronising systems or processing files.
Reporting and data processing
When raw data needs to be fetched, combined, validated, transformed, stored or forwarded as part of a repeatable process.
APIs and webhooks
APIs let systems exchange data directly. Webhooks let a workflow react automatically when something happens in another system. They are mechanisms behind the solution, not the goal itself.
If the need also requires a dedicated user interface or custom system, it may make more sense to combine the integration with a web app.
A login-based customer area may instead belong under client portals.
What happens when something goes wrong?
Automation should not simply move work out of sight. When it replaces manual steps, errors need to be discoverable, understandable and handled in a controlled way.
Validation
Data can be checked for missing fields, invalid values, unexpected formats and other known problems before the next action is performed.
Error handling
Expected failures such as unavailable third-party systems, API errors, timeouts, missing data or invalid responses are handled explicitly instead of being ignored.
Retries where appropriate
Temporary failures can be retried automatically in relevant flows, so a short outage in an external system does not necessarily mean the process is lost or needs manual restart.
Duplicate protection
If a step is attempted again, the solution should avoid creating the same order, customer or action more than once where possible. The technical principle is often called idempotency.
Logging
It should be possible to see what was attempted, what succeeded, what failed and when it happened. Otherwise automation can simply replace visible manual work with hidden problems.
Monitoring and alerting
Where the importance and scope of the solution require it, critical failures can be made visible to the relevant person or operations function. Scope and response times are agreed explicitly in the project or an operations agreement.
Technical proof: data flow, validation and recovery
pgDumpster is a concrete MKP Digital product where several data sources and system surfaces need to be handled in a controlled automated flow.
Own product
pgDumpster
pgDumpster is a source-available CLI for backup, verification, inspection and restore of hosted Supabase projects across databases, Storage, Auth, Edge Functions and project configuration.
View the pgDumpster project- Handles data and configuration across several Supabase surfaces in one coherent flow.
- Uses validation, integrity checks, checkpoints, resume and explicit recovery logic.
- Supports local and S3-compatible destinations with publication verification.
- The published release is documented with CI, CodeQL and hosted source-to-target E2E.
Price depends on the systems, data and workflow
The price levels are indicative. The final price is based on what needs to be connected, platform limitations and how robust the flow needs to be.
Simple integration
DKK 15,000–35,000
One or two systems, straightforward data exchange and few rules or fields.
Advanced integration
DKK 35,000–75,000
Several systems, more business logic, error handling or scheduled synchronisation.
Data pipeline / platform
DKK 75,000+
Larger flows with more data sources, transformations, operational requirements or more complex coordination.
What typically drives complexity
Number of systems
An integration between two systems is usually simpler than a workflow spanning several platforms.
API quality and platform limits
Documentation, rate limits, available endpoints, webhook support and other constraints affect what can be built and how much work it requires.
Data and mapping
Data volume, data models, mapping between systems, validation and transformation can be a substantial part of the work.
Workflow and rules
A simple ‘when X happens → do Y’ is less complex than flows with several conditions, statuses, branches, retries or approvals.
Authentication
Some systems use simple API keys. Others require OAuth, token refresh and handling of different user permissions.
Error handling and operations
Critical automations may require more logging, retries, monitoring, recovery or an agreed manual fallback.
Historical data
If existing data also needs to be migrated or backfilled, that is a separate complexity factor in addition to the ongoing integration flow.
How an integration project starts
First, the existing workflow is mapped. Then system access, data, rules and error handling are made concrete before implementation starts.
1
Map the process
We review what happens today, which systems and data are involved, who performs the work, and where errors or waiting time occur.
2
Scope and integration design
Source, target, triggers, rules, data, authentication, error handling and price are defined — including whether the systems actually expose the interfaces required.
3
Implementation and testing
The integration is built and relevant normal flows, invalid data, API failures, retries, duplicates and edge cases are tested within the agreed scope.
4
Production and operations
The flow is deployed and verified in production. Logging, monitoring, maintenance and handling of third-party changes are agreed as needed.
FAQ
Questions about integrations and automation
No, not necessarily. It depends on API access, export options, authentication, platform limitations and whether the required data is available at all. If a system does not expose the necessary access, the integration may be limited or unrealistic.
Other realistic options can be assessed, such as export/import or file-based flows, if the platform supports them. If the system provides no stable and permitted way to access the required data or actions, automation may be limited or not responsible to build.
A simple integration is indicatively DKK 15,000–35,000. The final price depends on factors such as the number of systems, API quality, data, workflow, authentication and requirements for error handling and operations.
Often, parts of it can be automated, but it depends on where the data comes from, what happens in the spreadsheet and where the result needs to go. The process is mapped first so the implementation does not simply reproduce a poor manual workflow in code.
It depends on the flow. Relevant solutions can record the failure, retry temporary errors and make critical problems visible. There is no promise that third-party systems will always be available.
Where the flow allows it, the integration can be designed so retries or repeated requests do not blindly create the same order, customer or action more than once. The exact strategy depends on the capabilities of the systems involved.
Yes, if the systems expose the necessary interfaces and data. More systems usually increase complexity because mapping, error handling and dependencies between steps also need to be handled.
Yes, if there is access to the existing code, configuration and relevant systems. Before changes are made, the current flow, failure patterns and whether the solution is sensible to continue are assessed.
Yes. Operations and maintenance can be agreed as needed. Scope can include relevant changes, bug fixes and operational work, but specific monitoring or response times must be stated in the agreement that is made.
Do you have a process that is still performed manually?
Describe which systems you use, what the employee does today, and what should ideally happen automatically. You do not need to know whether the solution requires an API, webhook or something else.
Describe the process