RecrutFlo logoRecrutFlo
Create account
← All articles

Recruitment operations

4 Shared Inbox Permissions Recruiters Must Check, From CVs to Apps

By Andre · · 10 min read

4 Shared Inbox Permissions Recruiters Must Check, From CVs to Apps

Geometric layers suggest shared inbox access permissions

Most recruiting teams should give people read and assign access by default, keep send permission limited to those who actually reply to candidates, and reserve full mailbox management for an admin. Any software connecting to that inbox should request the narrowest OAuth or Microsoft Graph scope that does the job, never broader access “just in case.” Before you turn any of this on, write down who processes candidate data and why, and switch on audit logging the same day.

TL;DR:

  • Use delegated access or groups in Google Workspace, review Microsoft app permissions through admin consent, and avoid shared IMAP passwords that erase individual activity trails.
  • Give recruiters read and assignment rights, hiring managers read only access to shared candidates, and reserve sending and full mailbox control for one admin.
  • CV readers should request gmail.readonly, not mail.google.com; Google requires a security assessment for restricted scopes, so broader access for attachment parsing is a warning sign.
  • Review permissions quarterly and after staffing changes; log app consent, scopes, and dates, and define CV retention and subject access request procedures.
  • Record whether your team is the controller and the provider the processor, give written processing instructions, and complete a privacy review before enabling automation.
Recrutflo
Organize CVs From Shared Inboxes
RecrutFlo connects to shared email inboxes, identifies CV attachments, and organizes candidate information into searchable profiles.
Explore RecrutFlo

Table of Contents

Permission categories and why each matters for CV handling

A shared recruitment inbox usually mixes four kinds of access, and conflating them is where most teams get into trouble. Read access lets someone open and view messages and attachments, which is the minimum needed to triage incoming CVs. Send access lets someone reply as the inbox, which matters for candidate communication but should not be handed to everyone who just needs to screen resumes. Manage access covers labeling, assigning, archiving, and deleting messages, actions that change the shared record other teammates rely on. Delete and archive in particular deserve a second look: someone who can quietly remove a message can also quietly remove evidence that a candidate applied at all, which matters if a subject access request ever comes in.

User-level and app-level permissions are a separate axis entirely. A recruiter’s own login might have broad read and reply rights, but the software connecting to that mailbox should be scoped independently, often much more narrowly. An integration that only extracts candidate details from attachments has no reason to hold send rights or full mailbox control, regardless of what access the human user has.

  • Read: view messages and attachments, no changes made.
  • Send: reply or send new messages as the shared address.
  • Manage: label, assign, archive, or delete messages.
  • App-level scope: what a connected tool can do, set independently of any one person’s login.

Getting this split right also sets you up for audit logging and subject access readiness, since recruitment guidance from the ICO expects recruiters to keep records of who handled applicant data and to respond to access requests with those records intact.

How to check and adjust access in Gmail, Microsoft 365, and IMAP setups

The practical steps differ by platform, but the goal is the same everywhere: know exactly who and what can touch the inbox, and narrow it wherever you can.

  1. Google Workspace: use delegated mailbox access or Google Groups rather than sharing one login, and check any connected app’s requested scope against Google’s Gmail API scope list before approving it; restricted scopes need extra security review, so involve your workspace admin for anything beyond basic read access.
  2. Microsoft 365 and Outlook: review connected apps through Azure admin consent screens and check which Microsoft Graph permission category each one requests, since many mailbox-level actions require admin approval rather than individual user consent.
  3. IMAP and shared credentials: avoid distributing one shared password across the team, since a single login makes it impossible to tell who read, sent, or deleted a given message; per-user access or a delegated model gives you that trail back.

A simple default by role works for most small teams: recruiters get read and assign, hiring managers get read only on candidates shared with them, and one admin holds send and full management rights.

Pro Tip: Review connected app permissions the same day you review team member access, since an overlooked integration is just as much a gap as an overlooked login.

Two access review paths meet at one checkpoint

What integrations should ask for and what to check before you approve

When a CV parsing or recruitment tool asks to connect to your inbox, the scope it requests tells you most of what you need to know. Gmail distinguishes between gmail.readonly, which only lets an app view messages and attachments, and broader scopes like mail.google.com, which grant full account control; if a tool only needs to read CVs out of incoming mail, there is no reason it should ask for the broader one. Google’s user-data policy requires developers to request only the minimum relevant permission and to use incremental authorization, asking for more access only when a feature that actually needs it is turned on, rather than requesting everything up front “for later.”

Microsoft Graph works on a similar principle, splitting permissions into delegated and application types, with many mailbox-level operations requiring explicit admin consent rather than a one-click user approval. Before approving any integration, it’s worth asking the vendor a short list of direct questions:

  • Exactly which scopes or permissions does the integration request, and why?
  • Does the tool keep an audit log of what it accessed and when?
  • What is the data retention and deletion policy for candidate records?
  • Is there a data processing agreement, and will the vendor support a DPIA if asked?

Restricted Gmail scopes such as mail.google.com and gmail.modify require a Google security assessment before an app can request them, which is a useful signal: a tool asking for one of these when it only reads attachments is over-scoped. Treat any vendor who wants broad access “to future-proof the integration” as a warning sign rather than a convenience.

Policy and audit checklist recruiters should implement

Permissions settings only hold up if there is a policy behind them. ICO guidance on AI and automation in recruitment recommends recording whether your organization acts as controller or processor for candidate data, and setting out written instructions for any software provider that touches that data on your behalf.

  • Record controller and processor roles in writing, with explicit instructions given to each provider.
  • Review privileges quarterly, or immediately when someone joins, leaves, or changes role.
  • Set a clear retention period for CVs and delete records once it passes.
  • Prepare a subject access request procedure before you need one, not after.
  • Run a privacy review or DPIA before switching on new inbox automation.

Access logs deserve a specific mention here: capturing who granted an app’s consent, which scopes were granted, and the date, gives you something concrete to show if a candidate asks how their data was handled.

Pro Tip: Treat a role change, not just a hiring or firing, as a trigger for a permissions review: a recruiter moving into an ops role often keeps access they no longer need.

Why permissions reviews belong in recruitment ops, not just IT

Why permissions reviews belong in recruitment ops, not just IT — overview diagram

Scoped automation tends to cut manual errors while leaving recruiters in control of candidate decisions, which is the balance most small teams are actually trying to strike. The mistake I see most often isn’t granting too much access on purpose. It’s treating permissions as a one-time setup task handled by whoever configured the inbox originally, then never revisiting it as the team grows or tools change.

Recruitment ops owns the hiring workflow, so it should own the access list that supports it, not hand it off entirely to IT and forget about it. A quarterly look at who can read, send, and manage the shared inbox takes a few minutes and catches the kind of drift that turns into a real problem later.

— Marco

Keeping CV parsing simple without over-granting access

We built RecrutFlo around the same principle this guide argues for: ask for only what the job requires. Our software connects to Gmail, Microsoft 365, Outlook, and IMAP mailboxes, finds CV attachments in incoming mail, and turns them into searchable candidate profiles without needing broad mailbox control to do it. Setup skips the onboarding call, and our pricing stays visible with no sales conversation required. See exactly how the connection works on our how it works page before you decide.

Recrutflo

FAQ

What permissions should a recruiter have on a shared CV inbox?

Most recruiters need read access to view incoming CVs and assign access to route candidates to the right person, with send access limited to those who reply directly to applicants. Full mailbox management, including deletion and bulk changes, works best reserved for one admin per team.

Should I share one shared mailbox password with the whole team?

Sharing a single login makes it impossible to tell who read, sent, or deleted any given message, which creates problems if you ever need to show who handled a candidate’s data. Delegated access or group-based permissions in Google Workspace or Microsoft 365 give you a per-person trail instead.

What OAuth scope should a CV parsing tool request from Gmail?

A tool that only needs to read CV attachments should request gmail.readonly rather than broader scopes like mail.google.com, which grant full account control. Google requires a security assessment before an app can even request the broader restricted scopes, so a narrow request is both safer and faster to approve.

Who is responsible for candidate data if we use recruitment software?

Recruiters typically act as the data controller, while a software provider processing CVs on their behalf acts as a processor, and ICO guidance recommends recording that relationship in writing with explicit processing instructions. This documentation also supports any DPIA or privacy review you run before switching on new automation.

How often should we review shared inbox permissions?

A quarterly review catches most drift, but a change in staffing, such as someone joining, leaving, or switching roles, should trigger an immediate check rather than waiting for the scheduled one. Keeping an access log of who was granted what, and when, makes each review faster.

Sources

Recommended