From 'Apply now' to a linked, placed record in five small steps
Five Make scenarios turn an Apply-now click into an application linked to its candidate, visible to the employer and placed on the right tracker, resolving the candidate through three lookups, and placing each application exactly once.
Where this applies
Recruiting, admissions and programme-intake teams: anywhere an applicant's click has to become a linked record, visible to the right people and placed on the right tracker.
- small scenarios, handing off through status
- 5
- lookups to find the candidate
- 3
- runs, two errors, one cause
- 93
The problem
A candidate presses Apply now. After that three jobs fall to staff: link the application to the right candidate, give the employer's team visibility of that candidate, and add the application to the tracker where interviews are planned. Each step done by hand is a chance to get it wrong.
The inputs are untidy. Names arrive in two formats, some applications are created by someone other than the candidate, and the person who clicks does not always have the same name on the platform as on their record. And each placement is a place for duplicates: a candidate on a tracker twice, or an application linked to the wrong person.
What we built
One entry point that does the setup
The click creates a subitem, and the first scenario turns it into a proper application (named applicant, role and opening) linked to the candidate, the employer and the right staff member. It failed twice when an automation-created subitem arrived with a system user id, so the first filter now ignores anything not created by a real person.
Status columns as the hand-off
The first scenario finishes by setting two status columns to 'Assign Now' and 'Add Now'. Each fires its own scenario, so the steps stay small, readable and independently retryable (if the tracker step fails, the access step has already done its job), and the board shows staff exactly how far each application has got.
Employer access that cannot double-count
One scenario subscribes the employer's team to the candidates board and records the employer on the candidate. It writes the employer as the deduplicated merge of what is already there and what is new, so a candidate can have several employers and re-running changes nothing.
Finding out who applied
The router resolves the candidate with one GraphQL request holding three aliased lookups (by the name inside the application title, by the creator's email, and by the creator's name) and a fallback chain: an existing link first, then the title prefix, then email, then name. It writes the link only if the application has none yet, a candidate was resolved and the creator was not an automation, so it never fights another scenario.
Placing it on the tracker, once
The router looks for the candidate's existing tracker row by relation first and by name second. Found, it adds a subitem for this role and employer; not found, it creates the row, already linked, and then the subitem. Either way the application and subitem are linked to each other and the status flips to 'Added', so a re-run adds a subitem and never a second candidate. A fourth route files hospitality applications on their own board the same way.
Rows that arrive before the application
A small two-operation scenario covers tracker rows added before any application exists. It matches the new row's name to the candidates board and writes the relation only when a match is found, so it never writes an empty link.
The outcome
Across the five scenarios: 93 runs and 359 operations, with two errors: both from one cause in the entry scenario, both fixed by a single filter.
The small steps complete in two to five seconds; the router, which does the most, in thirteen to nineteen.
An application now arrives linked to its candidate, visible to the employer and placed on the tracker without anyone touching it, and the records link back to each other.
Where it stops
The router reads the applicant, role and employer out of the application's name, which is brittle if a role or employer name itself contains a dash or a caret. If no candidate can be resolved it still creates a tracker row, using the name as typed, but unlinked. One of the hand-offs writes its back-link with the wrong kind of id, so that link may not be set by that scenario; the router writes its own. None of them has an error handler, so a failure falls back on Make's default error behaviour.
Built with
- Make.com
- monday.com
- GraphQL API
- Webhooks
Patterns used
- Status-column hand-off
- Aliased lookups with fallback
- Merge and deduplicate
- Two-way links
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no