During my apprenticeship at EDF, on a nuclear power generation site, I designed and built an internal application to make reliable and automate a whole document-management pipeline, from the request submitted by the business teams to its handling by the printing provider.
Context and problem
A nuclear generation site has strict requirements around technical documentation: staff must have their working documents printed reliably and quickly.
Before this project, print requests were sent to the provider through unstructured Excel files. This caused two concrete problems:
- frequent errors due to the lack of input control (free-text fields, unconstrained formats);
- a significant waste of time on the provider's side, who had to extract each document manually, one by one.
Goal
Design an app that makes input reliable and automates the whole chain, from the business teams to the provider. Imposed constraint: stay within EDF's Microsoft policy, i.e. use the Power Platform suite (Power Apps, Power Automate, SharePoint).
Architecture: two complementary flows
I structured the solution into two distinct flows:
- Data feed: a scheduled flow keeps an up-to-date copy in SharePoint of the reference list of printable documents, sourced from an internal document database. Since that database wasn't directly accessible with the available licenses, I set up an automatic synchronization (triggered by a scheduled email), processed by a script to produce a usable reference list.
- Request processing: triggered from the interface, it handles input, validation, segmentation, then transmission of the request to the provider.
Rather than putting everything into a single automation, I split the processing into several specialized automations triggering in cascade. This choice draws on software-engineering best practices (avoid duplication, ease maintenance, evolve one link without breaking the rest) and also clearly improves performance.
Interface and input validation
The Power Apps interface, aimed at non-technical users, offers two input modes matching the teams' habits. I implemented a whole layer of conditional logic missing from the native components:
- cross-validation (two input modes that can't both be empty);
- dependent dropdowns (the second filters based on the first);
- conditional fields depending on the request type.
This level of formalization, every field controlled, conditioned and validated before transmission, removes input errors at the source, which was impossible with the old free-form Excel files.
Working around low-code limits (TypeScript)
Power Platform feels simple but hides real limits: no regular expressions, poor performance on large CSV files, little advanced filtering. To get past them, I built TypeScript scripts (Office Scripts) handling file conversion, regex cleanup and data validation.
That's one of the project's key lessons: knowing how to step outside the no-code box when a precise technical need calls for it.
Technical challenges
- Performance optimization: my first loop-based (
For Each) processing was unusable on real volumes (over a day of processing). I rewrote it withFilteractions that operate on a whole array in one pass, far faster, but noticeably harder to build. - A subtle parsing bug: some data contained commas, but the comma was the CSV separator, which silently broke processing. I fixed it by switching the separator character via a script.
- Debugging: with no breakpoints or console, tracing an error in a flow of dozens of actions takes method and patience.
- External dependencies: part of the chain relies on a system managed by another team. Any change goes through formal requests, a common reality in industry, where some difficulties are organizational rather than technical.
Print tracking
In a second phase, I set up print tracking: a dedicated store (a SharePoint list) I designed myself, following each request through three states, being extracted, at the printing provider, then printed. It updates automatically at each step (when the processing email is received, then after the provider validates the prints through a Power BI dashboard). The goal: give the business teams end-to-end traceability of their requests.
Results & takeaways
I met all three goals: structured, validated requests at input, no more manual extractions on the provider's side (who now receives print-ready PDFs directly), and a fully automated chain. Structuring the requests even made it possible to introduce new differentiated treatments by document type, previously impossible. Deployment is under way, with the aim of extending the tool to other sites.
Beyond the technical side, this project taught me to frame a need in a complex, poorly documented environment, to make deliberate architecture choices, and to work with every stakeholder (business teams, provider, internal teams). It also tempered the low-code promise: between the complex automations and the TypeScript scripts, the solution requires real development skills and is, in practice, not maintainable by a non-technical profile, a risk I flagged for its long-term upkeep.