Who Should See Your ERP Export Files

A scheduling export set is more sensitive than it looks: together it can carry customer names, prices, quantities, due dates, part numbers and labor rates, and the files themselves are governed by your file system rather than by the application. In EDGEBIC by User Solutions the import function sits inside the permission-controlled Settings area with access granted through roles, but that control ends at the application boundary. The folder your nightly export lands in is your responsibility.

What is in the files

Take the five exports a typical integration uses and read them as one collection rather than five spreadsheets.

Individually, unremarkable. Together, in one browsable folder, that is a competitive briefing on your business, assembled by accident because convenience was the goal.

Routings deserve a particular mention. A full routing export is your manufacturing method, which is often the thing a shop would least like a competitor to read, and it is rarely thought of as confidential because it lives in an engineering system all day.

Where the application's control ends

Worth being exact about, because it determines what you have to do yourself.

Inside the application. Import lives in the permission-controlled Settings area. Access comes from roles rather than per-user settings, so you manage it by deciding which roles exist and who belongs to them. Every run writes one log file recording each row's outcome and any failure reason.

Outside the application. The export file is an ordinary xlsx or csv sitting wherever your export job wrote it. Nothing in EDGEBIC encrypts it, restricts who can open it, or removes it afterward. Those are file system and process questions.

That split is inherent to a file-based integration, which is how the whole integration works: something outside produces a file, an import mask loads it. There is no connector holding credentials and no sync service with its own access model, which removes a category of risk and hands you a folder to look after.

Who needs access

Keep two lists, and keep both short.

Who can produce the export. Usually one person or a scheduled job with database or ERP access. This is the technical half and it is bounded.

Who can run the import. The people who own master data and the planning cycle. Import changes data, so it belongs with them rather than with everyone who reads a schedule. Since permissions come from roles, the practical action is to review which roles include Settings access and prune the membership rather than looking for a per-user switch, because there is not one.

A useful test: if someone's job never requires them to change what the plant is planning against, they do not need import access, however senior they are.

Where the files should live

Four practical moves, none of them dramatic:

1. Give the export its own folder, not a general-purpose share. This is the highest-value change on this page and usually takes five minutes.
2. Grant that folder to the small group who produce and consume it. Most offices are browsing a share that was opened up years ago for a different reason.
3. Use a stable path with a predictable file name. Good for reliability, and it also means you are not scattering copies with ad-hoc names in convenient places.
4. Set a retention and delete on a schedule. Keep a few cycles for diagnosis, since when a schedule looks wrong the file that produced it is the fastest way to tell whether the data or the mapping was at fault. Beyond that the folder is accumulating sensitive data with no operational purpose.

Apply the same clear-out to import logs, which are also retained until you delete them.

Operational record versus audit trail

These get conflated, and it matters if your requirement is regulatory.

What exists is an operational record: one log file per run, showing exactly what each run changed, with reasons for failures. That is genuinely useful and it is what reading the import log after a nightly ERP run is about.

What does not exist is an in-app screen for browsing security or access history. So if you need to answer who opened a file or who held a permission on a given date, the controls have to come from the layers that offer them: your file system's own auditing on the export folder, and the discipline of a short role list. Decide which you actually need rather than assuming the application answers a question it does not claim to answer.

A short review worth doing once

Ask four questions, once, and write down the answers:

• Which folder do the exports land in, and who can browse it today?
• Which roles grant import access, and who is currently in them?
• How long do export files and import logs stay there?
• Who is told when someone with access changes job?

That last one is the gap in most shops. Access lists are created carefully and then never revisited, so the person who set up the integration three roles ago still has everything. Tie the review to whatever process already handles leavers rather than inventing a new one, and pair it with the ownership decisions in who owns the ERP import routine on your team.

The takeaway

Your ERP export set combines customer names, prices, quantities, due dates, routings and labor rates into one place, which makes the folder more sensitive than any single file in it. The application controls who can import, through roles rather than per-user settings, and records what each run did in a per-run log; it does not control the files on disk or offer a browsable access history. Give the export a dedicated folder with a short access list, set an explicit retention for files and logs, and review who holds import access when people change job. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with specifying the ERP export you need from IT and the data import governance workflow in EDGEBIC.