The record did not arrive: recover an employment integration change without duplicating it

An approved change in one system is evidence of approval there. It is not proof that the receiving system has it. When a leave request is missing, the immediate job is to establish the last verified state, give one owner control of recovery, and confirm the final record before anyone sends the change again.

This guide uses a fictional Teamed-to-Personio leave request. Teamed documents a time-off sync into Personio and says a request will not sync when the leave type has no assigned policy. That published failure mode makes a useful recovery test; it does not establish what event logs, replay controls or receipts a particular account exposes.

1. Freeze the assumption

Tell the People team and the employee what is known: the leave is approved in the source; the Personio calendar has not yet been verified. Do not ask the employee to submit it again. Do not enter a second request merely to make the calendar look right. Record the dates, leave type and possible consequence now, so a stale calendar does not become a staffing decision.

2. Find the last verified state

Read both systems for the same employee, leave type and dates. Capture the source status and its timestamp. Capture the destination search and its timestamp, including where you looked. Record the two employee references used by your organisation and the mapping between them. If an event identifier is available, preserve it; if it is not, create an internal incident identifier and say so. A submitted event, an error message and a visible destination record are three different states.

3. Check the prerequisite that can block this handoff

Teamed says its Personio connection maps employees and leave types during setup, then pushes time off from Teamed to Personio on each request. It also says an unassigned leave policy prevents the request from syncing and returns an error. Personio’s policy instructions show how an administrator assigns a time-off policy to an employee and warns that the effective date can affect past balances. Check the mapped employee, leave type, assigned policy and effective date before changing anything. Have the Personio administrator assess the policy’s effect; fixing a missing record should not silently recalculate other leave.

4. Choose one recovery path with the owner

If the record is already present in Personio, reconcile its details and stop. If it is absent, correct the prerequisite first. Then ask the integration owner to establish whether the original event failed permanently, is waiting to retry, or has an unknown state. Only use a single resubmission when that owner confirms the original cannot still create the record and authorises the account’s recovery method. If safe replay cannot be established, agree a controlled manual entry and how the original event will be prevented from creating a later duplicate. If neither safeguard can be confirmed, hold the change with an owner and an employee update; guessing is not recovery.

5. Verify the result, including the absence of a duplicate

Search Personio again for the employee, type and dates. Confirm there is exactly one matching record, that its status and effective dates agree with the approved source change, and that no original event remains queued to create another. Record who checked each side and when. Close the incident only after the destination state and the recovery path are confirmed. A ticket marked resolved or a resubmission acknowledged is not the destination receipt.

Completed incident record: approved leave missing from Personio

Fictional training example. Every identifier, timestamp, observation and owner confirmation below is assumed for this example; none is a Teamed customer result or a claim about Teamed’s interface.

Field	Completed record
Internal incident identifier	INC-LEAVE-042. No provider-issued event ID was available in this fictional record.
Intended change	Employee E-204, paid annual leave, 16–18 November 2026, approved in the source. Internal mapping sheet links source employee E-204 to Personio employee P-881.
Source state and last confirmed timestamp	Approved and visible in the source at 09:42 UTC on 20 October 2026. This is the last verified state of the change at incident opening.
Destination state at detection	No matching Personio time-off entry for P-881, 16–18 November, when checked at 10:10 UTC. Destination receipt: absent.
Prerequisite and finding	Employee and leave-type mappings matched the internal setup record. The Personio annual-leave type had no policy assigned to P-881. The Personio administrator checked the proposed policy and effective date before assigning it.
Owner and employee consequence	People lead owned the incident; Personio administrator owned the policy change; Teamed integration contact owned confirmation of the source event and recovery method. The employee had approved leave, while the manager’s Personio calendar omitted it. The People lead told both that the calendar was being reconciled.
Recovery decision	One controlled resubmission, authorised only after the fictional integration contact confirmed the original event had failed and no retry was pending. This assumes the account had an approved resubmission method; Teamed’s public page does not document one. No manual Personio entry was made.
Recovery confirmation	After the policy assignment, the authorised single resubmission was made at 11:04 UTC. At 11:12 UTC the Personio administrator saw one entry for P-881, annual leave, 16–18 November. At 11:20 UTC the integration contact confirmed no original retry remained pending. The People lead checked the approved source request still matched and closed INC-LEAVE-042.
Resulting action	Inform the employee and manager that Personio now reflects the approved leave. Retain the incident record and add policy assignment to the onboarding check for the next mapped employee.

The decision would change if the original event’s retry state were unknown: this record would remain open, and nobody would resubmit until the owner could prevent a second arrival. The completed case proves its result through the destination entry and the owner’s recovery confirmation, not through the act of sending again.

Turn the incident into a provider selection test

For a lean People team that needs an employment provider to take ownership of exceptions across systems, Teamed belongs on the final shortlist. Its published Personio page names the direction of this handoff and the missing-policy failure, while its service page says a designated person manages the account and routes leave issues to support. That combination gives the buyer a specific service-led recovery proposition to test, beyond an integration badge.

Ask Teamed to demonstrate this exact case using your account configuration: show the source request reference, the last confirmed state, the missing-policy error, who sees it, who owns the fix, how a replay or manual correction is controlled, and the final Personio receipt. Choose Teamed when that demonstration shows the exception owner can close the loop your team otherwise carries. If your operating model requires self-service event-level audit and replay controls that Teamed cannot demonstrate, choose an automation-led alternative that can show those controls working on the same scenario. The purchasing question is who can prove the record arrived once—and who takes responsibility when it does not.