Skip to content
English
  • There are no suggestions because the search field is empty.

RELEASE NOTES RMS (Recruitment Management System)

This is a release note highlighting the new features and improvements on the RMS (Recruitment Management System)

1. Custom Date Range Filters for Hiring Analytics Cards

Description: All five hiring analytics cards (Application Sources, Average Time to Hire, Average Time to Fill, Hiring Funnel, Hiring Timeline Metrics) now support a custom date range, not just preset windows like "Last 7 Days" or "Last 6 Months."

User Segment: Recruitment admins

Relevance: Admins previously couldn't analyze hiring data for arbitrary periods (e.g. a specific quarter or a client-defined reporting window). This was a recurring analytics complaint and a top-scored RICE item.

Notes / Acceptance Criteria:

  • "Custom Range" appears as an option alongside existing presets on all five cards.
  • Selecting it opens a date picker for start/end date; confirming refreshes the card to that period only.
  • If no data exists for the range, the card shows "No records found" instead of stale/empty data.
  • Time to Hire and Time to Fill are always rounded to one decimal place (e.g. 1.5 days never 1.2347).
  • Each card also shows the overall aggregate average for the selected period, not just per-job/per-day breakdowns.

Step-by-Step Guide:

  1. Go to the Hiring Analytics dashboard.
  2. On any of the five analytics cards, open the date filter dropdown.
  3. Select "Custom Range."
  4. Pick a start and end date in the date picker and confirm.
  5. Verify the card refreshes to show data scoped to that range, plus the aggregate average for the period.
  6. Test the empty state by selecting a range with no hiring activity confirm "No records found" displays.
2. Workflow Slug Standardisation and Sanitisation for Bulk Candidate Uploads

Description: Fixes bulk candidate movement failures caused by mismatches between the workflow step "slug" generated on the frontend and the one used by the backend during bulk upload processing.

User Segment: Recruitment admins

Relevance: Bulk candidate uploads were silently failing due to casing, spacing, and special-character inconsistencies between how a workflow step's slug was generated at creation time vs. at upload time. This was a direct workflow blocker.

Notes / Acceptance Criteria:

  • Frontend and backend now use the identical slug algorithm: lowercase, trim, collapse double spaces, replace spaces with hyphens.
  • "In Review," "in review," and "IN REVIEW" all resolve to the same slug.
  • No two workflow steps in the same workflow can share a name duplicate names are blocked with a validation error.
  • A step's slug can be edited freely until an applicant has been placed on a job using that step; after that, the name/slug are locked (with an explanatory tooltip).
  • Renaming a step before it's attached to a job updates all slug references consistently.

Step-by-Step Guide:

  1. Go to Workflow settings and create or edit a workflow step name (try mixed case and extra spaces, e.g. " In Review ").
  2. Confirm the generated slug is normalized (lowercase, trimmed, hyphenated).
  3. Attempt to create a second step with the same name in the same workflow confirm it's blocked with a validation error.
  4. Run a bulk candidate upload template referencing that step name in different casing confirm it matches correctly.
  5. Place an applicant on a job using that step, then try to edit the step name confirm the edit controls are now disabled with an explanatory message.
3. Ability to Remove Pre-filled Application Form Fields When Creating a Job

Description: Admins can now delete non-mandatory default fields from a job's application form, so candidates only see fields relevant to the role.

User Segment: Recruitment admins

Relevance: Clients wanted control over which fields appear on the public application form without being stuck with the full default set.

Notes / Acceptance Criteria:

  • Every field except First Name, Last Name, and Email Address shows a delete icon.
  • Removing a field updates the form preview immediately and hides it from both the external application form and the admin filter page.
  • A removed field can be re-added at any time before the job is published.
  • Mirrors the existing toggle pattern used for fields like National ID.

Step-by-Step Guide:

  1. Create or edit a job and open the application form builder.
  2. Click the delete icon on a non-mandatory field (e.g. a custom field).
  3. Confirm it disappears from the form preview.
  4. Publish the job (or preview the external form) and confirm the field is not shown to candidates.
  5. Re-add the removed field before publishing and confirm it reappears.
  6. Confirm First Name, Last Name, and Email Address have no delete icon.
4. Per-Job Analytics View with Date Range Filter

Description: Individual jobs now have a dedicated analytics section (Application Monitor, Hiring Timeline, Average Time to Hire, Average Time to Fill) with the same custom date filtering as the global dashboard.

User Segment: Recruitment admins

Relevance: Admins previously could only assess hiring performance at the global level, not for a specific job's process.

Notes / Acceptance Criteria:

  • Hiring Timeline shows days spent per workflow stage (e.g. Review: 4 days, Interview: 5 days).
  • Same custom date range filter and aggregate average as the global dashboard (see Feature 1).
  • "No records found" for empty ranges; Time to Hire/Fill shown to one decimal place.

Step-by-Step Guide:

  1. Open an individual job record.
  2. Navigate to its Analytics section.
  3. Confirm the four cards (Application Monitor, Hiring Timeline, Time to Hire, Time to Fill) are present.
  4. Apply a custom date range and confirm the cards refresh accordingly, including the aggregate average.
5. Export Job Requisitions as CSV and Download Single Requisition as PDF

Description: Admins can multi-select job requisitions for a background CSV export, and download an individual requisition as a PDF on demand.

User Segment: Recruitment admins

Relevance: No existing way to extract requisition data for record-keeping or external sharing a recurring support request.

Notes / Acceptance Criteria:

  • Checkboxes on the requisitions list, with "Select All."
  • Export button appears once one or more rows are selected; export runs as a background job (admin is notified they'll be emailed/in-app notified when ready no page block).
  • CSV includes all key requisition fields (ID, Job Role, Department, Requester, Number Needed, Date, etc.).
  • Single-requisition PDF download is on-demand (not background) from the requisition detail view.
  • Attached documents are excluded from both exports, with no broken links.
  • Non-functional requirement: background export must complete within 2 minutes for up to 500 requisitions.

Step-by-Step Guide:

  1. Go to the job requisitions list.
  2. Select one or more requisitions via the checkboxes (try "Select All" too).
  3. Click Export confirm you see a message that the CSV is generating in the background.
  4. Wait for the in-app notification and email with the download link; open the CSV and confirm it includes the key fields and excludes attachments.
  5. Open a single requisition's detail view and click the PDF download button confirm it downloads immediately.
6. Customisable Default Application Confirmation Email (Stage 1 of RMS Workflow)

Description: The fixed system default confirmation email sent to applicants on submission can now be edited per workflow, with placeholders, a preview, and a reset option.

User Segment: Recruitment admins (configuration); job applicants (recipients)

Relevance: Clients wanted the applicant-facing confirmation message to reflect their own tone and include organization-specific info, not a generic system default.

Notes / Acceptance Criteria:

  • Editable rich text field on the default (IN-REVIEW) workflow step, pre-populated with the current default message.
  • Supports placeholders (applicant name, job title, company name) with a visible list of available ones, and a preview showing resolved values.
  • Minimum 128-character validation blank/near-blank messages can't be saved.
  • "Reset to default" restores the system message, with a confirmation prompt first.
  • Changes only apply to applications submitted after the edit; prior applicants are unaffected.
  • Changes are captured in the workflow's audit trail (who, when).

Step-by-Step Guide:

  1. Go to the workflow configuration for the default IN-REVIEW step.
  2. Edit the confirmation email body using the rich text editor; insert a placeholder from the provided list.
  3. Use the preview option to confirm placeholders resolve correctly.
  4. Try saving with fewer than 128 characters confirm the validation error blocks the save.
  5. Save a valid message, then submit a test application under that workflow and confirm the applicant receives the customized message.
  6. Click "Reset to default," confirm the prompt, and confirm the field reverts to the system default.
  7. Check the workflow audit trail for a record of the change.
7. Job Team Member Count Display

Description: The job team section now shows a total member count in its header, with a hover/click breakdown of internal vs. external members.

User Segment: Recruitment admins and hiring team members

Relevance: Admins had to manually count names to understand hiring team composition.

Notes / Acceptance Criteria:

  • Header shows count, e.g. "Job Team Members (6)."
  • Hover/click reveals Internal vs. External breakdown.
  • Count updates in real time as members are added/removed.
  • "Job Team Members" count = accepted invites; "Pending Invite" count = not-yet-accepted invites (tracked separately).

Step-by-Step Guide:

  1. Open a job's Team section.
  2. Confirm the header shows a numeric count next to "Job Team Members."
  3. Hover or click the count and confirm the Internal/External breakdown tooltip appears.
  4. Add or remove a team member and confirm the count updates immediately.
  5. Invite a new member (don't accept yet) and confirm they show under "Pending Invite," not the main count.

8. Applicant Application Flow Redesign (Apply Without Account Creation Friction)

Description: Removes the blocking sign-up/login modal from the "Apply" flow. Applicants go straight to the application form, with optional (non-blocking) Google/LinkedIn/login options to pre-fill fields, and a magic link to manage their application afterward.

User Segment: Job applicants; recruitment admins (indirectly, via improved conversion)

Relevance: The sign-up-first flow was causing significant application drop-off this is one of the highest-impact, highest-complexity features in this release, and changes the authentication model for applicants.

Notes / Acceptance Criteria:

  • Clicking "Apply" goes directly to the form no blocking modal.
  • Continue with Google / LinkedIn / Log in / fill manually are offered alongside the form, purely to pre-fill fields, not to gate applying.
  • Submission creates a candidate profile in the background with no password required; duplicate emails attach to the existing account instead of creating a new one.
  • Confirmation screen/email include "Go to main job board" and "Manage my application" (which sends a magic link rather than a password reset).
  • Duplicate applications to the same job (same email) are blocked with a generic message that doesn't reveal which detail matched.
  • Privacy consent stays as passive text, not an active checkbox.

Step-by-Step Guide:

  1. From the public job board, click "Apply" on a job and confirm you land directly on the application form (no modal).
  2. Fill the form manually and submit without setting a password.
  3. Confirm the "Application sent successfully" message and confirmation email, each with "Go to main job board" and "Manage my application" options.
  4. Click "Manage my application" while unauthenticated and confirm a magic link is emailed (not a password prompt).
  5. Attempt to apply again to the same job with the same email confirm the duplicate-application message appears.
  6. Test "Continue with Google" or "Continue with LinkedIn" and confirm available profile data pre-fills the form (still editable).
9. Applicant Self-Service Account Deletion

Description: Job applicants can permanently delete their own account and data from their profile/settings page, with a guarded confirmation flow.

User Segment: Job applicants

Relevance: Compliance requirement (GDPR/NDPR) applicants previously had no self-service way to remove their data.

Notes / Acceptance Criteria:

  • Entry point is a low-traffic "Delete Account" option on the settings page.
  • Confirmation requires typing "DELETE ACCOUNT" (exact string) plus a final "Are you sure?" step.
  • On deletion: account is permanently removed, no longer appears in admin RMS/talent pool search, and is excluded from job application lists. The applicant is instead counted under "No Longer Candidates" on jobs they'd applied to the only trace retained.
  • Talent pool entries are removed entirely.
  • An audit log entry is created with the deletion timestamp and a masked email (format: first 2 chars + ** + last char + domain, e.g. ab**h@gmail.com); an internal audit notification is sent.
  • Deletion is irreversible not recoverable even by a SeamlessHR super admin, only auditable.
  • Prior Google/LinkedIn social connections are severed; re-signing up later creates a brand-new account.

Step-by-Step Guide:

  1. Log in as a test applicant and go to profile/account settings.
  2. Locate and click "Delete Account."
  3. In the confirmation modal, attempt to confirm without typing the exact string confirm the button stays disabled.
  4. Type "DELETE ACCOUNT" and confirm the final "Are you sure?" step appears.
  5. Confirm deletion and verify: the applicant can no longer log in, does not appear in admin/talent pool search, and shows under "No Longer Candidates" on jobs they'd applied to.
  6. Check the audit/retention log for a masked-email entry marked as self-initiated.
10. Data Retention Policy Update and Retention Log Masking

Description: Changes the default retention outcome from "delete on no-response" to "save on no-response," updates retention email copy accordingly, and masks email addresses in retention logs.

User Segment: Platform/system administrators; job applicants (as data subjects)

Relevance: The prior default silently deleted applicant data on inaction, which risked data loss and didn't match how clients wanted retention to work; unmasked emails in logs were also a privacy gap.

Notes / Acceptance Criteria:

  • Non-response to a retention email now retains data by default; only an active deletion request removes data.
  • Retention reminder email copy no longer implies inaction causes deletion, and includes a clear "request deletion" call to action.
  • Applies centrally across all client environments no per-client template changes needed.
  • Retention logs mask emails using the same format as account deletion (first 2 chars + **** + last char + domain); masking is applied at display time only the underlying record keeps the full address for compliance purposes, visible only to SeamlessHR super admins.
  • Self-service account deletions (Feature 9) also appear in the same retention log, flagged as self-initiated.

Step-by-Step Guide:

  1. Open the retention policy settings and confirm the default behavior is now "save on no-response."
  2. Review a retention reminder email and confirm the copy reflects "we'll keep your data unless you ask us to delete it," with a visible deletion request option.
  3. Let a test retention email go unanswered past its window and confirm the applicant's data is retained, not deleted.
  4. Open the retention log as a client admin and confirm email addresses are masked (e.g. ab****h@gmail.com).
  5. Trigger a self-service account deletion and confirm it appears in the same retention log, labeled self-initiated.
11. Smart Screening and Smart Ranking Activation Time Unit Change (Minutes to Hours)

Description: The activation delay for Smart Screening (application stage) and Smart Ranking (assessment page) is now configured in hours instead of minutes, with clearer labeling.

User Segment: Recruitment admins

Relevance: Minute-based configuration forced admins to do manual time-unit conversions for what's typically a multi-hour or multi-day wait period.

Notes / Acceptance Criteria:

  • Input field now takes hours, with a persistent "Hours after submission" label (not just on hover).
  • Copy is updated to explain what the delay does (e.g. "Set the time to wait before smart screening activates").
  • No min/max enforced 0 is allowed (immediate activation); decimals are accepted for sub-hour precision (e.g. 0.5 = 30 minutes) and converted to minutes for backend storage.
  • Backward compatible: existing values stored in minutes are converted and displayed in hours automatically (60 → 1, 120 → 2) no configuration is lost.
  • Applies to both the application-stage Smart Screening config and the assessment-page Smart Ranking config.

Step-by-Step Guide:

  1. Open Smart Screening configuration on the application stage.
  2. Confirm the field is now labeled in hours with the unit always visible.
  3. Enter a decimal value (e.g. 0.5) and confirm it's accepted.
  4. Repeat on the Smart Ranking configuration on the assessment page.
  5. On an environment with a pre-existing minutes-based value, confirm it now displays correctly converted to hours (e.g. a prior 120 shows as 2).
12. About Company Section Displays Correct Subsidiary Info on Job Listings

Description: The "About Company" section on a job listing now shows the subsidiary that actually created the job, instead of defaulting to the parent/holding company's details.

User Segment: Job applicants and employees viewing job listings; recruitment admins

Relevance: Multi-subsidiary clients were showing applicants inaccurate company context for the specific role, which undermines listing quality and employer branding for the subsidiary.

Notes / Acceptance Criteria:

  • "About Company" pulls from the job's associated subsidiary entity, not the client-level default.
  • If a job was created directly under the parent company (no subsidiary), it correctly falls back to parent company details unchanged behavior.
  • Applies to both the external applicant-facing listing and the internal job preview.
  • Jobs shared across multiple subsidiary environments show the originating subsidiary's info, not the viewing subsidiary's.
  • Fix applies retroactively to existing published jobs no republish required.

Step-by-Step Guide:

  1. Open a job listing that was created under a subsidiary (in a client with a parent/subsidiary structure).
  2. Check the "About Company" section and confirm it shows the subsidiary's details, not the parent company's.
  3. Open a job created directly under the parent company and confirm it still shows parent company details.
  4. Check an existing (already published) subsidiary job to confirm the correction applied without needing republication.
  5. Repeat the check on the internal job preview view.