Skip to content

Approving a person should give them the right seat, team and boards

Eight Make scenarios turn an approval or a status change into a guest invitation, the right team memberships and the right boards: for candidates on several tracks, for the organisations that refer them, and for employers.

Onboarding & accessFlow2026

Where this applies

Any team that shares a monday.com account with outsiders (candidates, clients, partners, vendors) and needs each to see their own records and nothing else.

scenarios across three audiences
8
boards per provider team
4
reconciliation sweep interval
12 h

The problem

A programme that runs candidates, employers and referring organisations on one monday.com account has an access problem. Candidates must see their own record and nothing else; a referrer must see the candidates it referred and no one else's; everyone has to be invited, put in the right team and given the right boards.

Doing that by hand for every approval is slow and error-prone, and monday.com's native Make module cannot invite a guest or manage a team at all, so the work has to go through the API directly.

What we built

01

Direct API calls where the module stops

Inviting guests, creating teams and adding users to teams all go through GraphQL calls inside Make, because the native modules do not expose them. Everything else (reading items, writing columns) uses the modules, so each scenario stays readable.

02

One pattern, several tracks

Candidates on different tracks each have an approval and a team. The chain is the same: invite as a guest, add to the all-candidates team, write the new user onto the candidate's record, add to the track's team, set the track's status to 'Added'. A separate scenario handles a candidate who has already been invited and, if either of two screening answers is yes, adds them to a second, management-track team.

03

Errors handled by kind

A transient failure on a team add or a column write is retried three times at fifteen-minute intervals as an incomplete execution, so a brief outage becomes a delay and not a gap. Where the invite itself errors, the run stops quietly rather than carrying on with nobody to add.

04

Onboarding an organisation in one run

When a referring organisation's status is set to 'Invite Now', one scenario creates a private guest team for it, subscribes that team to four boards, invites each of its contacts, adds them to the organisation's team and a shared all-providers team, and emails each sign-up instructions. Contacts who were already invited are re-added to the teams rather than invited again. A second scenario writes the provider's team onto each candidate who named it, so it can see its own candidates and no one else's.

05

Employers from a form

When an employer submits an open role, a scenario finds or creates the employer, creates its guest team with access to six boards, invites up to four interviewer contacts, emails them what to do first, and links the employer and its contacts to the role.

06

Sweeps that check the real state

Two scheduled scenarios re-check, every twelve hours, that every candidate and every provider contact has a user, the right team memberships and an accepted invitation (reading the account's real state rather than trusting a board column) and repair what is missing. They set visible flags for staff and email anyone who has not yet logged in.

The outcome

  • Built over 2025 and 2026 ahead of intake. Between them the eight scenarios have run five times (a hospitality-track invitation three times and a provider assignment twice), with no errors.

  • The employer onboarding and both sweeps are switched off.

  • An approval or a status change is the only human step; the seat, the team, the boards and the invitation email follow from it.

Where it stops

These flows were built ahead of intake and have seen only light use. The case they do not yet handle is a person who already has a monday.com account: the invitation returns an error and, depending on the scenario, the run either stops or carries on with no user to add. The sweeps store a last-reminded date but do not use it to throttle, so as built a reminder would repeat each run, and the email wording is tied to one event date. Team ids are fixed in the scenarios, and the track-specific invitations are separate copies, so a fix has to be made in each.

Built with

  • Make.com
  • monday.com
  • GraphQL API
  • Microsoft Outlook
  • Webhooks

Patterns used

  • Direct API where the module stops
  • Break and retry
  • Team-scoped access
  • Reconcile real state

Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy

Start here

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.

Book a 15-minute callsaveez@skofi.tech

What happens on the call

  • 15 minutes, no deck
  • We map the process on the call
  • A written scope, or an honest no
Book a call