I am building a Make scenario that automatically reviews Certificates of Insurance (COIs) for Window Nation.
My workflow currently:
OneDrive (Watch Files/Folders)
HTTP (Download File)
OpenAI (Analyze Images - Vision)
OpenAI (Upload a File)
OpenAI (Generate a Response)
Router
Move/Rename files based on the review result
The goal is for OpenAI to:
Review the uploaded COI.
Compare it against a Sample Window Nation COI.
Determine whether the COI is:
APPROVED
NOT APPROVED
NEEDS HUMAN REVIEW
Generate a correct file name when approved.
Route the file to the correct OneDrive folder.
What is the problem & what have you tried?
I am experiencing a few issues:
OpenAI is sometimes using the wrong date from the COI. The COI contains multiple dates, and I need it to use the certificate completion date in the upper-right corner, not the policy effective dates.
When OpenAI returns “NEEDS HUMAN REVIEW”, the file is not always being moved to my “Needs Human Review” folder, even though I have a router configured for that status.
I am also working on automatically renaming approved files using the “CORRECT FILE NAME” value returned by OpenAI.
I have already:
Revised my OpenAI prompts multiple times.
Added routing filters for APPROVED, NOT APPROVED, and NEEDS HUMAN REVIEW.
Updated the file naming logic.
Tested multiple COI documents.
Error messages or input/output bundles
STATUS: NEEDS HUMAN REVIEW
FIRST NAME:
LAST NAME:
BUSINESS NAME:
POLICY TYPE:
EFFECTIVE DATE:
EXPIRATION DATE:
CORRECT FILE NAME:
ZOHO SEARCH NAME:
ISSUES:
Unable to verify required information from the COI.
Hi Jenna - for this, I would separate the AI extraction problem from the Make routing problem.
The completion-date issue usually needs a strict output contract that names the field by location and meaning, not just “date”, because the COI also has policy effective and expiration dates. Then the router should use a normalized status field, so only exact APPROVED, NOT APPROVED, or NEEDS HUMAN REVIEW values reach the file-action routes.
If this is still open, the first slice I would test with fake or redacted COIs is:
define the JSON fields for certificate completion date, policy dates, status, correct file name, and issues;
test a few COIs where multiple dates appear;
normalize the status before the router filters;
dry-run the OneDrive move/rename decisions with a small review log before changing live folders.
That should show whether the prompt/schema, router filters, or file-operation mapping is the weak point without needing live OneDrive or OpenAI access first.
Hello @Jenna.Harris , welcome to make.com community, I have worked and have experience with Make.com and l will love to collaborate with you on this you can schedule a call Here and you can checkout my upwork profile Here, for my pastworks and certifications
Your scenario structure looks good, but COI processing with AI can be tricky because documents often contain multiple dates and inconsistent layouts. The date-selection issue is usually solved by making the extraction instructions much more explicit (for example, telling OpenAI to only use the certificate completion date in the upper-right corner and ignore policy dates unless specifically requested).
This is the type of document-processing workflow we build at Flowbird Ltd, and we’re also a Make Partner. If you’d like help reviewing the scenario, prompts, or routing logic, feel free to DM me or email me at: [email protected]
Hi @Jenna.Harris! I would love to help you with your automation. I just checked the public link for your scenario it should not be a challenge to fix it.
We are a small team of make.com experts and have developed plenty of complex integrations. This project should not be a challenge to us.
This is a good fixed-scope rescue job. I would not try to fix it only by adding more prompt text; I would separate extraction, validation and routing so Make has deterministic status fields.
The first paid block I would take:
inspect one APPROVED, one NOT APPROVED and one NEEDS HUMAN REVIEW COI plus your current scenario;
change the OpenAI step to return strict JSON with certificate_completion_date, policy dates, status, correct file name and reasons;
add validation rules so the upper-right certificate completion date is preferred and policy dates are not accidentally used as the completion date;
fix the router filters so APPROVED / NOT APPROVED / NEEDS HUMAN REVIEW always land in the right OneDrive folder;
add a small run log so each file has source file, extracted fields, status, target folder and error reason.
I would keep this as a contained paid diagnostic/fix before touching production folders. If you can share the public scenario link plus 3-5 redacted sample COIs, I can confirm the exact fixed price and timeline. As a starting point, I would quote USD 300 for the extraction/routing fix if the scenario and samples are ready; usually 1-2 working days.
I would make the AI step produce one strict review object, then let Make route only from that object.
For the date issue, I would not ask the model for “the date” in prose. I would require fields like certificate_completion_date, policy_effective_date, policy_expiration_date, plus a short evidence snippet and confidence flag. If completion date is missing or ambiguous, route NEEDS HUMAN REVIEW instead of guessing, then Move/Rename from deterministic status and filename fields.
TinyOps Studio can quote a fixed $499 rescue pass for this: tighten the extraction schema, add the ambiguity guard, and prove approved/not-approved/human-review paths against 3-5 sample COIs. If this is still open, DM me one redacted sample COI and the filename pattern you want.
Your scenario structure looks good, the issues are in two specific places.
On the router not catching “NEEDS HUMAN REVIEW”: OpenAI is likely returning the status embedded in a longer string or with whitespace, so your exact match fails silently. Add a Set Variable module after OpenAI to normalize: {{trim(toUpper(your_status_variable))}}, then switch your router filters from Equals to Contains.
On the date issue: add a date_confidence flag (“high” / “low”) to your OpenAI output alongside certificate_completion_date. Any response with date_confidence: low automatically routes to NEEDS HUMAN REVIEW in Make - so you’re catching uncertainty deterministically instead of relying on OpenAI to self-report it.
Hi Jenna - all three issues actually share one root cause: the OpenAI step is handing Make free text, and the router/rename logic is brittle when it has to parse prose. Fix that and the three problems mostly collapse into one.
Wrong date: vision models are unreliable at spatial cues like “upper-right corner,” so don’t anchor on position - anchor on the form’s label. A standard COI is an ACORD 25 form, and the date you want is the field labeled “DATE (MM/DD/YYYY)” at the top of the certificate, not the effective/expiration dates in the coverage rows. Tell the model exactly that: “Return the value of the DATE (MM/DD/YYYY) field at the top of the ACORD certificate; ignore all policy effective and expiration dates.” Having it also echo the label it pulled the date from makes errors obvious.
NEEDS HUMAN REVIEW not moving: this is almost always a filter mismatch. If STATUS comes back embedded in a larger blob, or with different casing/spacing than your router filter (“NEEDS HUMAN REVIEW” vs “Needs Human Review”, a trailing space, a period), the filter silently fails and the bundle falls through every route and just stops - exactly the “not always moved” symptom. Two fixes: make STATUS a clean field (below), and add a final fallback route with no filter that sends anything unmatched to the Needs Human Review folder, so nothing ever silently dies.
Renaming: the CORRECT FILE NAME value can contain characters OneDrive rejects in a filename ( / \ : * ? " < > | ). Strip those right before the Move/Rename module, or you’ll get intermittent failures on exactly the files whose names include them.
The unifying fix: have the OpenAI step return JSON, not prose. Use response_format / JSON mode so it returns a strict object - status, completion_date, correct_file_name, issues - then your router filters on the status field exactly and the rename maps correct_file_name directly. No more parsing a paragraph, and the three issues mostly disappear at once.
Hi! I’m Misha, an automation and LLM integration expert. Your scenario is already close, but the core issue is reliability in the AI decision layer. I can rework the OpenAI extraction logic so it explicitly identifies the certificate completion date from the upper-right corner instead of policy dates, enforce structured JSON outputs for consistent routing, fix the Make router conditions causing “NEEDS HUMAN REVIEW” files to miss the correct OneDrive folder, and implement bulletproof file naming based on validated COI data. The result is a production-ready COI review system that automatically classifies documents, routes them correctly, generates compliant filenames, and eliminates the manual verification bottleneck that’s currently slowing down your workflow.
Hi Jenna — both issues trace to one root cause: the scenario trusts a nondeterministic model output as if it were deterministic.
Wrong date: constrain OpenAI to a fixed output schema and anchor the field to “the boxed completion date, upper-right” (not “effective date”), so it can’t drift to a policy date.
Router missing NEEDS HUMAN REVIEW: almost always a whitespace/case/type mismatch between the status string the model returns and the filter condition — they look identical but don’t compare equal.
Both quick. The bigger win is a confidence gate, so a low-certainty COI goes to human review instead of a guess. My background is production systems, where confident-but-wrong output is the expensive failure mode.
One question: is this already approving real COIs in production, or still in testing?
What is your goal?
What is the problem & what have you tried?
Error messages or input/output bundles
Create public scenario page
Walkthrough Call: Click