Build a Process FMEA one part at a time — generate the failure modes and causes for each process, rate the risk, and export a clean Excel workbook.
Most FMEA tools make you re-describe the same operation on every part that uses it. Ten parts through the same drill means ten copies of the same analysis, and when a control changes you have ten documents to remember. FMEA Studio inverts that: the process library holds the analysis, and an FMEA is the list of processes a part uses. Fix a control once and every document that uses that process is correct.
Process steps are named by operation with no made-up operation numbers, so you number and align them to your own process flow and control plan. Set the Line # on each step inside an FMEA and the steps sort by it everywhere — on screen and in both exports — so Op 105 prints before Op 120 no matter which you added first. Whole numbers only, and numbering by tens leaves room to insert an operation later. Steps you leave unnumbered keep the order you added them in and follow the numbered ones.
An FMEA is read-only for process content. The requirements, failure modes, effects, causes, controls and ratings all come from the library and are edited there. On the document itself you set the Line # and choose which processes are in it — and you can remove a process step. That is the whole of it.
This is deliberate. A process is shared by every FMEA that uses it, so editing one on a document would either quietly diverge from the library — the copies drifting apart, which is the thing the library exists to stop — or push a change into every other document from a screen that gives no hint that is what it is doing.
When you edit a process in the library and it saves, that change is pushed into every FMEA already using it. You do not remove the process and add it back, and you do not open those documents — they are updated where they sit, and the editor tells you how many changed. Treat the library as your controlled master: a correction there is a correction everywhere, including on documents you finished months ago.
Two things stay with the document rather than the process, because they belong to the part and not to the operation: the recommended action you committed to on a line, and the line number that operation has on that particular part. Everything else — requirements, failure modes, effects, causes, controls and ratings — comes from the library.
The process editor saves on its own as you work, so nothing is lost to a closed laptop or a dropped connection. It also means there is no moment where an edit is finished but not yet shared. If a process is used across parts that are already released, review it before you change it — the correction reaches all of them.
Two different relationships, and they do different jobs.
Ratings belong to the process, and are set in the process library. The same operation carries the same risk wherever it is used, so Severity, Occurrence and Detection are rated once, on the process, and travel with it into every FMEA that pulls it in. An FMEA shows them and does not let you change them.
FMEA Studio deliberately leaves Severity, Occurrence, and Detection blank — those ratings depend on your team's scales and real data, and shouldn't be guessed by AI. Once you fill them in, the tool computes them for you:
A row is flagged as owing a Recommended Action when either of two things is true. The flag appears in the editor and prints in both exports as “Action required” with the reason, so an empty Recommended Action cell always means answered rather than overlooked.
Flagged causes are collected under Action items, with a suggested action written for each one. That page is the only place an action is written or changed — there is no Recommended Action box in the editor, because an action is a decision about risk and a text field in the middle of a rating screen invites it to be answered in passing, or skipped and never returned to. Accept an action and it is written into the document; put it off; or delete it if the cause genuinely needs none. A banner follows you around the app while any are unanswered.
Lower a score later and the action stops printing on your exports without being deleted: the item moves to No longer flagged and comes back exactly as it was, wording included, if the ratings go back up. Only you can delete one for good.
Why 150 rather than 100: Action Priority High already flags a large share of rows on its own. A threshold of 100 roughly doubles what gets flagged, and most of what it adds is already rated AP Medium — the same information twice, which trains people to ignore flags. 150 still catches the case Action Priority is blind to, a low-severity failure that happens often and is hard to detect, without burying it.
The two triggers answer different questions and neither replaces the other. Action Priority asks must this be acted on, weighted so severity dominates. The RPN threshold asks is this noisy. A safety failure caught reliably can be AP High at an RPN in the thirties; a cosmetic defect that happens constantly can pass RPN 100 and still be AP Low.
Action Priority ranks each cause using all three ratings together, rather than by multiplying them. Multiplying ranks badly. A rare, well-detected safety failure scores 9×2×2 = 36. A frequent cosmetic one scores 4×3×3 = 36. Identical RPN, nothing like the same risk — and a team working top-down through an RPN column would give them equal attention.
AP weights Severity first, then Occurrence, then Detection. A high-severity item therefore stays high priority even when you detect it well, because detecting a hazard reliably is not the same as removing it.
AP stays blank until Severity, Occurrence and Detection are all entered, and recalculates the moment any of them changes. RPN is still exported alongside it, because plenty of customer requirements continue to ask for it.
Each rating attaches to a different part of the row, which is why the exported table merges the way it does: Severity comes from the effect, so it spans the whole failure mode. Occurrence and Detection belong to the individual cause and its controls, so they sit on the cause row — and so does the AP computed from them. Two causes of the same failure mode can, and often should, end up with different priorities.
Pick the quality standard you work to — ISO 9001, AS9100, ISO 13485, and more — or choose Other and type any customer-specific standard. Each built-in standard carries its own analysis focus, so the draft reaches for what that standard expects: foreign object damage, lot traceability and special-process control under AS9100; sterility, biocompatibility and labeling under ISO 13485; operator exposure and guarding under ISO 45001. A standard you type yourself is used by name only.
Only one thing is metered by the month for cost reasons: AI drafts. Writing requirements by hand is never limited, and assembling an FMEA from processes you already have costs no draft at all. Everything a Free account produces is usable — there is no watermark and nothing is crippled; the paid line is the editable spreadsheet and the volume.
Because it is not the document’s to edit. One process, one analysis, shared by every part that uses it — so it is edited in the process library and every document follows. On an FMEA you set the line numbers and choose which processes it contains.
No. It produces the qualitative analysis — failure modes, effects, causes, controls, and recommended actions — and leaves the numeric ratings for your team to set. RPN and Action Priority then calculate automatically.
Two things, separately. Each AI draft in the process library counts one — that is the only action that costs us anything to run. Each new FMEA counts against the monthly document allowance, whether you assembled it from a part family or from scratch. Writing requirements by hand, editing anything, and re-exporting are all free and unlimited.
They are updated automatically. The edit is pushed into every FMEA that uses that process as soon as it saves — you do not have to open them, and you never remove the process and add it back. Your recommended actions and the line number that operation has on each part are kept, since those belong to the document rather than to the shared process.
Yes — every field and rating is fully editable, with autosave. Add, edit, or delete any row.
A real Excel .xlsx workbook (not a CSV or an XML file that triggers a warning), with merged cells grouping each process, requirement, and failure mode.
Yes — a free, no-signup tool analyzes one process and shows the result on screen. That is the same unit of work the library is built from, so what you see is exactly what a finished process looks like. Create an account to keep processes in a library, edit them, and assemble them into FMEAs.
Email support@dropfeed.io and we'll get back to you.
← Back to Dropfeed