Dear Experts
I have the following scenarie . We want create a flow in N8N using agent for do the termination of the employeee in SAP Successfactor.
This is possible?
Regards
@testn8n_Santiago yeah its doable. theres no native successfactors node, so you drive it with the HTTP Request node hitting SuccessFactorsâ OData API, and your agent calls that http request as a tool. for termination specifically you either post an EmpJob record with a termination eventReason, or use the EmpEmploymentTermination API which creates that EmpJob for you. the one real prerequisite is API access on the SF side, an oauth/api user with permission to write employment data. do you already have that API access provisioned?
If I have access.
In that case, should I create an MCP Server to add this Tools?
if youve got access then no, you dont need an MCP server for a single action like this. just attach an HTTP Request Tool node to the agent pointed at the EmpEmploymentTermination endpoint, and the agent calls it directly as a tool. MCP only earns its keep when youre building a whole reusable library of successfactors tools to share across agents and workflows, for one termination call its overkill. the http request tool is the cleaner path here.
Thanks!
Iâll try it and give you feedback. Thanks again for your answer.
Should I use a specific model or do you have any recommendations?
Then I would just put in the System Prompt what it should do, right?
any of the strong tool-calling models handle it fine, gpt-4o, claude sonnet, or gemini 2.5. for something like this id lean to a reliable one over a cheap small model, precision on the tool call matters more than saving cents. and yeah, the system prompt is where you tell it what to do and when to fire the tool. one thing worth adding, termination is irreversible, so dont let the agent run it fully autonomously, put a confirmation step or a hard check on the employee id in front of it so a wrong call cant terminate the wrong person.
Welcome @testn8n_Santiago to our community!
For an employee termination flow in SuccessFactors, Iâd recommend starting with a very small âagent + HTTP toolâ prototype first, then wrapping more logic around it once the core call is reliable. In practice that means: create an AI Agent node, attach a single HTTP Request Tool pointing to the EmpEmploymentTermination OData endpoint, and configure that tool with the same auth, URL and headers you already use successfully in Postman, including the eventReason, userId and startDate fields in the body. In the system prompt, be explicit that the agent must only ever call this tool for a single, clearly identified employee, and that it should surface the final payload (employee ID, effective date, reason) in natural language before you execute anything, so you can review what will be sent to SuccessFactors. Because termination is a highârisk action, Iâd also add a humanâinâtheâloop step around this tool (for example: the agent prepares the payload, but the workflow pauses for your approval before the HTTP tool runs) so you always have a last manual check before the record is written.
If you share the exact EmpEmploymentTermination payload you use in Postman (with IDs anonymized), I can help you turn that into a readyâtoâpaste HTTP Request Tool configuration for your agent.
If you want to avoid writing raw HTTP queries for every single entity, you can install an open-source community node onto your self-hosted instance: Go to Settings > Community Nodes and search for n8n-nodes-sap-odata or n8n-nodes-odata.
These community plugins help parse metadata, automate the extraction of required CSRF tokens for write/POST operations, and streamline the pagination structure.
This is
Operation:
Upsert
HTTP Method
POST
URI
https:///odata/v2/upsert
Payload
{
"__metadata":{
"uri":"EmpEmploymentTermination"
},
"personIdExternal":"1234567",
"userId":"1234567",
"endDate":"/Date(1558556800000)/",
"eventReason":"TERRTMNT"
}
@testn8n_Santiago it works in Postman but not n8n because of the CSRF handshake. SuccessFactors OData writes need an X-CSRF-Token plus the session cookie, both pulled from a GET first. Postmanâs cookie jar does that automatically, n8n doesnât, so a single HTTP Request Tool canât (sergeys hinted at this).
Build it as a 2-step sub-workflow and give the agent a Call n8n Workflow tool:
- HTTP Request GET to https://your-server/odata/v2/ with Basic auth + header X-CSRF-Token: Fetch. Enable âInclude Response Headers and Statusâ to capture the x-csrf-token and set-cookie.
- HTTP Request POST to /odata/v2/upsert with Basic auth, the X-CSRF-Token and Cookie from step 1, and your EmpEmploymentTermination JSON as the body.
Or use sergeysâ n8n-nodes-sap-odata node, which handles CSRF for you. Keep nguyenthieutoanâs human-in-the-loop confirm, termination canât be undone.
@testn8n_Santiago close, auth and payload are right (Basic Auth, correct datacenter, the EmpEmploymentTermination body). Two fixes:
-
Itâs on GET, which only reads. The termination is a write, so it has to be POST to /odata/v2/upsert (your body already has __metadata.uri, which is what upsert expects).
-
A single HTTP Request still canât do the CSRF handshake SF requires. You need two: a GET to /odata/v2/ with header X-CSRF-Token: Fetch and âInclude Response Headers and Statusâ turned on (to grab the token + set-cookie), then the POST to /odata/v2/upsert carrying that X-CSRF-Token and Cookie plus your JSON.
A tool node is one call, so put those two requests in a small sub-workflow and attach that to the agent as a Call n8n Workflow tool. Thatâs what makes it actually fire.
Hey @testn8n_Santiago, youâre on the right track with the 2-step setup!
One thing to double-check on your second HTTP Request node (the POST): make sure youâre passing the x-csrf-token and cookie values from the response headers of the first GET, not hardcoded. In n8n you can reference them like:
X-CSRF-Token: {{ $(âHTTP Request 1â).first().headers[âx-csrf-tokenâ] }}
Cookie: {{ $(âHTTP Request 1â).first().headers[âset-cookieâ] }}
Also confirm your POST body has Content-Type: application/json set as a header, otherwise SuccessFactors may reject it even with a valid CSRF token.
Once those two nodes are working together, wrap them in a sub-workflow and connect it to your agent as a Call n8n Workflow tool, thatâs the final step to make the agent actually trigger the termination. Keep that human approval step before it fires!
@testn8n_Santiago your GET and POST are hooked up as two separate tools on the agent, so the POST cant see what the GET returned, its input panel only shows the chat trigger, not HTTP Request1. thats why theres nothing to map.
they need to run in sequence, GET then POST, inside a little sub-workflow that you hand to the agent as one Call n8n Workflow tool (not the two http nodes directly). once the POST sits after the GET you can pull:
X-CSRF-Token: {{ $(âHTTP Request1â).item.json.headers[âx-csrf-tokenâ] }}
Cookie: {{ $(âHTTP Request1â).item.json.headers[âset-cookieâ].join('; ') }}
also i didnt spot x-csrf-token in your GET response, so make sure the GET sends request header X-CSRF-Token: Fetch, thats what makes SF return the token.
@testn8n_Santiago yeah youre on the right track, the hard partâs done. the sub-workflow is trigger â GET â POST as one Call Workflow tool, the GET is pulling the x-csrf-token (i can see it in its output), and the POST maps the token + cookie from it. thats the whole CSRF handshake working.
main thing to fix: the tools Description still has the default ârandom color, comma separated colors to excludeâ text. the agent reads that to decide when and how to call the tool, so change it to what it actually does, something like âTerminates an employee in SuccessFactors. Input: the employees UserId.â thats almost certainly the warning on your agent.
small watch-out: the x-csrf-token shows url-encoded in the GET output (%2f, %2b etc). n8n usually sends it fine, but if the POST comes back 403 on CSRF, decoding that token is the first thing to check.