Candidate Database
The Candidate Database is the Recruit module's central store of candidate records. Where Job Applications organises people by job posting and pipeline stage, the Candidate Database keeps the record of the person: candidate records persist here and stay reusable across job postings, so a candidate you met on one opening is still available when the next one is created.
Who can use it
Access follows Settings → Roles & Permissions (/account/settings/roles), which holds a full permission matrix per role. Recruitment permissions — like every other module — can be set to None, Added (records the user personally added), Owns (records assigned to them) or All. Give recruiters and HR staff the level appropriate to their role; if someone reports a missing page, check Roles & Permissions first, then have them log out and back in, because permission changes do not always apply to an already-active session.
Prerequisites
- The Recruit module must be enabled for your company (Settings → Module Settings).
- Your role needs a recruitment permission level above None in Settings → Roles & Permissions.
- To collect candidates from the public Career Page, switch on Enable Career Site in Settings → Recruit Settings and publish at least one job with status Open.
How to Access
Navigation: Sidebar → Recruit → Candidate Database
Direct URL: /account/candidate-database
Related recruitment pages sit alongside it: Recruitment Dashboard (/account/recruit-dashboard), Jobs (/account/jobs), Job Applications (/account/job-applications), Interview Schedule (/account/interview-schedule), Offer Letters (/account/job-offer-letter), Skills (/account/job-skills) and Reports (/account/recruit-job-report).
Working with candidate records
1. Build the database through applications
Open /account/candidate-database to see the candidates your recruitment activity has accumulated. Applications submitted against a job posting — including those that arrive through the public Career Page — produce the candidate records that live here, so the database grows as postings run rather than needing to be assembled separately.
2. Open a candidate to review their history
Select a candidate to review their record. Because the record persists beyond any single posting, it is the place to look when you want the whole picture of someone who has applied to your company more than once, rather than the single-posting view you get inside Job Applications.
3. Re-use candidates on a new posting
When a new opening is created at /account/jobs, check the Candidate Database before sourcing externally. Candidates recorded from earlier postings remain available for the new one — that reuse across postings is the reason the database exists.
4. Keep skills meaningful
Skills are maintained as a shared library at Recruit → Skills (/account/job-skills) and are attached to job postings through the job's Skills field. A consistent skills vocabulary is what makes re-engaging past applicants practical, so agree on skill naming in the Skills library before it grows large.
Effect on Other Features
- Job Applications: Applicants tracked per posting at
/account/job-applicationspersist as candidate records here. The default pipeline runs applied → screening → phone_screen → interview_round_1 → interview_round_2 → assessment → offer → hired / rejected / withdrawn / on_hold. The candidate confirmation email now includes the position that was applied for. - Jobs: Applicants to a posting created at
/account/jobspersist in the candidate database and can be reused across future postings. - Career Page: With Enable Career Site switched on in Settings → Recruit Settings, applications from the public career page feed into the same candidate records.
- Skills: The Skills library (
/account/job-skills) supplies the vocabulary used on job postings, which is what keeps candidate re-engagement searchable. - Offer Letters: Offers at
/account/job-offer-letterare tracked with status (Accept/Pending), expiry date and joining date, so a candidate's outcome is visible from the offer record. - Recruitment Reports:
/account/recruit-job-reportprovides recruitment-specific reporting on the same underlying recruitment data.
Limitations
- Candidate records are scoped to the Recruit module, not to Employees. A hired candidate is not automatically the same object as an employee record. Workaround: after an offer reaches Accept in
/account/job-offer-letter, create the employee in HR → Employees and use the offer's joining date so the two records line up. - Field-level detail of the candidate record is not documented here. This article deliberately covers only what is confirmed in the product. Workaround: open
/account/candidate-databaseon your own tenant and read the columns and record layout directly — your enabled modules and role permissions determine what renders. - Visibility depends on permission level, so two recruiters can see different lists. With Added or Owns, a user sees only their own or assigned records. Workaround: if a shared view is required, raise the recruitment permission to All for that role in Settings → Roles & Permissions.
- PMSuite → Google Calendar is one-way. Interview events pushed out from PMSuite appear in Google Calendar, but items created in Google Calendar do not appear in PMSuite. Workaround: schedule interviews in Recruit → Interview Schedule (
/account/interview-schedule) so the record originates in PMSuite and pushes outward.
Troubleshooting
- Candidate Database is missing from the sidebar. Confirm the Recruit module is enabled in Settings → Module Settings, then confirm your role's recruitment permission is above None in Settings → Roles & Permissions. Log out and back in afterwards — permission changes do not always apply to an active session.
- A candidate you expected is not listed. Check your permission level first: at Added or Owns you only see your own or assigned records. Then confirm the application actually exists at
/account/job-applicationsfor the relevant posting. - No candidates are arriving from the public site. Verify Enable Career Site is on in Settings → Recruit Settings and that the posting's status is Open rather than Closed at
/account/jobs. - Applicants are not receiving the confirmation email. Check your company's outgoing mail configuration under Settings → Custom Email Setup / Notification Settings; the confirmation email includes the applied position, so a missing position usually indicates the application was recorded outside a posting.
- Interviews are not showing in Google Calendar. The push requires Google Calendar to be active and verified for the company with a stored authorisation, plus the relevant per-type toggle in Google Calendar Settings. Confirm those in Settings before investigating further.