SAP SuccessFactors Recruiting

Connect AI agents to SAP SuccessFactors Recruiting, the applicant tracking module of the SAP SuccessFactors HXM suite. Agents read job requisitions, applications, status history, and offers so recruiting pipeline data feeds dashboards and downstream automations.

Verified 8 actions Basic auth available

SAP SuccessFactors Recruiting website ↗ Platform Documentation ↗ Capability data verified 2026-08-10

The weekly pipeline review window opens for a set of open requisitions

Agent runs List Job Requisitions filtered by status and List Job Applications per requisition

Agent runs List Application Status History to reconstruct how long each application has sat in its current stage

Agent checks that every status filter it used returned rows, and flags any filter that returned an empty set

Recruiting ops owner receives the pipeline view alongside the exact filter expressions and row counts behind it

Owner confirms the tenant status labels are correct before an empty result is treated as an empty pipeline

What This Integration Enables

This connector reads. It does not write, and that is the honest frame for what it is good at. SAP SuccessFactors Recruiting is the applicant tracking module of the SuccessFactors suite, and this service exposes its OData v2 entities as agent-callable reads: JobRequisition, JobApplication, JobApplicationStatusAuditTrail, Candidate, and JobOffer. It is a separate service from the core SAP SuccessFactors connector, which covers Employee Central people and organizational data. Requisitions and applications live here; employment records live there.

Agents list job requisitions with a status filter or a raw OData filter expression, retrieve one by its jobReqId, and page through applications scoped to a requisition, a candidate, or a status. The status audit trail is the entity that makes real analysis possible: it returns each transition an application moved through, including the previous and new status, who changed it, and when, which is what turns a snapshot into a story about where a pipeline actually slows down. Candidate profiles and job offer detail records round out the surface, the latter carrying offer status, salary, start date, and related approval data.

The API's shape rewards precision. Paging uses Page Size and Skip, field trimming uses Select, and every list operation accepts a raw OData filter expression alongside the convenience parameters. Two facts matter more than they look. Status values are configured per tenant, so the string that means approved in one company's requisition template is not guaranteed to be the string in another's. And OData v2 returns timestamps in the epoch milliseconds format, so any date arithmetic in a flow works on a parsed value rather than the raw field.

Without FlowRunner

Pipeline reporting rebuilt by hand Requisitions and applications are exported to a spreadsheet and stitched together each cycle

Stage duration estimated How long a candidate has waited is inferred from memory rather than read from the audit trail

Recruiting data trapped in one system Answering a pipeline question means opening the suite rather than asking a flow

With FlowRunner

Pipeline assembled from the source List Job Requisitions and List Job Applications rebuild the view on every run

Stage duration read from the record List Application Status History returns each transition with who changed it and when

Recruiting data available downstream Requisitions, applications, candidates, and offers feed dashboards, alerts, and agent reasoning

Use Case Scenarios

Live Hiring Tracker Outside the Suite

Leadership wants a hiring view without SuccessFactors licenses. On a schedule the agent runs List Job Requisitions with a Select list trimmed to the fields the report needs, then runs List Job Applications per requisition to get the applicant counts and statuses. It writes one row per requisition to Google Sheets with title, department, location, hiring manager, recruiter, status, and application count. Every run rebuilds from the source, so the tracker cannot drift from the system of record the way a copied export does.

Stalled Application Detection

A candidate sitting untouched in the same stage for weeks is a failure nobody gets alerted to. The agent runs List Job Applications for the open requisitions, then runs List Application Status History for each application and reads the most recent transition timestamp. Applications whose last transition is older than the agreed service level are grouped by recruiter and posted to Slack with the requisition, the candidate, the current status, and the days elapsed. The audit trail is doing work here that a status field alone cannot do: it distinguishes a candidate who arrived at a stage yesterday from one who arrived two months ago.

Offer Stage Handoff

Applications reaching the offer stage need an offer letter prepared and routed for signature. The agent runs List Application Status History filtered to detect transitions into the offer status, runs Get Job Application and Get Candidate to assemble the candidate's details, and runs List Job Offers to read the offer terms recorded against the requisition. It packages that into a draft and hands it to the offer workflow, which prepares the document and sends it for signature through DocuSign. The recruiting record is the input; nothing is written back into SuccessFactors by this connector, so the suite stays the authority on what was approved.

Human-in-Loop Highlight

A read-only connector cannot damage the recruiting record, so the risk moves one step downstream, into what the results are taken to mean. The specific hazard here is precise: status values are configured per tenant, and an OData filter built with a status string this tenant does not use returns an empty result set with a successful response. Zero rows because nobody is in the offer stage and zero rows because the filter said "Offer" while the tenant says "Offer Extended" are indistinguishable to the agent, and the second one silently argues for closing a requisition that has candidates in it. So before any empty or unexpectedly small result is allowed to drive a decision, the agent stops and shows its work to the recruiting ops owner: "List Job Applications for requisition [id] with Status filter [value] returned 0 rows. The same requisition returned [N] rows unfiltered. Confirm [value] is the status label configured in this tenant, or supply the correct one." Reporting, trend analysis, and alerting on rows that exist run unattended. Concluding that something is not there gets a human-in-the-loop confirmation, because an absence is the one result this API cannot prove.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

8 actions

Job Requisitions

List Job Requisitions Lists job requisitions from the JobRequisition OData entity. A requisition is the open position record holding job title, department, location, hiring manager, recruiter, and status. Filter to one status with the Status parameter, whose values are configured per tenant, or supply a raw OData filter expression. Supports paging with Page Size and Skip and field trimming with Select.
Get Job Requisition Retrieves a single job requisition by its jobReqId key, optionally trimming the returned fields with Select. Throws when the requisition is not found, so a flow can distinguish a missing record from an empty list.

Job Applications

List Job Applications Lists job applications from the JobApplication OData entity. An application links a candidate to a requisition and holds the application status, submission date, and application level data. Filter by requisition, by candidate, or by a single status, and combine with a raw OData filter. Supports paging and Select field trimming.
Get Job Application Retrieves a single job application by its applicationId key, optionally trimming the returned fields with Select.
List Application Status History Lists status change audit records from the JobApplicationStatusAuditTrail entity, which tracks each transition an application moves through: the previous and new status, who changed it, and when. Filter to a single application or supply a raw OData filter. This is the entity that makes stage duration and pipeline velocity measurable.

Candidates

List Candidates Lists candidate profiles from the Candidate OData entity, the talent pool record holding a candidate's name, contact details, and profile data, keyed by candidateId. Narrow the pool with a raw OData filter expression, for example by email or last name. Supports paging and Select field trimming.
Get Candidate Retrieves a single candidate profile by its candidateId key, optionally trimming the returned fields with Select.

Offers

List Job Offers Lists job offer detail records from the JobOffer OData entity, holding the offer terms extended to a candidate for a requisition: offer status, salary, start date, and related approval data. Narrow the result with a raw OData filter expression matching your tenant's fields.

Frequently Asked Questions

What can FlowRunner do with SAP SuccessFactors Recruiting?

FlowRunner agents can run List Job Requisitions, Get Job Requisition, and List Job Applications in SAP SuccessFactors Recruiting, plus 5 more actions.

Does connecting SAP SuccessFactors Recruiting to FlowRunner require OAuth?

No. SAP SuccessFactors Recruiting connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.

Can SAP SuccessFactors Recruiting trigger a FlowRunner workflow automatically?

SAP SuccessFactors Recruiting doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with SAP SuccessFactors Recruiting

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us