Integrate a natif.ai Splitting Process in Make.com#
This guide will demonstrate how to use Make.com scenarios to leverage the power of our AI-powered document splitting system with human verification at self-defined confidence thresholds.
To prevent timeouts and handle longer processing times without errors, the flow is divided into two scenarios which are connected Make.com 's built-in data storage.
We'll create scenarios that ingest documents, process them through natif.ai and add them to DocuWare.
How to build our Scenarios#
As a way to simplify the process, we have created two downloadable blueprint with a pre-configured basic layout. After connecting your natif.ai account and optionally your DocuWare and email accounts, the template scenario is almost ready to run successfully. Some model configurations will still be required, but this guide will walk you through the process step by step.
You can download our example scenarios as JSON files here and import them into your Make.com account:
Preparation#
In the first step, a Data Store must be created in Make. The Data Store is used as an intermediate medium through which our two scenarios communicate with each other. Make sure to allocate sufficient MB for your use case (this value can be adjusted later if needed).
In the "Specification" create the following "Items":
-
processing_id of type Text (required)
-
human_notified of type Boolean
Leave all other settings as default.
Scenario 1: Process Documents With natif.ai and Store Their ID in the Data Store#
The first scenario, (1) fetches attachments from your emails, (2) processes them with natif.ai, and (3) stores the returned processing_id in the Data Store, to be used by the second scenario. Here is a step-by-step guide:
The scenario starts with the source from which you retrieve your documents. In our example template, this source is the "Watch Email" module. This module monitors all incoming emails in the connected mailbox within the folder named "Make"
All specifications here can be customized to fit your specific use case.
Next, an Iterator extracts the attachments from the email.
This is followed by a natif.ai "Upload a Document" module. You need to configure the natif.ai plugin by linking it to your account on <https://platform.natif.ai> and select the splitting workflow that will process the incoming documents. To do this you will need an API key, you can find the steps needed for this here.
The final step of this process stores the received processing_id in the previously created data storage.
With this, the first step is complete: we have received a document, extracted it, sent it to natif.ai via Make.com and stored the processing_id in the data storage.
Scenario 2: Check the processing status, decide whether manual human verification is required, and store the split documents in DocuWare#
This scenario is much more complex than the first one. The goal of this step is to regularly check the data storage, retrieve the processing IDs that are still pending (not yet completed) and get the current status from natif.ai.
Once the processing is complete, the Make.com workflow generates an array of all split-point confidences returned by natif.ai, identifies the lowest value and compares it with the threshold you have specified. If the confidence is below your chosen threshold, a human is contacted to manually review the split points.
If the confidence is above your threshold or if the document has already been verified by a human, the split documents are stored in the location you have chosen, in this case DocuWare.
In the first step, a "Search Records" is performed in the data storage to find all entries with a processing_id .
In the next step, a natif.ai "Make an API Call" module is used to query the current status of the selected processing_id .
This is followed by a combination of an Iterator, Repeater and Numeric Aggregator that gathers all split-point confidences and identifies the lowest value for each input document.
Next, a Router is used, which has two decision branches with filters:
-
The first path (labeled High Confidence) is followed when the lowest split-point confidence in the document is still above 0.7. This means that no further human verification is needed and the document can be stored.
-
The second path (labeled Low Confidence) is followed when the confidence of the uncertain split-point is below 0.7.
Hint: You can adjust the threshold for human verification at any time in the designated router to trade off manual effort and quality of the split documents.
High Confidence Path#
If the lowest confidence is higher than the specified threshold, a natif.ai "Make an API Call" is triggered, which calls /processing/results/{{7.data.processing_id}}/sub-pdfs. This request returns a list of all links to the sub-PDFs.
In the next module, these links are passed through an Iterator and then individually called in the next natif.ai "Make an API Call".
This way, we retrieve the split documents one by one, which can optionally be stored in a file cabinet in the following DocuWare module. It is important that "Data" refers to the "Body" of module 22.
The final step in this process deletes the record from the Data Store after the file has been successfully saved.
Low Confidence Path#
If the lowest confidence is below the threshold, a natif.ai "Make an API Call" module follows. This module checks via /processing/results/{{7.data.processing_id}}/document-splitting/verification whether the document has already been reviewed by a human.
This is crucial for the following router, which determines whether the document has been verified or not. If the document has been verified, the same process continues as described above in the High Confidence Path.
If the document has not yet been verified, the request moves to the next router to check whether a notification has already been sent to a human. This second router prevents the person from receiving the same email repeatedly for the same document. That’s why a boolean value in the Data Store ensures that this email is only sent once. If necessary, you can build workflows to send reminders at regular intervals, or use a fully different medium than email to notify users about manual verification tasks.
If both verified and notified are false, an email should be sent to the assigned person. The first step is a "Generate Share Token" module, which creates a share token for this document.
In the subsequent "Send an Email" module, an email is sent to the designated recipient. The example text in this module is as follows:
Dear Natif.ai user,
Our AI model has automatically split a document within your Make.com workflow, but due to a too low confidence, manual verification is required.
Please review the split document at the following link:
Your assistance ensures the document is correctly processed.
Best regards
As the final step, the boolean value human_notified in the Data Store is set to true, ensuring that no additional email is sent upon subsequent runs.
Finished#
Your Make workflow, integrating our natif.ai splitting workflow and DocuWare, is now ready to be used. To test it, simply run the scenario, send any number of documents to your starting point and observe your output tray.
Notes for Future Production Use#
- When using email as an input source, ensure that images from signatures are not sent to natif.ai. This can be achieved with a filter based on file name, file size or a parser module
- You can adjust the threshold for human verification at any time in the designated router to match your requirements
- It is recommended to implement a flow that sends a follow-up verification email after a certain time interval if the initial email is overlooked. This can be achieved by:
- Using a countdown value in the datastore that decreases with each skiped email flow
- Storing a date variable in the database that triggers another email when a set time has passed
- Utilizing a third-party module to manage the countdown