Staff upload new SOP PDFs that must be chunked for RAG automatically. Which Functions trigger starts that work on upload?
Select an answer to reveal the explanation.
Short Explanation
You can let an Azure Functions blob trigger start the chunking pipeline as soon as a new SOP PDF lands in its configured storage location. That way, your upload is enough—staff don’t need to remember a second manual step.
Full Explanation
Staff-uploaded SOP PDFs that must be chunked for RAG automatically should start from the storage event itself. An Azure Functions blob trigger can bind to the container or path where SOPs land and run the chunking pipeline when a new blob arrives. This keeps the workflow simple: staff upload to the known location, and each new SOP can enter the municipal knowledge index without a second manual step. An HTTP trigger that requires staff to start the pipeline after every upload is less reliable because a forgotten call leaves the SOP unindexed. A Service Bus session receiver with no link to Blob Storage uploads does not observe blob creation; sessions can order messages, but another process would have to enqueue a message when an upload occurs. Polling Redis keys that never change when SOPs are uploaded also provides no signal that a new blob exists, so the pipeline will not start from that event. Exam caveat: the blob trigger responds to uploads that match its configured container and path; large PDFs can also encounter host-plan execution timeouts. Practical check: upload a test SOP PDF and confirm that the Function runs, chunks are written, and embeddings or index updates follow. If path filters are configured, also upload a file outside the matching path or extension and confirm it is ignored.