Using Flow, Prompt Builder, and Multimodal AI to Validate Partner Proof-of-Completion Files

A customer recently had a pretty common partner management problem.

Partners needed to submit a proof of completion before a rebate claim could be created. The proof was usually a PDF. Sometimes it was an invoice. Sometimes it was a completion certificate. Sometimes it was a document that looked right to a human, but still didn’t include the actual fields the business needed.

The required information was simple enough:

Date
Amount
Quantity
Product

So far, so good.

The problem was that “upload a file” is not the same thing as “submit a valid claim.”

A partner could upload a PDF with no amount. Or a screenshot with no product. Or a document that had the product and date, but no quantity. If we created the rebate claim immediately after upload, we would just be moving the validation problem downstream to an internal team.

That is usually where the process starts to get expensive.

The Standard Approach

The first instinct might be to build a custom Lightning Web Component.

You could create an LWC that accepts the file, calls Apex, sends the file somewhere for parsing, waits for a response, validates the result, and then creates the rebate claim.

That works.

But it also means you now own the user interface, the file handling behavior, the error handling, the Apex integration, and probably a few edge cases around Experience Cloud permissions.

For this use case, that felt heavier than it needed to be.

The better starting point was a Screen Flow hosted in the partner community.

Let Flow Handle the Upload

Salesforce already gives us a File Upload screen component.

That matters.

When a partner uploads the PDF from the screen flow, Salesforce creates the file in Salesforce Files. More specifically, you can capture the uploaded file’s ContentDocumentId from the File Upload component output and store it in a Flow text collection variable.

That ContentDocumentId becomes the handoff point.

We do not need to rebuild file upload from scratch. We do not need to recreate the standard Salesforce Files model. We just need to use the file that Salesforce already created and pass it into the next step in the process.

The first screen is simple:

Upload Proof of Completion
Accepted file types: PDF, PNG, JPG
Store uploaded Content Document IDs in a collection variable

Now we have the partner’s file inside Salesforce.

Then comes the interesting part.

Let the Prompt Read the File

This is where Prompt Builder becomes more than a text generation tool.

The prompt template can use a model that supports file inputs, including PDFs and images. That means the uploaded proof of completion can be passed into the prompt as grounding context, and the model can inspect the document for the fields we care about.

The prompt does not need to be clever.

In fact, it should be intentionally boring.

Something like:

You are reviewing a partner proof-of-completion document.
Extract the following fields from the uploaded file:
- completionDate
- amount
- quantity
- product
Only return values that are clearly present in the document.Do not infer or guess.
If a required field is missing, include the field name in missingFields.
Return the response in this JSON format:
{  "completionDate": "",  "amount": "",  "quantity": "",  "product": "",  "missingFields": []}

Notice the important instruction:

Do not infer or guess.

For this process, a guessed value is worse than a blank value. If the PDF does not clearly show the amount, we want the partner to fix the submission before a claim is created.

Return Structured Data to Flow

Once the prompt runs, the response needs to be useful to Flow.

That means the output should be structured. Ideally, the prompt returns predictable fields that can be mapped into Flow variables:

completionDate → Date variable
amount → Currency or Number variable
quantity → Number variable
product → Text variable or Product lookup helper value
missingFields → Text collection or delimited text value

Now the flow has something it can reason over.

This is the key shift.

We are not asking AI to “approve” the claim. We are asking AI to extract the values needed for the existing business process.

Flow still owns the process logic.

That is a much better division of responsibility.

Add the Decision Element

After the prompt action returns its response, the flow checks missingFields.

If missingFields is not blank, the user goes back to the upload screen.

The screen can display a message like:

We could not find the following required information in your proof of completion:
Amount
Quantity
Please upload a corrected document that includes all required fields.

Now the partner gets immediate feedback.

No internal review queue.
No manual email back to the partner.
No half-created rebate claim sitting in a pending status because the proof was unusable.

If missingFields is blank, then the flow continues.

Create the Rebate Claim

At this point, the flow has the values it needs:

Date
Amount
Quantity
Product
Uploaded proof file

Now the flow can create the rebate claim record.

Depending on the data model, this could be a custom object like Rebate_Claim__c, with fields such as:

Completion_Date__c
Claim_Amount__c
Quantity__c
Product__c
Partner_Account__c
Status__c

The flow creates the claim and then links the uploaded file to the claim record using ContentDocumentLink, if the file was not already uploaded directly against that record.

That last part is important.

If the rebate claim does not exist yet when the partner uploads the file, the file may need to be linked to the newly created claim after the record is inserted. The ContentDocumentId captured earlier is what makes that possible.

Why This Pattern Works

The nice thing about this architecture is that every tool is doing the job it is good at.

Flow handles the guided user experience.

The File Upload component handles the upload.

Salesforce Files stores the document.

Prompt Builder extracts structured information from the PDF.

Flow validates the result.

The rebate claim is only created after the required fields are present.

No custom LWC required.

That does not mean an LWC would be wrong. There are absolutely cases where a custom component makes sense, especially if the upload experience needs to be highly customized.

But for this use case, the screen flow is easier to maintain, easier to hand off to admins, and easier to change later when the business inevitably adds one more required field.

And they will.

A Few Practical Considerations

There are still some details worth thinking through.

First, be clear about whether the partner can upload multiple files. If the business process expects one proof of completion, make the UI enforce one proof of completion.

Second, keep the prompt strict. The model should extract, not invent. The phrase “do not infer or guess” should be doing real work here.

Third, think about product matching. If the document says “Model X-1000” but Salesforce stores the product as “X1000 Commercial Unit,” you may need a second step to normalize or match the extracted product value.

Fourth, consider storing the raw AI response. That can be useful for troubleshooting when a partner says, “The document had the amount,” but the prompt did not find it.

Finally, keep a human review path. AI-assisted validation is a great first pass, but there should still be a way to route weird edge cases to a person.

The Takeaway

This is a good example of using AI inside an existing Salesforce process without turning the whole process over to AI.

The partner still uploads the proof.

Salesforce still stores the file.

Flow still controls the business logic.

The rebate claim still gets created using normal Salesforce automation.

The only difference is that Prompt Builder helps read the document before the claim is created.

That is the sweet spot.

Use the LLM for the part that used to require a person to open the PDF and look for four fields.

Use Flow for everything else.