Your Recruitment & Talent Acquisition Data Template

iCIMS
Your Recruitment & Talent Acquisition Data Template

Your Recruitment & Talent Acquisition Data Template

This template provides a clear roadmap for collecting the essential data needed to analyze your recruitment and talent acquisition process. It outlines the crucial attributes to gather, the key activities to track, and practical guidance for extracting this information from your iCIMS system. Using this template will help you prepare your data for comprehensive process mining.
  • Recommended attributes to collect
  • Key activities to track for process analysis
  • Extraction guidance for your iCIMS system
New to event logs? Learn how to create a process mining event log.

Recruitment & Talent Acquisition Attributes

These are the recommended data fields to include in your event log for a comprehensive analysis of your recruitment and talent acquisition process.
3 Required 6 Recommended 12 Optional
Name Description
Activity Name
ActivityName
The name of the specific step or milestone that occurred in the recruitment process.
Description

The Activity Name describes an event that happened at a specific point in time for a job application. Examples include 'Application Received', 'First Interview Conducted', and 'Offer Extended'. These activities form the sequential steps of the recruitment process.

This attribute is fundamental to process mining as it defines the nodes in the process map. Analyzing the sequence and frequency of these activities reveals the actual hiring workflow, highlights common and alternative paths, and identifies bottlenecks or rework loops.

Why it matters

This attribute defines the steps of the process, making it possible to build a process map, analyze flow, and identify deviations from the standard hiring procedure.

Where to get

Typically derived from status changes in the Recruiting Workflow Profile in iCIMS. The specific statuses and bins are often customizable by the organization.

Examples
Application ScreenedFirst Interview ConductedOffer AcceptedCandidate Hired
Activity Start Time
ActivityStartTime
The timestamp indicating when a specific recruitment activity began or was recorded.
Description

This attribute provides the date and time for each activity, such as when an application was screened or an interview was scheduled. Timestamps are essential for understanding the timing and duration of process steps.

In process mining, this timestamp is used to order events chronologically, enabling the discovery of the actual process flow. It is the basis for all time-based analysis, including calculating cycle times between activities, identifying delays, and monitoring performance against service level agreements.

Why it matters

It provides the chronological order of events, which is critical for calculating process durations, identifying bottlenecks, and understanding the timeline of the hiring process.

Where to get

This information is typically available in the audit trail or history logs associated with a Recruiting Workflow Profile in iCIMS.

Examples
2023-10-26T10:00:00Z2023-11-05T14:30:00Z2023-11-15T09:15:00Z
Job Application
JobApplicationId
The unique identifier for a candidate's application to a specific job requisition.
Description

The Job Application ID is the cornerstone of the recruitment process analysis, acting as the case identifier. Each ID represents a single candidate's journey for a particular job opening, from the initial submission through all subsequent stages like screening, interviews, and offer management.

In process mining, this attribute is used to link all related activities together into a cohesive end-to-end process flow. Analyzing processes based on the Job Application ID allows for a clear visualization of the hiring funnel, accurate calculation of cycle times, and identification of variations in the recruitment path for different candidates.

Why it matters

It is essential for tracking the entire lifecycle of a single application, enabling analysis of time-to-hire, drop-off rates, and process conformance for each candidate's journey.

Where to get

This is typically the primary key for an application record in iCIMS. Consult the Person or Recruiting Workflow Profile APIs.

Examples
APP-2023-001234APP-2023-005678APP-2024-009101
Application Source
ApplicationSource
The channel or method through which the candidate submitted their application.
Description

This attribute indicates the origin of the application, for example, 'Company Website', 'LinkedIn', 'Employee Referral', or 'Job Board'. It tracks how candidates are finding out about and applying for open positions.

This information is essential for the 'Application Sourcing Channel ROI' dashboard. By analyzing the volume of applications and, more importantly, the number of hires from each source, organizations can determine which channels provide the best return on investment. This helps optimize recruitment marketing spend and focus efforts on the most effective sources.

Why it matters

It helps measure the effectiveness of different recruiting channels, enabling optimization of sourcing strategies and budget.

Where to get

This data is captured on the candidate's application profile in iCIMS, often selected by the candidate or tracked via URL parameters.

Examples
LinkedInEmployee ReferralCompany Careers PageIndeed
Application Status
ApplicationStatus
The final outcome or current disposition of the job application.
Description

This attribute represents the final status of an application, indicating whether the candidate was hired, rejected by the company, or withdrew their application. It provides the concluding event for the recruitment process.

This is a critical attribute for outcome-based analysis. It is used to calculate conversion rates, offer acceptance rates, and drop-off rates. Understanding the final disposition of applications is fundamental to measuring the success and efficiency of the entire recruitment funnel.

Why it matters

It defines the outcome of the process, which is essential for calculating key metrics like hire rates and rejection rates.

Where to get

This is the final status in the Recruiting Workflow Profile in iCIMS. It is typically set when an application is moved to a terminal 'disposition' bin.

Examples
HiredRejected by CompanyCandidate Withdrew
Department
Department
The business department or function for which the job position is being hired.
Description

This attribute specifies the department, such as 'Engineering', 'Marketing', or 'Sales', that the open position belongs to. It provides organizational context for the job requisition.

Department information is a powerful dimension for analysis. It allows for segmenting KPIs like 'Time to Hire' and 'Offer Acceptance Rate' by department, which can reveal significant differences in hiring processes and efficiency across the organization. This helps identify which departments have optimized processes and which may need support.

Why it matters

It allows for performance comparison across different business units, highlighting variations in hiring efficiency and bottlenecks.

Where to get

This is typically part of the Job Profile information associated with the Job Requisition ID in iCIMS. It may be linked to organizational structure data.

Examples
EngineeringSalesMarketingHuman Resources
Hiring Manager
HiringManager
The name or ID of the hiring manager for the job requisition.
Description

The Hiring Manager is the person for whom the position is being filled. They are a key stakeholder in the process, responsible for reviewing candidates, conducting interviews, and making the final hiring decision.

This attribute is critical for the 'Hiring Manager Feedback Cycle' dashboard. By tracking the time between an interview and feedback submission per hiring manager, organizations can identify delays in the decision-making process and work to reduce them, which helps accelerate the overall hiring timeline.

Why it matters

It helps analyze hiring manager engagement and efficiency, particularly in providing timely feedback, which is a common source of delay.

Where to get

Typically stored on the Job Profile associated with the job requisition in iCIMS.

Examples
Robert BrownSusan WhiteMichael Green
Job Requisition ID
JobRequisitionId
The unique identifier for the job opening or position.
Description

The Job Requisition ID links multiple applications to a single job posting. It represents the specific role that candidates are applying for, containing details like the job title, department, and location.

In analysis, this ID is used to group and compare all applications for the same position. It allows for a view of the entire candidate pool for a single role, helping to understand the effectiveness of the hiring process for different types of jobs.

Why it matters

It groups all applications for the same role, allowing for analysis of the entire recruitment funnel for a specific job opening.

Where to get

This ID is a fundamental part of the Job Profile in iCIMS and is linked to every application submitted for that role.

Examples
REQ-2023-105REQ-2024-012REQ-2024-301
Recruiter
Recruiter
The name or ID of the recruiter responsible for managing the job application.
Description

This attribute identifies the primary recruiter assigned to the application. This person is typically responsible for screening candidates, coordinating interviews, and managing the process.

Analyzing data by recruiter is essential for the 'Recruiter Performance Overview' dashboard. It helps in evaluating individual and team performance by tracking metrics like time-to-screen, interview completion rates, and the number of successful hires. This allows for identifying best practices and areas for additional training.

Why it matters

This attribute is key to assessing recruiter workload and performance, enabling targeted improvements and resource allocation.

Where to get

This information is often stored on the Recruiting Workflow Profile or the associated Job Profile in iCIMS, linked to the user who performed certain actions.

Examples
John SmithJane DoeEmily Jones
Activity End Time
ActivityEndTime
The timestamp indicating when a recruitment activity was completed.
Description

The Activity End Time marks the conclusion of an event. In many cases, especially for discrete events like 'Offer Extended', the end time might be the same as the start time. However, for activities that have a duration, such as an interview block, it can be distinct.

This attribute is used to calculate the precise duration of individual activities, known as processing time. Analyzing processing time helps identify which specific tasks are taking the most time, rather than just the waiting time between tasks.

Why it matters

It enables the calculation of an activity's processing time, helping to distinguish between active work time and idle waiting time.

Where to get

Similar to the start time, this can be found in the audit trail or history logs in iCIMS. It might require inference if only a single event timestamp is available.

Examples
2023-10-26T10:05:00Z2023-11-05T15:30:00Z2023-11-15T09:15:00Z
Activity Processing Time
ProcessingTime
The time spent actively working on a single recruitment activity.
Description

Processing Time is the duration of a specific activity, calculated as the difference between its end time and start time. For many recruitment events, this may be zero or very short. However, for tasks like 'Conducting Interview', it can represent the actual time spent on that task.

This metric helps differentiate between active work time and waiting time. While the time between 'Interview Scheduled' and 'Interview Conducted' might be long (waiting time), the processing time of the interview itself is much shorter. Analyzing processing time can help optimize the execution of individual tasks.

Why it matters

It measures the actual duration of an activity, helping to distinguish active work from idle time and identify tasks that are time-consuming to execute.

Where to get

This is calculated in the process mining tool by subtracting the ActivityStartTime from the ActivityEndTime for each event.

Examples
1 hour 0 minutes0 hours 30 minutes0 hours 5 minutes
Candidate ID
CandidateId
The unique identifier for an individual candidate across all their applications.
Description

The Candidate ID is a unique identifier for a person in the talent pool, distinct from the Job Application ID. A single candidate can have multiple applications, but they will always have the same Candidate ID.

This attribute is particularly useful for the 'Duplicate Screening Detection' analysis. By grouping activities by Candidate ID, it's possible to identify instances where the same person is being screened multiple times for different roles unnecessarily. It also allows for a more holistic view of a candidate's interaction history with the company.

Why it matters

It uniquely identifies a person, allowing for analysis of a candidate's journey across multiple applications and detecting redundant activities.

Where to get

This is the primary identifier for the Person Profile in iCIMS.

Examples
CAND-9876CAND-5432CAND-1001
Country
Country
The country where the job position is located.
Description

This attribute specifies the country associated with the job requisition. It provides geographical context for the hiring process.

For global organizations, analyzing the recruitment process by country is essential. It can highlight regional differences in hiring timelines, sourcing channel effectiveness, and process compliance. This analysis helps in developing location-specific recruitment strategies and setting realistic regional performance targets.

Why it matters

It enables geographical segmentation of the hiring process, revealing regional performance variations and supporting global process standardization efforts.

Where to get

This is part of the location information on the Job Profile in iCIMS.

Examples
United StatesGermanyUnited KingdomCanada
Is Rework
IsRework
A flag indicating if an activity is being repeated for the same job application.
Description

The Is Rework attribute is a boolean flag that is set to true if a specific activity occurs more than once within the same case. For example, if a candidate has to go through the 'First Interview' stage twice, the second instance would be marked as rework.

This is a powerful attribute for the 'Process Compliance & Variants' analysis. It quickly highlights inefficiencies, redundancies, and deviations from the standard process. Identifying and quantifying rework helps to streamline the process, reduce wasted effort, and improve the candidate experience.

Why it matters

It helps to quantify process inefficiencies by identifying repeated steps, which are often indicative of problems or non-standard process flows.

Where to get

This attribute is calculated within the process mining tool by checking if an activity with the same name has already occurred for a given JobApplicationId.

Examples
truefalse
Job Location
JobLocation
The specific city or office location for the job opening.
Description

The Job Location provides a more granular geographical detail than the country, typically indicating the city, state, or specific office.

This attribute allows for more detailed regional analysis. For example, 'Time to Hire' can be compared across different cities to understand local market conditions and hiring challenges. It can also help in resource planning for regional recruitment teams.

Why it matters

It offers granular geographical insights, helping to analyze performance differences between specific offices or cities.

Where to get

This is stored in the location fields on the Job Profile in iCIMS.

Examples
New York, NYSan Francisco, CALondon, UK
Job Title
JobTitle
The title of the position for which the candidate has applied.
Description

The Job Title is the official name of the open role, such as 'Software Engineer' or 'Product Manager'. It provides specific detail about the position beyond the department or job family.

This attribute is a common dimension for filtering and segmenting recruitment data. For instance, analyzing 'Time to Hire' by job title can reveal that certain roles, especially senior or specialized ones, take significantly longer to fill. This insight can lead to developing tailored recruitment strategies for different types of positions.

Why it matters

It enables detailed analysis and performance comparison for specific roles, which may have unique hiring challenges and timelines.

Where to get

This is a primary field on the Job Profile in iCIMS.

Examples
Senior Software EngineerMarketing ManagerData Analyst
Last Data Update
LastDataUpdate
The timestamp indicating when the data was last extracted or refreshed from the source system.
Description

This attribute records the date and time of the most recent data pull from iCIMS. It does not reflect when the event happened, but rather when the record was last synchronized with the process mining tool.

This information is vital for understanding the freshness of the data being analyzed. It allows users to know if they are looking at real-time information or a snapshot from a specific point in time, which is important for the relevance and accuracy of the analysis.

Why it matters

It informs users about the timeliness of the data, ensuring that analyses and decisions are based on up-to-date information.

Where to get

This timestamp should be generated and recorded by the data extraction, transformation, and load (ETL) pipeline each time it runs.

Examples
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
Offer Amount
OfferAmount
The salary or compensation amount extended to the candidate in a job offer.
Description

This attribute contains the monetary value of the compensation package offered to a candidate. It is typically recorded when the 'Offer Extended' activity occurs.

This data is valuable for the 'Offer Acceptance Rate Trends' dashboard. By analyzing acceptance rates against the offer amount, and segmenting by factors like job title or department, organizations can gain insights into their compensation competitiveness. It can help identify if offers are being rejected due to compensation and inform adjustments to salary bands.

Why it matters

It provides crucial context for analyzing offer acceptance rates and understanding the impact of compensation on hiring success.

Where to get

This information is often stored in an 'Offer' tab or related fields on the Recruiting Workflow Profile in iCIMS.

Examples
8500012000095500.50
Rejection Reason
RejectionReason
The reason why a candidate's application was rejected by the company.
Description

When an application is rejected, this attribute provides the specific reason, such as 'Not a culture fit', 'Lacks required skills', or 'Position filled by another candidate'. This data is typically selected from a predefined list by the recruiter or hiring manager.

Analyzing rejection reasons provides valuable feedback on the recruitment process. It can highlight issues such as misalignment in job descriptions, problems with candidate quality from certain sources, or areas where the screening process can be improved. This helps in refining recruitment strategy and improving the quality of the candidate pipeline.

Why it matters

It provides critical feedback on why candidates are not advancing, helping to refine job descriptions, sourcing, and screening criteria.

Where to get

This is typically recorded when moving a candidate to a rejection status in the Recruiting Workflow in iCIMS.

Examples
Does not meet minimum qualificationsSalary expectations too highMore qualified candidate selected
Source System
SourceSystem
The system from which the data originated, in this case, iCIMS.
Description

This attribute identifies the source application where the recruitment data was generated and stored. For this process, the value would consistently be 'iCIMS' or a more specific identifier for the iCIMS instance.

While it may seem static in a single-system analysis, it becomes crucial when merging data from multiple systems, for example, combining recruitment data from iCIMS with HRIS data from another system. It ensures data lineage and helps in troubleshooting data integration issues.

Why it matters

It provides context on data origin, which is crucial for data governance and when integrating data from multiple HR systems.

Where to get

This is a static value ('iCIMS') that should be added during the data extraction and transformation process.

Examples
iCIMS Talent CloudiCIMS
Total Cycle Time
CycleTime
The total time elapsed from the first activity to the last activity for a job application.
Description

Cycle Time measures the end-to-end duration of the recruitment process for a single application. It is calculated as the difference between the timestamp of the very first event (e.g., 'Application Received') and the final event (e.g., 'Candidate Hired' or 'Application Rejected').

This is a primary KPI for measuring overall process efficiency. It is used in the 'Time to Hire Performance' dashboard to track how long it takes to fill roles. Analyzing cycle time helps identify long-running processes and set benchmarks for process improvement initiatives.

Why it matters

This calculated metric is a key performance indicator for overall process efficiency and is crucial for dashboards tracking time-to-hire.

Where to get

This attribute is not available in iCIMS directly. It is calculated in the process mining tool by taking the difference between the maximum and minimum ActivityStartTime for each JobApplicationId.

Examples
45 days 10 hours62 days 4 hours30 days 0 hours
Required Recommended Optional

Recruitment & Talent Acquisition Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and bottleneck identification within your hiring funnel.
7 Recommended 8 Optional
Activity Description
Application Received
Marks the start of the recruitment process for a specific job application. This event is captured when a candidate successfully submits their application through a career portal or it is manually entered into iCIMS.
Why it matters

This is the primary start event for the process. Analyzing the time from this activity to subsequent milestones is essential for understanding overall time-to-fill and identifying front-end bottlenecks.

Where to get

Typically inferred from the creation date of the application record or a timestamp associated with an initial status like 'Submitted' or 'New Application' in the candidate's workflow history.

Capture

Use the creation timestamp of the job application record or the first status change timestamp.

Event type inferred
Application Rejected By Company
The company has decided not to move forward with the candidate at some stage of the process. This is captured by a recruiter or hiring manager updating the application status to a terminal 'Rejected' or 'Not Selected' state.
Why it matters

This is the most common end-point. Analyzing at which stage most rejections occur is fundamental to understanding recruitment funnel effectiveness and identifying bottlenecks.

Where to get

Inferred from a status change to a terminal rejection status, such as 'Rejected', 'Not Selected', or 'Position Filled'. iCIMS often requires a disposition reason.

Capture

Detect status change to any terminal non-hired, non-withdrawn status.

Event type inferred
Candidate Hired
The final activity indicating a successful recruitment process. This event is logged when the candidate is moved to a final 'Hired' status, officially concluding the application process and often triggering onboarding workflows.
Why it matters

This is the primary success end-point for the process. It is essential for calculating the overall time-to-hire and hiring funnel conversion rates.

Where to get

Inferred from the timestamp of the final status change to 'Hired' or 'Started' in the application workflow. This is a terminal status.

Capture

Capture timestamp of status change to the final 'Hired' status.

Event type inferred
Candidate Submitted To Hiring Mgr
A recruiter formally presents a qualified candidate's profile to the hiring manager for review. This is usually captured when the recruiter moves the candidate to a specific 'Hiring Manager Review' step in the iCIMS workflow.
Why it matters

This is a critical handoff point. Measuring the time from this step to manager feedback is key to identifying delays in the hiring manager's part of the process.

Where to get

Inferred from the timestamp when the application status is changed to 'Submitted to Hiring Manager', 'HM Review', or a similar status indicating the manager's involvement.

Capture

Capture timestamp of status change to 'Hiring Manager Review' or equivalent.

Event type inferred
First Interview Conducted
This activity signifies that the first round of interviews with the candidate has been completed. It is typically recorded when a recruiter or hiring manager updates the candidate's status after the interview has taken place.
Why it matters

This is a major milestone in the evaluation process. The time between this event and feedback submission is critical for the 'Hiring Manager Feedback Cycle' analysis.

Where to get

Inferred from a status update in the application workflow to a status like 'Interview Completed', 'Awaiting Feedback', or 'First Interview Complete'.

Capture

Detect status change to 'Interview Complete' or a related status after the scheduled interview date.

Event type inferred
Offer Accepted
The candidate has formally accepted the job offer. This is a key success milestone, recorded when the recruiter updates the candidate's status based on their response.
Why it matters

This activity is crucial for calculating the offer acceptance rate and signals the transition towards pre-employment checks and onboarding.

Where to get

Inferred from a timestamped status change to 'Offer Accepted' or 'Hire Pending' in the application workflow.

Capture

Identify timestamp of status change to 'Offer Accepted'.

Event type inferred
Offer Extended
A formal job offer has been created and extended to the candidate. This is a critical milestone and is typically captured by changing the application's status to a dedicated 'Offer' stage.
Why it matters

This activity is the numerator for the 'Offer Acceptance Rate' KPI. It marks the beginning of the final decision-making phase of the recruitment process.

Where to get

Inferred from a status change in the application workflow to a status such as 'Offer Extended', 'Offer Made', or 'Verbal Offer'.

Capture

Capture timestamp of status change to any 'Offer' related status.

Event type inferred
Application Screened
Represents the completion of the initial review of an application by a recruiter. This activity is typically inferred when an application's status is changed from a 'new' state to one indicating review, such as 'Under Review' or 'Screening'.
Why it matters

Tracking this activity helps measure recruiter efficiency and the time-to-screen KPI. Delays here can cause candidate drop-off and extend the overall hiring timeline.

Where to get

Inferred from a status change on the application profile. Look for changes from an initial status to a status like 'Reviewed', 'Screened', or 'Under Consideration'.

Capture

Identify timestamp of status change to a 'reviewed' or 'screened' status.

Event type inferred
Background Check Initiated
Represents the start of the pre-employment screening process after an offer has been accepted. This is often tracked by moving the candidate to a 'Background Check' status, which may trigger an integration with a third-party vendor.
Why it matters

Analyzing the time from 'Offer Accepted' to this activity helps identify delays in pre-employment processes, which can impact the candidate's start date.

Where to get

Inferred from a status change to 'Background Check in Progress' or a similar status. Some iCIMS integrations may log this as an explicit event.

Capture

Detect status change to a 'Background Check' status.

Event type inferred
Candidate Phone Screened
Indicates that a recruiter has conducted a preliminary phone interview with the candidate. This event is usually captured when a recruiter updates the candidate's status in their workflow after the call is completed.
Why it matters

This is a key filtering stage in the recruitment funnel. Analyzing its duration and conversion rate helps assess the quality of initial screening and sourcing.

Where to get

Inferred from a status change in the candidate workflow to a status such as 'Phone Screen Completed', 'Advanced to Next Step', or a similar custom status.

Capture

Detect status change to 'Phone Screen' or a similar configured status in the application workflow.

Event type inferred
Candidate Withdrew Application
The candidate has voluntarily removed themselves from consideration for the role. This is recorded when the candidate informs the recruiter, who then updates the application status to 'Withdrawn'.
Why it matters

This is a critical failure end-point. High withdrawal rates at certain stages may indicate a lengthy process, poor communication, or a negative candidate experience.

Where to get

Inferred from a timestamped status change to 'Withdrawn by Candidate', 'Withdrew', or a similar terminal status in the iCIMS workflow.

Capture

Capture timestamp of status change to 'Withdrawn' or equivalent.

Event type inferred
Feedback Submitted
Occurs when a member of the hiring team, typically the hiring manager, submits their evaluation of the candidate post-interview. iCIMS allows for structured feedback capture, and this event can be inferred from the creation of that feedback record.
Why it matters

Essential for measuring the 'Avg Hiring Mgr Feedback Time' KPI. Delays in feedback submission are a common bottleneck that slows down the entire hiring process.

Where to get

Inferred from the creation timestamp of an interview feedback record associated with the application. It may also be a specific status change like 'Feedback Received'.

Capture

Use the creation timestamp of the interview feedback entry in the system.

Event type inferred
First Interview Scheduled
Represents the point where an interview has been scheduled between the candidate and the hiring team. iCIMS has scheduling capabilities, and this is captured when an interview event is created and associated with the application.
Why it matters

Marks the transition from screening to formal evaluation. Tracking this helps analyze scheduling efficiency and the time taken to engage qualified candidates.

Where to get

Can be an explicit event from the iCIMS interview scheduling module or inferred from a status change to 'Interview Scheduled' or a similar state.

Capture

Use the creation date of the interview record or the timestamp of a status change to 'Interviewing'.

Event type inferred
Offer Rejected
The candidate has formally declined the job offer. This is an unsuccessful outcome, captured when a recruiter updates the candidate's status to 'Offer Declined' or 'Offer Rejected'.
Why it matters

This is a key failure end-point. Analyzing when and why offers are rejected provides insights into compensation competitiveness and candidate experience.

Where to get

Inferred from a status change in the application workflow to a terminal status like 'Offer Rejected' or 'Offer Declined'.

Capture

Identify timestamp of status change to 'Offer Rejected' or equivalent.

Event type inferred
Second Interview Scheduled
Indicates that the candidate has advanced and a subsequent round of interviews is being arranged. This is captured when a new interview event is scheduled or the candidate is moved to a 'Second Interview' stage.
Why it matters

Analyzing the frequency of and time leading to second interviews helps understand process depth and identify whether some roles require excessive interview rounds.

Where to get

Inferred from a status change to 'Second Interview Scheduled' or the creation of a new interview record for a candidate already interviewed.

Capture

Identify a status change or a new interview record being created for the same application.

Event type inferred
Recommended Optional

Extraction Guides

How to get your data from iCIMS