March 2025 Release Notes

Table of Contents

New Features

User Mapping when Advance/Reject/Export

Filtering by Candidate and Custom Fields + Application Screening Questions 

Handling Conflicting Data in Multi-Profile Situations

Support for SSO-Only Login

New Features

User Mapping when Advance/Reject/Export

What is it?

We now allow Findem users to self-identify their mapped ATS user with an in-step workflow. Users will be able to easily complete their workflow after mapping to their ATS user.

This addresses a common failure that occurs when users attempt to export, advance, or reject candidates, specifically in cases where the user is not mapped to the correct ATS user. The update ensures that the system recognizes the user performing the action and improves the user experience by providing a clear, self-service workflow for resolving mapping issues. The intention is to reduce confusion and prevent unnecessary failures during these actions.

How does it work?

If a user attempts to perform an action (such as exporting a candidate), and they are not mapped to an ATS user, the system will trigger a prompt asking the user to identify themselves.

The user will be presented with a pop-up that asks, "Who are you?" They can then manually select their identity from a list or enter their information and press Save. This action will resolve the mapping issue and allow the user to continue with the task.

This self-identification process ensures that recruiters and other users can easily resolve mapping issues without needing to rely on Customer Support.

Why did we add this?

This was causing users in their first experience to be frustrated if configuration was not done, or their Findem user was not automatically mapped. By adding this self-service option, the system minimizes the number of errors caused by unmapped users, particularly when users attempt to advance, reject, or export candidates.

The goal is to ensure that the action proceeds smoothly without unnecessary interruptions, enhancing the overall user experience.

Filtering by Candidate and Custom Fields + Application Screening Questions 

What is it?

Users will now have the ability to filter inbounds applications, and candidates by custom fields or application screening questions. Custom field filters can be found in the Inbounds Tab, The ATS Tab, and in the ATS Attributes section in the left navigation.

How does it work?

There will now be custom fields in multiple locations, including:

• Inbound Applicants Tab: You can filter inbound applicants based on custom fields, allowing you to segment and prioritize candidates based on their responses or attributes.
• Attributes Sidebar: Custom fields are now also available in the attributes sidebar, making it easier to filter based on these criteria while reviewing candidate profiles.

This feature is compatible with several popular ATS platforms, including:

• Greenhouse
• Ashby
• Workday
• Lever
• Jobvite
• SmartRecruiters
• SAP SuccessFactors

For most of these integrations, custom fields will be available out of the box. However, SAP SuccessFactors and iCIMS users will require additional configuration to make custom field values available, as their API doesn’t support this functionality directly.

SAP SuccessFactors and iSINS customers will need to provide a file that declares their custom field values to allow for proper integration. A dedicated implementation process will be required to collect this information from these customers.

Why did we build it?

• Reason 1: Customers put a lot of effort into segregating their candidates/applications in the ATS with custom fields. They would like to leverage these groupings in Findem to more Search for candidates more effectively.
• Reason 2: Recruiters want to surface the "knockout" questions in the application review cycle in order to improve efficiency. Today, customer feedback has been that "Findem does not include all of the information I need to make a decision." This effort is to close the gap and provide users with all of the required info to advance/reject an applicant.

Supported ATSes - V22 (March 8th Release)

• Greenhouse
• Ashby
• Lever
• Jobvite
• SmartRecruiters

Supported ATSes - V23 (March 22th Release)

• iCIMS
• Workday

Handling Conflicting Data in Multi-Profile Situations

What is it? 

Occasionally candidates will have multiple profiles (e.g. public data and a resume associated with an application) where the profiles have conflicting information on them. We've updated our matching algorithm and the associated user experience to more clearly represent how we are scoring that candidate, specifically with regards to current location, job title and company. The matching algorithm will be inclusive of data across multiple profiles so that users can determine candidate fit for the role.

Why did we build it? 

Prior to this change there were two main issues occurring that were breaking user trust in our search platform:

• We were displaying a location (or job title) as a match when it clearly wasn't, or vise versa
• We were displaying information in matching that wasn't visible in the currently viewed profile

Additional notes

• The primary focus of this is on fields that can be current (location, job title, company). We started here because the primary cause of confusion is a result of one of the profiles having outdated information. Additionally other fields are generally a superset (e.g. if you have a skill on your resume, but not on your public profile, you likely still have that skill)
• Changes will be visible on the candidate row (across all tabs except inbounds where we display and match against the application resume) and in the EP in the header and match details section
• This is an inclusive change, meaning that as a result more candidates should meet an employer's criteria. In the future we will likely try and make a determination on what data is the most accurate, smoothing out some of the experience
• Occasionally customers may see multiple locations that are logically the same, but not normalized, so we show the +1 experience

Support for SSO-Only Login

What is it?

We are excited to announce an update to our login experience that supports SSO-only login per customer as desired. To support this option, the Findem login experience will change for all users who log in via https://matches.findem.ai/auth/login.

Here's how it works:

1. From the main Findem login screen, enter your email address.
2. You will now be presented with your org-specified login options:
   1. SSO only: you will go directly to your SSO login experience
   2. Email/password + SSO: you will see a password option as well as the SSO button
   3. Email/password only: you will see a password option as well as a Google SSO button (for now)

New account creation will follow a similar flow.

Why did we build it?

We have some customers who don’t want to allow email/password logins due to IT policies/for security reasons. The larger our enterprise customer, the more likely this is to happen. Historically, we’ve only supported adding on an SSO option in addition to email/password. With this release, we will support SSO-only login at an org level for orgs that have Okta, PingID, or Azure AD SSO set up.

How do I enable it?

If your org would like to enable SSO-only login, contact your CSM who will work with our internal team to enable this manually. In the near future, we will have an option in Organization Settings > Security to require SSO once you’re added it.

Caveats

• Currently, we don’t have a Google SSO option; we just always support it if there is no other SSO enabled. In a subsequent release, we will add an explicit Google SSO option for orgs that want to show Google SSO as a button and/or want to require Google SSO.
• Existing email users will be able to “upgrade” to the SSO-only option simply by logging in via SSO in the login flow, provided they have the same email address in Findem as they do in their SSO setup.
• If there are multiple orgs or subsidiaries under your org (e.g., Acme, Acme Exec, Acme Staging), please work through what the login configuration should be for each one. Ideally it’s all the same configuration but we can support unique configurations per org.
• If a user has multiple email accounts within an org and SSO-only is enforced, any alternate emails that deviate from the SSO account’s email address will no longer be accessible. E.g. if there are both [e-mail] and [e-mail] users within the Acme org and we turn on SSO only for that org, [e-mail] will be the only account that can be logged into.