Tenant application screening with Make, Airtable and Mindee

Part 1 · 10 min

Airtable base

You copy the ready-to-use base, check one setting, then create your first listing.

1.1 Copy the base

1. Open the Airtable base link provided with this tutorial.
2. Click Copy base, then choose the workspace where you want to add it.
   SCREENSHOT
3. The base opens in your account. It already contains the French document pack and an applicant form.

1.2 Explore the tables

The applicant form and two interfaces complete the base: Targeted review, to check documents, and Dashboard, to track activity. SCREENSHOT

| Table | What it contains | Do you edit it? |

| Settings | General settings: confidence threshold, maximum document age, Mindee model IDs | Yes, in part 4 |

| Document types | Accepted document types, with their category (Identity, Address, Employment, Income) | Rarely, see part 8 |

| Listings | Your listings: rent, charges, income requirements | Yes, for each listing |

| Applications | One record per application, with its status and reason | Yes, to read the results |

| Documents | One row per document read, with the extracted values and their confidence level | Yes, to review documents |

1.3 Check Settings

Open the Settings table. It must contain a single row, named "Configuration". SCREENSHOT

Warning. Delete any empty row: Make would read the wrong row and all your settings would be empty.

1.4 Create your first listing

In Listings, create a row and fill in:

| Field | Example | Role |

| ID | T2-LYON7 | The listing name, chosen by the applicant in the form |

| Address detailed, ZIP Code, City | 12 rue de Marseille, 69007, Lyon | The property address |

| Rent without charges, Charges | €680, €70 | Rent including charges is calculated automatically |

| Rent multiple | 3 | Income must be at least 3 times the rent including charges |

| Payslips required | 3 | Number of payslips required |

| Tax income tolerance | 25% | Accepted gap between the tax notice and the payslips |

| Tax document required | Checked | The tax notice is required |

| Listing status | Available | Switch to Rented once the property is let |

To follow this tutorial with the demo set, create a listing at €750 including charges.

Part 2 · 40 min

Data-extraction setup

You create seven models, one per document type read in detail. Each model reads three or four fields. You paste the guidelines provided; Mindee does the rest.

2.1 Create a model extraction in Mindee

1. In Mindee, create a new model from scratch, not from the catalog. By describing what fields you want to extract.
   SCREENSHOT
2. Name it exactly as in the table in step 2.3, for example TS – Payslip FR.
3. Enable the Confidence Score option. Without it, no confidence level is returned and everything goes to review.
   SCREENSHOT
4. Leave RAG disabled.

2.2 Check the generated fields

For each field, check its title, description and guidelines, then check the technical name Mindee generates from the title. SCREENSHOT

Warning. The technical name must match the table exactly: holder_name, surname, given_name, reference_date, amount, reference_number. A different name, even by one letter (given_names instead of given_name), breaks the Make scenario without showing an error: the field simply arrives empty.

Rules common to all models:

• Guidelines in English, French labels quoted between « ».
• A missing value stays empty: never an inferred value.
• Numbers (reference_number) are returned without spaces.
• Multiple holders are separated by " ; ".

2.3 The seven models

| Model | Name | reference_date | amount | reference_number |

| TS – Payslip FR | holder_name: the employee | End of period, not the payment date | Net pay before tax | – |

| TS – Utility bill FR | holder_name: the contract holder | Issue date | – | Customer number, otherwise billing account |

| TS – Rent receipt FR | holder_name: the tenant(s) | End of period; month only = last day | Total paid, rent + charges | – |

| TS – ID card | holder_name: the holder | Expiry date, front or back | – | Card number |

| TS – Passport | surname + given_name | Expiry date | – | Passport number |

| TS – Driver license | surname (field 1) + given_name (field 2) | Field 4b | – | Field 5 |

| TS – Tax return FR | holder_name: the declarant(s) | Issue date | Declarant 1 salaries (box 1AJ), otherwise professional income | Declarant 1 tax number |

Start with TS – Payslip FR. Test it with Mindee's Live Test on the payslips from the demo set, compare with the expected values, then build the other six models the same way.

2.4 The guidelines to paste

The guidelines below are the ones that needed the most adjustments.

TS – Passport, surname

Description: Surname of the passport holder.
Guidelines: Use the surname field (« Surname », « Nom »). Return it as printed. If it is unreadable, use the surname encoded in the first line of the machine-readable zone (the part before "<<"). Never use the given names.


TS – Passport, given_name

Description: Given names of the passport holder.
Guidelines: Use the given names field (« Given names », « Prénoms »). Return all of them as printed. If it is unreadable, use the given names encoded in the first line of the machine-readable zone (the part after "<<"). Never use the surname.


TS – Driver license, surname

Description: Surname of the licence holder from field 1, in full-size capital letters only (e.g. "MARTIN", never "MARTINA" or "AMARTIN").
Guidelines: Use field 1 (« 1. »). The surname is often framed by tiny decorative letters printed smaller and higher than the name, touching its first or last letter. Read only the full-size capital letters. Example: if field 1 looks like "ⁿMARTINᵃ", return "MARTIN". Do not add any letter that is smaller than the others. Never use the line of characters at the bottom of the licence, and never use field 2.


TS – Driver license, given_name

Description: Given names of the licence holder from field 2, in full-size letters only.
Guidelines: Use field 2 (« 2. »). The given names may be framed by tiny decorative letters printed smaller and higher than the name, touching its first or last letter. Read only the full-size letters and do not add any letter that is smaller than the others. Return all given names. Never use the line of characters at the bottom of the licence, and never use field 1.


TS – Driver license, reference_number

Description: Licence number printed in field 5 on EU licences (e.g. "13AA00002") or field 4d (« DLN ») on US licences, never the long line of characters at the bottom of the licence.

TS – Utility bill FR, holder_name

Description: Name of the contract holder.
Guidelines: Use the contract holder (« Titulaire du contrat », « Titulaire », or the customer the bill is addressed to). Never use the supplier, the co-signatory of a payment mandate or a third-party payer. Return first name(s) then last name, without any civility or title (M., Mme, Monsieur, Madame…). Names are often printed last name first (e.g. « DURAND Camille », « M. DURAND Camille »): reorder them as first name(s) then last name. The last name is usually the part in capital letters. Keep the case, accents and hyphens as printed. If several holders are named, return all of them separated by " ; ".


TS – Tax return FR, amount

Annual salaries of declarant 1 only, as printed in box 1AJ ("Salaires et assimilés", "Traitements, salaires" – declarant 1 column). Do not take box 1BJ (declarant 2), the household total, the "revenu fiscal de référence" or the "revenu brut global".
If box 1AJ is absent or empty (self-employed taxpayer with no salary), return declarant 1's professional income instead: non-commercial profits (BNC, boxes 5HQ, 5KU or 5HP) or commercial profits (BIC), as printed.
Return a number without currency or spaces. Leave empty if neither is printed.


What the models don't do. They copy what is printed. Reordering names, removing a title or changing the case does not work well through guidelines: Make handles it. Don't insist on the guideline if the Live Test shows « DURAND Camille » or « M. Paul MARTIN »: that's expected.

Warning. The models look very similar in the Mindee interface. Check the model name at the top of the screen before saving a change.

Part 3 · 15 min

Classification setup

The Split (Mindee classification model) is the only model Make calls. It cuts each file into documents, recognizes their type, then sends each document to its extraction model. A file containing three merged payslips therefore gives three documents, in a single call.

3.1 Create the Splitter (Mindee classification model)

1. In Mindee, create a Split model named TS – Split.
   SCREENSHOT
2. Add the 21 classes below. Their name must be exactly the Code in the Document types table: in English, lowercase, with no spaces or accents.
3. Paste the description of each class.
   SCREENSHOT

Warning. A misnamed class (Payslip instead of payslip) is not matched by Make to any document type: the document arrives without a type and must be reviewed by hand.

3.2 The class descriptions

id_card: National identity card (« Carte nationale d'identité » or a foreign ID card), in card format, front and/or back. Not a passport, not a driving licence, not a residence permit.
passport: Identity page of a passport, with a two-line machine-readable zone at the bottom.
driver_license: Driving licence (« Permis de conduire »): EU card with numbered fields 1 to 9, or a US driver license.
residence_permit: Residence permit of a foreign national (« Titre de séjour », « Carte de séjour », « Carte de résident », « Récépissé de demande de titre de séjour »).
rent_receipt: Rent receipt (« Quittance de loyer ») issued by a landlord or an agency to a tenant, confirming payment of rent and charges for one period. Not an energy, water or telecom bill.
utility_bill: Bill from an energy, water, internet or phone supplier (« Facture ») addressed to a customer, with a consumption or subscription and an amount due. Not a rent receipt, not a delivery note or a shop receipt.
landlord_reference: Letter from a previous landlord certifying that the tenant paid the rent (« Attestation du précédent bailleur »). A letter, not a receipt for one period.
host_certificate: Sworn statement by a person who hosts the applicant (« Attestation d'hébergement », « Attestation sur l'honneur »).
property_tax_or_deed: Property tax notice (« Avis de taxe foncière ») or property deed (« Titre de propriété », « Attestation de propriété »).
employment_contract: Employment contract (« Contrat de travail », CDI, CDD), usually several pages with numbered articles and signed by both the employer and the employee.
employment_letter: Short letter from an employer confirming current employment (« Attestation employeur », « Attestation de travail », « Promesse d'embauche »), usually one page signed by the employer only. Not a full employment contract.
company_registration: Business registration document (« Extrait Kbis », « Avis de situation SIRENE », « Certificat d'inscription au répertoire INSEE », « Extrait du répertoire des métiers »).
professional_card: Professional card of a regulated profession (« Carte professionnelle »).
student_card: Student card or enrolment certificate (« Carte d'étudiant », « Certificat de scolarité »). Not a scholarship award notice.
payslip: A single French payslip (bulletin de paie) for one employee and one pay period. Each pay period is a separate document, even when several payslips follow each other in the same file.
tax_return: French income tax notice (« Avis d'impôt sur le revenu », « Avis de non-imposition ») issued by the tax administration, possibly over several pages. Not a property tax notice.
bank_statement: Bank account statement listing dated transactions and a balance over a period (« Relevé de compte »). Not a bank details sheet (« RIB ») that only shows the holder, the IBAN and the BIC.
benefits_pension: Statement of pension, retirement or social benefits (CAF, France Travail, CPAM, retirement fund).
scholarship: Scholarship award notice (« Avis d'attribution de bourse », CROUS).
accountant_certificate: Certificate from a chartered accountant about a self-employed person's income (« Attestation de l'expert-comptable »), or annual accounts (« Bilan »).
unknown: Any document that matches none of the other classes: shop receipts, delivery notes, bank details sheets (RIB), unrelated letters.


3.3 Chain the models

From the Split's Utility Configuration page, link seven classes to their extraction model:
SCREENSHOT

| Class | Chained model |

| id_card | TS – ID card |

| passport | TS – Passport |

| driver_license | TS – Driver license |

| rent_receipt | TS – Rent receipt FR |

| utility_bill | TS – Utility bill FR |

| payslip | TS – Payslip FR |

| tax_return | TS – Tax return FR |

The other fourteen classes, unknown included, stay without a model: the document is only recognized, which is enough for application completeness and costs fewer credits.

3.4 Test the Splitter

Run a Live Test on three files from the demo set:
SCREENSHOT MINDEE

1. The PDF merging three payslips (ref. FR - d2_payslips): you should get three payslip ranges, each with its values.
2. A rent receipt (ref. FR - d2_quittance) and a utility bill (ref. FR‑d3_utility_bill_internet): each should receive its own class.
3. Bank details (IBAN/RIB) (ref. FR‑d3_rib): it should come out as unknown, not bank_statement.

Part 4 · 5 min

Settings

You copy your Mindee model IDs into Airtable. Make reads them for each application: no ID is entered in the scenario.

4.1 Copy the Model IDs

1. In Mindee, open each model and copy its Model ID.
   SCREENSHOT
2. In Airtable, open the "Configuration" row of Settings.
   SCREENSHOT
3. Paste each ID into its field:

| Settings field | Mindee model |

| model_split | TS – Split |

| model_id_card | TS – ID card |

| model_passport | TS – Passport |

| model_driver_license | TS – Driver license |

| model_rent_receipt | TS – Rent receipt FR |

| model_utility_bill | TS – Utility bill FR |

| model_payslip | TS – Payslip FR |

| model_tax_return | TS – Tax return FR |

Only model_split is called by Make, since the Split itself sends each document to its model. The other seven are for reference: they let you find which model is chained to which class.

4.2 Check the two settings

| Field | Value | What it means |

| confidence_threshold | High | Information read with a High or Certain level is approved automatically. Below that, it is shown to you. |

| max_document_age_days | 90 | A bill, rent receipt or payslip dated more than 90 days ago is flagged "Document too old". |

Keep High: it's the threshold validated on the demo set. A lower threshold lets more reading errors through; a higher threshold sends more documents to review.

Part 5 · 15 min

Make scenario

You import the scenario, connect it to your base and your Mindee account, then schedule it. You don't have to write any formula.

5.1 Import the scenario

1. Open the scenario link provided with this tutorial and add it to your Make organization.
   SCREENSHOT
2. The scenario has 14 modules, in five blocks: trigger, splitting by Mindee, document type, confidence and rules, document creation in Airtable.
   SCREENSHOT

5.2 Create the connections

1. Open the first Airtable module. In Connection, click Add and authorize Make to access your base.
   SCREENSHOT
2. Open the Mindee module. Create the connection with your Mindee API key, found in your Mindee account.
   SCREENSHOT
3. The other Airtable and Mindee modules reuse these connections automatically. Check by opening them one by one.

5.3 Choose the base and tables

In each Airtable module, choose your base, then the table shown in the module name: Applications, Settings, Document types or Documents.

5.4 First run

1. Right-click the first module, Watch Records, then Choose where to start.
   SCREENSHOT
2. Choose From now on: only applications submitted from now on will be processed.
3. Click Run once. The scenario waits for a first application: you'll submit it in part 6.

5.5 Schedule the scenario

1. Click the clock on the first module, then Schedule settings.
   SCREENSHOT
2. Choose Days of the week, Monday to Friday, every 60 minutes, from 8 am to 8 pm.
3. Check that your Make organization's time zone is Europe/Paris, in the organization settings.
4. Turn the scenario on with the ON switch.

Each check uses Make operations, even without a new application. This setting uses about 280 per month.

If a document fails. The scenario doesn't stop: the document is created in Airtable with "Processing error" or "Record creation error", in Targeted review, and the rest of the application is processed normally. You review it by hand.

For those who modify the scenario. In a Make formula, never use quotation marks: type High, not "High", and use the space, emptystring and emptyarray keywords from the panel. In a formula sent to Airtable, on the contrary, quotation marks are required, and REGEX_MATCH({field}, "^value$") replaces the = sign. The appendix details the most common errors.

Part 6 · 15 min

The first test

You submit the five fictitious applications from the demo set and check that each one gets the expected status. If so, your tool is ready.

6.1 Submit application 1

1. Open the applicant form from Airtable.
   SCREENSHOT
2. Choose the €750 listing created in part 1, enter MARTIN and Maëlle-Gaëlle, then upload the documents of application 1 in their section.
   SCREENSHOT
3. Tick the consent box and submit.
4. In Make, click Run once so you don't wait for the next hour, and follow the application as it goes through.

6.2 Read the result

In Documents, each document of the application has its row. Look at four columns:

| Column | What it shows |

| Mindee verdict | The judgment on reading reliability and the rules: Auto-approved, Targeted review, Non-compliant or Unknown |

| Final verdict | The same, adjusted by your policy: type not allowed, type always reviewed, mismatch with the type declared by the applicant |

| Name confidence, Date confidence… | The confidence level of each piece of information: Low in red, Medium in orange, High in green, Certain in blue |

| Review note | What to check, in one sentence |

In Applications, the application shows its Status and its Reason.

6.3 Run the five applications

| Application | Applicant | What it tests | Expected status |

| 1 | Maëlle-Gaëlle MARTIN, manager on a permanent contract | The ideal application | Targeted review until the ID card is approved, then Approved |

| 2 | Henert PUDARSAN, developer on a permanent contract | Expired passport, rent receipt declared as a bill, shop receipt, merged payslips | Targeted review |

| 3 | Carmen MUESTRA, freelance translator | Double surname, no payslip | Targeted review "Income to be assessed by the agent", then Non-compliant once the income is entered |

| 4 | Paul MARTIN, logistics technician | Expired driving licence, income too low | Non-compliant |

| 5 | Victor DAMBARD, working student | Two payslips out of three, no tax notice | Incomplete |

For each application, enter the applicant's surname and first name in the form as shown in the table.

6.4 Read the Dashboard

Open the Dashboard interface. It shows the number of applications per status and the automation rate: the share of information approved without intervention. It's the indicator to track to measure the time saved.
SCREENSHOT

Part 7

Agent's daily work

Day to day, you only open the Targeted review interface and decide document by document with a single field, Review. SCREENSHOT

The four application statuses

| Status | What it means | What you do |

| Incomplete | A required document is missing: identity, address, employment, income, number of payslips or tax notice | You follow up with the applicant |

| Targeted review | At least one document or piece of information needs checking | You review the flagged documents |

| Non-compliant | An objective rule is not met: expired or too old document, insufficient income, too large a gap with the tax notice | You decide what to do next |

| Approved | Everything is complete, reliable and compliant | You move on to the viewing or the lease |

The reason "Income to be assessed by the agent" is a Targeted review case: the application is complete but no usable income was read, for example for a self-employed applicant without payslips.

The Targeted review interface

| Page | What it contains |

| Documents to review | The documents to check, including unrecognized documents |

| Other documents | The other documents of ongoing applications |

| Income to assess | The applications whose income you need to enter |

The Review field, your only lever

For each flagged document, open the file, read the Review note, then choose:

• Approved manually: the document is fine. It no longer counts as a document to review or as a non-compliance.
• Rejected: the document is not acceptable. It no longer counts towards the application's completeness.

The application status updates immediately.

Don't correct the extracted values. Changing a name or a date in Documents doesn't rerun any calculation: the Mindee verdict is calculated only once. Use Review.

Typical cases

| Case | What you see | What you do |

| Declared type different from the detected type | "Declared: utility_bill / Detected: rent_receipt" | If the document is fine, Approved manually |

| Different name | "Name mismatch" | Typo, maiden name, usual first name: Approved manually; otherwise Rejected |

| 15-year ID card | "Expired document" on a card issued to an adult between 2004 and 2013 | These cards remain valid 5 years beyond the printed date: Approved manually |

| Self-employed without payslips | Income to assess page | Enter the monthly income in Income entered by agent, based on the accountant's certificate or the tax notice |

| Joint tax notice | "Joint tax notice: gap not checked" | The gap with the payslips is not calculated. Compare it yourself if needed |

| Unrecognized document | Final verdict Unknown | Check what it is: Approved manually or Rejected |

| Document in error | "Processing error" or "Record creation error" | Open the file and review it entirely by hand |

| Same document submitted twice | Two identical rows, same name and same date | The tool doesn't detect it: set the duplicate to Rejected |

Part 8

Adapt the tutorial for you

All settings are made in Airtable, without touching the Make scenario or the Mindee models.

Per listing, in Listings

SCREENSHOT

| Setting | Default | When to change it |

| Rent multiple | 3 | Guarantor required or not, agency or owner policy |

| Payslips required | 3 | Ask for fewer for student housing, for example |

| Tax income tolerance | 25% | Wider if your applicants often change jobs; empty to skip the gap check |

| Tax document required | Checked | Uncheck if you don't ask for the tax notice for this listing |

For the whole agency, in Document types

SCREENSHOT

Each document type has two boxes:

• Allowed: uncheck it to refuse a document type. The French pack already refuses bank statements, which decree 2015-1437 does not allow landlords to request.
• Always review: check it to always review a type, even when well read. The residence permit is already set this way.

Warning. Leave Allowed checked on unknown. An unrecognized document must be reviewed, not refused: unchecked, the box would show it as "Not allowed".

The confidence threshold, in Settings

SCREENSHOT

Keep confidence_threshold on High. It was chosen on the demo set as the best balance between reading errors let through and documents sent to review. If you change it, run the five applications from part 6 again.

Going further

• Joint application, flatshare, guarantor. Not supported yet: see the limits table in part 0. Each person fills in their own form, and you match the household's applications and the guarantor's yourself.
• Joint tax notice. The tool recognizes it and flags that the gap is not calculated. The amount read is declarant 1's, who is not necessarily your applicant.