Workflow automation: connect your software, control your data, stop re-keying
Make information flow between your tools reliably, securely and under supervision, with data held in a single place.
Automate what repeats, connect what is isolated
Copying rows from one file to another, re-entering an order in three programs, fixing the same export by hand every week: signs that information does not move by itself. Workflow automation makes it flow between your tools without intervention, with checks, and makes it reliable.
The approach stays pragmatic: start from your current files and tools, automate first what recurs most or causes the most errors, then consolidate. For smaller tasks (macros, scripts, executables), see the automations and utilities page.
Do any of these sound familiar?
- You copy data from one file or program to another.
- Your software does not talk to each other.
- The same information (customer, product, price) exists in several versions that do not match.
- Each new link between two tools piles onto the previous ones and nobody dares touch anything.
- You want to analyse your data, but it is scattered or of uneven quality.
- When an automatic exchange fails, you find out too late.
What I offer
Software integration
Connecting your tools (sales management, invoicing, store, CRM) through their APIs, webhooks or exchange files.
Middleware and gateway
An intermediate layer that receives, checks, transforms and redistributes data, so each program is not linked to all the others.
Data management
Ingestion, transformation, quality control, ETL/ELT pipelines, data warehouse, modelling and publication to users and tools.
Monitoring and recovery
Logs, alerts, replay of failed exchanges, recovery after an incident without losing or duplicating data.
Repetitive tasks
Automated Excel, macros, scripts and executables for more occasional processing.
Software integration: APIs, webhooks, middleware
Connecting two programs looks easy while there are only two. With five or ten tools the number of links explodes and any change in one program breaks several exchanges. I design exchanges to stay readable and maintainable.
- APIs: direct reading and writing in programs that offer them
- Webhooks: receiving an event (new order, contact created) to trigger processing
- Exchange files (CSV, JSON, XML) when no API exists
- Middleware: a central point that receives, validates, transforms and routes
- Authentication and secrets handled properly, rights limited to what is needed
- Sandbox to test an exchange without touching real data
To understand the principles: connecting your software with APIs, API integration in detail and middleware.
Single data, held in one place
My design principle: each piece of data has a reference source, held in one place. Other tools consume it, they do not copy it their own way. This reduces duplicates, inconsistencies and the number of interconnections to maintain: instead of linking each program to all the others, each links to the reference data.
- Fewer point-to-point links, hence fewer failures and cheaper tool changes
- One version of the truth for figures, customers, products
- Quality rules applied once, in the right place
- Clear traceability: where data comes from, who changed it, when
Data management: from source to publication
Once needs go beyond a few exchanges, data becomes a subject in itself. I build readable processing chains, from the arrival of data to its availability.
- IngestionCollection from sources: databases, files, APIs, software exports.
- TransformationCleaning, harmonising, enriching, calculating, following written rules.
- QualityCompleteness, format and consistency checks, with rejection or quarantine of anomalies.
- StorageIn a data warehouse (for example Snowflake) or a database suited to volume and need.
- ModellingA data model designed for analysis and reuse.
- PublicationMade available to consumers: dashboards, applications, other systems, exports.
Layered architecture: bronze, silver, gold
I often organise the warehouse following the so-called “medallion” architecture.
| Layer | Content | Role |
|---|---|---|
| Bronze | Raw data, as received | Keep a faithful source, be able to replay a process |
| Silver | Cleaned, typed, deduplicated, matched data | Provide a reliable, consistent base |
| Gold | Data modelled for use | Feed indicators, dashboards and applications directly |
ETL or ELT pipelines (transform before or after loading) move data from one layer to the next. On analysis: from spreadsheet to dashboard and choosing indicators.
Monitoring and incident recovery
An automatic exchange that fails silently is worse than a manual one. Every flow I build is designed to be observable and replayable.
- Logging of each exchange: what came in, was transformed, went out
- Alerts on failure or anomaly
- Replay of failed items without duplicates
- Recovery after an incident from the raw layer
- Dashboard of flow status
- Operations documentation: what to do when it breaks
What it covers, and what it does not
| Covered | Not covered |
|---|---|
| Design and building of flows, pipelines and transformations | Purchase of software or warehouse licences, third-party subscriptions |
| Setting up monitoring and operations documentation | Ongoing operations and maintenance after delivery (additional contract) |
| Tests on your real data before going live | Training and user support (additional contract) |
| Recommendations on data quality | Fixing data in your software on your behalf |
Services are provided with an obligation of means, based on a scope written in the quote.
How it works
- ObservationI look at how information flows today, on your real tools and data.
- MappingI diagram sources, destinations and duplicates.
- PrioritisationWe choose together what is worth handling first.
- BuildDelivery in batches, tests on your data, in staging.
- Acceptance testingYou check results on your real cases.
- Go-liveProduction after a backup, with monitoring in place.
The framework is the one described in how I work.
Frequently asked questions
Do I have to replace my software?
No, most of the time we start from what exists. A tool is replaced only if it is truly the bottleneck, and that choice is yours.
My software has no API: is that a problem?
Not always. We can use exports, exchange files or other mechanisms. Feasibility is checked before the quote.
Do I need a data warehouse?
Not necessarily. For a few exchanges, middleware is enough. A warehouse becomes useful when data must be historised, combined and analysed.
What happens when a flow fails?
It is logged, an alert is raised and failed items can be replayed without duplicates. Continuous operational monitoring is, however, not included in the services.
Is my data protected?
Access is limited to what is needed, secrets are not stored in code and personal data processing is governed (see the privacy policy).
What about a simple task?
The automations and utilities page presents macros, scripts and executables for more targeted needs.
Going further
Scope before automating
If the need still has to be clarified, some project support helps choose the right approach.
Flows to connect?
Describe your tools and what is stuck: I will tell you how I can help.