p24-infra Docs

ecotrans-hr-workflow-operations

5 min read

ecotrans-hr-workflow — Operations

Purpose

n8n Cloud workflow that syncs HR-related records from Pinbox24 W4 into a Google Sheet and notifies the HR department by email. Runs on n8n Cloud (https://p24.app.n8n.cloud), not bms-4.

  • Workflow ID: bT6grVXtfLOzYf9j
  • Workflow name (exact, case-sensitive): ecotrans-hr-workflow
  • Trigger: Webhook, POST, path 2c806402-bce0-42bb-94b1-f63757c247b4
  • Status as of 2026-07-30: active: true, wiring verified intact (see Incident History)

What calls the webhook (confirmed 2026-07-30)

Traced via the W4 backend source (gitlab.com/pinbox24/p24-back-ts, branch development) and MongoDB rs0 (w4_db, read-only w4_app). Pinbox24’s process engine is data-driven — the webhook call isn’t in the TypeScript source at all, it’s config stored in Mongo, executed by the generic make_request task type (src/apps/processes/processInstances/processTaskHelpers/tasks/make_request/make_request.ts).

  • Process: w4_db.process.configs, _id: 66cc611fa9bbec01d424da36, name holidays-apply-process (status preparation) — the employee leave/vacation-request workflow.
  • Activity 59 (trigger, titled “n8n hr - flow webhook emp_id to pass with _id of employer record not instance or apply record”): a make_request task, POST to exactly https://p24.app.n8n.cloud/webhook/2c806402-bce0-42bb-94b1-f63757c247b4?startDate=##start##&email=##creatorEmail##, body { startDate: '##start##', email: '##creatorEmail##' }. This fires automatically once a manager approves an employee’s leave request — it is not a manual button click on the happy path.
  • Activity 60 (act, role admin, immediately after 59, titled “restry [sic] webhook to n8n”): an admin-only manual retry button for when the activity-59 POST fails. This is almost certainly what the n8n-side node name hrProcessUpdate_clickButtonXXX refers to.
  • Registry 66cc4258a9bbec01d424d9c6 (w4_db.registries) is named Mitarbeiter (“employees” — German) — the employee master registry, confirming this is the same HR/leave data the n8n workflow reads via GET /api/reg/.../data-table.

If this stops firing, check holidays-apply-process activity 59/60 config in w4_db and the Pinbox24 app’s leave-approval flow before assuming the n8n side is at fault.

Pipeline (verified via n8n API, 2026-07-30)

Webhook (POST /webhook/2c806402-...)
  └─> p24-auth  (HTTP Request → https://p24-auth.radieu.workers.dev/token)
        │  mints a Pinbox24 JWT via the CF Worker — see docs/p24-auth-worker-operations.md
        │  credential: httpHeaderAuth "p24-auth-automation-key" (id g7S3Dsl2AQmTn5Yh)
        └─> Code                       — extracts token from the Worker response
              └─> Edit Fields2         — builds the Authorization header expression
                    └─> HTTP Request   — GET api.w4.pinbox24.com/api/reg/66cc4258a9bbec01d424d9c6/data-table
                          └─> Edit Fields1
                                └─> HTTP Request2  — GET .../66cc4258a9bbec01d424d9c6/{{ record _id }}
                                      └─> Google Drive
                                            └─> Switch
                                                  ├─> Google Drive1 ─> Switch1 ─┬─> prepare model to put in excel ─> createOrUpdateRecord ─> hrProcessUpdate_clickButtonXXX
                                                  │                             └─> Code1 ─> notify hr department (Gmail)
                                                  └─> Code1 ─> notify hr department (Gmail)

When clicking 'Test workflow' (manual trigger) --> also wired to p24-auth, for editor testing only
  • HTTP Request / HTTP Request2 send their authorization header as an n8n expression (={{ ... }}, not a hardcoded literal) built from the p24-auth token — this is the correct pattern, not a 3800-style hardcoded-secret violation.
  • Pinbox24 registry ID 66cc4258a9bbec01d424d9c6 is the HR data-table this workflow reads from.
  • createOrUpdateRecord (Google Sheets) and notify hr department (Gmail) are the two externally-visible side effects — a Sheets row upsert and an email to HR.
  • Exact Switch/Switch1 branch conditions were not inspected — read the node parameters directly in the n8n UI if you need to trace a specific record’s path.

Incident History

2026-07-30 — trigger disconnected from pipeline (fixed)

Both the Webhook and When clicking 'Test workflow' trigger nodes had zero outgoing connections — the entire downstream pipeline (p24-auth → … → notify hr department) was fully wired internally but not reachable from either trigger. A POST to the live webhook would return normally but silently execute nothing.

Root cause: resolved by timeline reconstruction (2026-07-30), pointing to the user’s own n8n Cloud UI session. Exact timestamps, cross-referenced against the session transcript:

EventTime (UTC)
ai-documents-inbox-folders processing updatedAt (found active: false)02:06:44.633Z
ecotrans-hr-workflow updatedAt (connections broken)02:09:56.646Z
User’s message reporting the disconnected node (screenshot)02:11:50.068Z

Both breaks happened before the user’s message, ruling out any p24-infra-side response to it. The earlier candidate — an n8n Cloud API PUT /workflows/{id} used to attach node credentials during unrelated #4177 remediation in the same session — is also ruled out: those writes landed at 2026-07-29T15:12–16:47Z (original fix) and ~19:17–19:46Z (a later credential-reattachment recheck), 6–11 hours before the breaks. No API write from this session falls inside the 02:06–02:10Z window.

What does fall in that window: two different workflows, each updated once, about 3 minutes apart. An automated script hitting both workflows would fire its two PUTs seconds apart, not minutes — the ~3-minute gap reads as a human switching between two open workflow tabs in the n8n Cloud editor, consistent with the user’s own account (“i did this ui step”). Most likely explanation: an n8n Cloud UI save on one or both workflows had a connections/active-flag side effect beyond the field the user intended to change (Send Headers) — not conclusively provable without n8n Cloud’s UI-only version history, but no other candidate fits the timeline.

Fix: fetched the live workflow, added exactly the two missing edges (Webhook → p24-auth, manual trigger → p24-auth) via a targeted PUT, and verified via immediate GET that node count, p24-auth’s attached credential, and every other existing connection were unchanged — only the two intended edges were added.

Prevention / what to check after any n8n Cloud API write to this or the AI-inbox workflow: re-fetch the workflow and confirm every trigger node still has non-empty outgoing connections, not just that node parameters/credentials look right. A credential-attachment check alone would not have caught this.

Health check

# Confirm the Webhook trigger is still wired to p24-auth (the failure mode above)
$cloudUrl = ...  # N8N_CLOUD_BASE_URL from secrets/n8n-bms4.env.sops
$wf = Invoke-RestMethod -Uri "$cloudUrl/workflows/bT6grVXtfLOzYf9j" -Headers $headers -Method GET
$wf.active                                  # expect True
$wf.connections.Webhook.main[0].node         # expect "p24-auth" present, not empty

Or in the n8n UI: open the workflow canvas, confirm a visible line runs from Webhook to p24-auth (not just from p24-auth onward).

Graph View