Skip to main content
Cloning allows you to create a copy of an existing search — including all its results, contact details, and metadata — without affecting the original. This is useful in several scenarios:
  • Testing different criteria — You want to see how adjusting filters (e.g., wider radius, different experience level) changes the results, without losing your original search.
  • Sharing with teammates — You found a great set of results and want a colleague on your agency team to have their own copy to work from independently.
  • Creating variations — You want to search for the same role in different locations or with different skill combinations, starting from a proven baseline.
  • Preserving a snapshot — Before making significant changes to a search, clone it to keep the current state as a reference.
  • Candidate handoffs — When transferring a candidate to a colleague, clone the associated search so they have immediate context and all the results you have already curated.
Cloning is especially valuable for agency teams. Instead of asking a teammate to recreate your search from scratch, you can clone it directly to their account with all results intact. This saves significant time and ensures both recruiters work from the same baseline data.
Cloning is available from the search detail page:
1

Open the Search

Navigate to the search you want to clone by clicking on its card in the saved searches list.
2

Click Clone

On the search detail page, find the Clone action button in the toolbar. Click it to open the clone dialog.
3

Select the Target User

Choose which team member should receive the cloned search. You can clone to yourself or to any member of your agency.
Cloning to teammates requires you to be part of an agency. Both you and the target user must be members of the same agency. If you are an independent recruiter without an agency, you can still clone searches to yourself.
4

Confirm and Clone

Click Confirm to create the clone. Recruitier copies the search, all its jobs, and associated contact details to the target user’s account. The process typically takes a few seconds depending on the number of jobs.

​
What Gets Copied

When you clone a search, the following data is duplicated:
DataCopied?Details
Search criteriaYesName (with “[Cloned]” prefix), description, keywords, experience level, flexibility, job type, location, when filter
All active jobsYesEach non-deleted job is copied as a new record linked to the same underlying scraped job data
Contact detailsYesAll contact details associated with each job are duplicated for the target user
Match typesYesEach job’s AI classification (excellent, good, poor) is preserved
Match scoresYesRelevance scores are carried over from the original
Source keywordsYesThe keywords that led to each job match are preserved
The following data is not copied:
DataCopied?Reason
TagsNoTags are personal organizational tools and may not be relevant to the recipient
FavoritesNoFavorite status is reset — the recipient starts fresh
Project assignmentNoProjects are user-specific and not transferred
Internal notesNoNotes may contain private information not intended for sharing
Outreach flowsNoOutreach workflows are tied to individual user accounts
The cloned search references the same underlying scraped job records as the original. This means if a scraped job is updated (e.g., marked as expired), the update is reflected in both the original and cloned search. The scraped job data is shared; only the user-specific metadata (tags, notes, outreach) is independent.

​
Cloned Search Identification

Cloned searches are clearly identified in the interface:
  • The search name is prefixed with “[Cloned]” (e.g., “[Cloned] Python Developer”)
  • The search card and detail page show who cloned the search (name and email of the cloning user)
  • A reference to the original search ID (original_search_id) is stored for traceability
  • The cloned by user ID (cloned_by_user_id) records who performed the clone
If you clone a search that was already cloned (i.e., it already has the “[Cloned]” prefix), Recruitier does not add a second prefix. The name remains “[Cloned] Original Name” to keep it clean and readable. Once a search is cloned, it behaves as a fully independent search. The recipient can:
  • View and sort results just like any other search
  • Delete individual jobs from the cloned search without affecting the original
  • Tag jobs with their own personal tags
  • Add internal notes to jobs
  • Start outreach flows from the cloned search’s contact details
  • Favorite jobs independently from the original search
The cloned search is also independently monitored for new matching jobs, separate from the original search’s monitoring.
Changes to a cloned search do not propagate back to the original, and vice versa. After cloning, the two searches are completely independent. Deleting a job from the clone does not delete it from the original, and new jobs found by the original’s monitor are not automatically added to the clone.

​
Agency Team Workflow

Cloning is designed primarily as a team collaboration feature. Here is a typical workflow for agency teams:
  1. Recruiter A creates a comprehensive search for “Senior React Developer” with carefully selected skills, location filters, and experience level
  2. The search returns 150 results. Recruiter A reviews the top matches and tags the most promising ones
  3. Recruiter B is working on a similar placement. Instead of creating a new search, Recruiter A clones the search to Recruiter B’s account
  4. Recruiter B receives the clone with all 150 results intact and can immediately begin their own review, tagging, and outreach — without duplicating Recruiter A’s effort
  5. Both recruiters can now work the same opportunity set independently, with their own tags, notes, and outreach tracking
This workflow saves significant time and ensures both recruiters are working from the same baseline data while maintaining independent tracking.

​
Permissions

Cloning requires the following conditions to be met:
  • You must own the search you want to clone (you created it or it was previously cloned to you)
  • To clone to a teammate, both you and the target must be members of the same agency
  • You do not need any special role (admin or member) — all agency members can clone
  • The clone target must be an active user in the same agency
If you are not part of an agency, you can only clone searches to yourself. This is still useful for creating search variations without modifying your original — for example, cloning a search and then bulk-deleting poor matches from the clone while keeping the original intact.

​
Best Practices

  • Clone before making major changes — If you want to significantly adjust a search’s result set (e.g., bulk deleting poor matches), clone it first to preserve the original
  • Use cloning for candidate handoffs — When transferring a candidate to a colleague, clone the associated search so they have immediate context
  • Clone to yourself for A/B testing — Create two versions of a search with slightly different criteria to compare which produces better results
  • Keep names descriptive — After cloning, consider adding context to help identify the purpose (the “[Cloned]” prefix helps distinguish it, but adding the candidate name or variation description makes it even clearer)
  • Clone early, not late — Clone when the result set is fresh and unmodified. Cloning after heavy tag/delete operations means the recipient gets a partially curated set rather than the full original

​
Advanced

​
Clone Implementation Details

The clone operation works at the database level as follows:
  1. Search record duplication — A new search entity is created with all criteria fields copied from the original. The user_id is set to the target user, the name gets the “[Cloned]” prefix, and original_search_id and cloned_by_user_id are set for traceability.
  2. Job record duplication — Each non-deleted job in the original search is copied as a new Job entity. The new job record has a new ID and the target user’s user_id, but references the same scraped_job_id as the original. This means both the original and cloned jobs point to the same underlying ScrapedJob record.
  3. Contact detail duplication — All contact details associated with each cloned job are duplicated as new records for the target user. This ensures the recipient has immediate access to all contact information without needing a separate enrichment step.
  4. Metadata preservation — Match scores, match classifications, and source keywords are copied to the new job records. The recipient sees the same scoring and classification as the original.
  5. Metadata exclusion — Tags, favorites, project assignments, internal notes, and outreach flows are deliberately not copied. These are personal/team-specific data that should not be assumed transferable.

​
How Cloning Interacts with Monitoring

The cloned search inherits the monitoring state from the original at the time of cloning. If the original had is_monitored = true, the clone will also be monitored. However, from that point forward, monitoring runs independently:
  • New jobs found by the original’s monitor are not added to the clone
  • New jobs found by the clone’s monitor are not added to the original
  • Each search maintains its own new_jobs_count
  • SSE notifications for new matches are sent to the respective search owner
This independence is by design — it prevents confusion about where new results came from and keeps each recruiter’s pipeline cleanly separated.

​
Edge Cases

Only non-deleted (active) jobs are included in the clone. If you deleted 50 out of 150 jobs from the original, the clone will contain 100 jobs. The deleted jobs are not recoverable through cloning.
You can clone a clone. The new clone gets the “[Cloned]” prefix (only one level — it does not become “[Cloned] [Cloned] Name”). The original_search_id points to the immediate parent, and cloned_by_user_id records who performed this specific clone.
Expired jobs are included in the clone because they may still have value for reference. The expiration status comes from the shared ScrapedJob record, so if a job expires after cloning, it appears as expired in both the original and the clone.
If the target user already has some of the same underlying scraped jobs in their collection (from a different search), the clone creates additional Job records for those same ScrapedJobs. The user may see the same listing in multiple searches, which is expected behavior — each search maintains its own independent set of job records.

​
Business Rules

  • Agency boundary enforcement: Cloning is strictly limited to users within the same agency. Cross-agency cloning is not supported for data privacy reasons.
  • No cascading updates: After cloning, the original and clone are independent. There is no sync mechanism between them.
  • Soft data references: Both the original and clone reference the same ScrapedJob records. If a ScrapedJob is updated (new contact info, expiration, description update), both searches reflect the change because they share the same underlying data.