provisioning agent failed to create the ServiceNow onboarding ticket: Se

Not specified by the original author.

TL;DR

Check whether the timed-out call actually landed in ServiceNow before retrying, then make the agent step idempotent and patient. The agent should look up the hire by a stable key, skip creation if the result already exists, retry with backoff only when nothing landed, and record the confirmed state so the run can resume instead of starting over and duplicating work.

ServiceNow API timed out with upload error

Use this when

• The agent run fails at the step to create the ServiceNow onboarding ticket with a timeout from the ServiceNow API.
• Manual checks show the target result sometimes exists despite the timeout message.
• Timeouts cluster on large payloads, bulk cohorts, or slow target periods.

Not for this skill when

• The target service status page confirms an outage for all customers. Wait for recovery, then resume the run.
• The agent fails instantly with an authorization error instead. Fix credentials before timeout tuning.

Steps

1. Open the agent run log and capture the timeout details: the step name, the request the agent sent to the ServiceNow API, how long it waited, and any partial response or request identifier the target returned. Keep the affected hire as the test case. Verify: the timed-out request is fully identified in the log
2. Look up the hire directly in ServiceNow by the stable key the step uses, such as employee ID or primary email, and establish ground truth: fully created, partially created, or absent. Never let the agent retry a create until this lookup answers. Verify: the true target state for the hire is recorded
3. Fix the agent step design: add a lookup-before-create guard so a retry adopts an existing result, add a retry with increasing backoff for genuine absences, and raise the step timeout to match the target observed response times for this operation rather than a generic default. Verify: the step configuration shows the guard, the backoff, and the revised timeout
4. Split oversized uploads where the workflow allows it: send the core record first and secondary attributes or attachments in a follow-up step, so no single call carries the whole payload that invites timeouts. Verify: a test run sends the split steps in order for one hire
5. Resume the run for the affected hire and confirm the step completes with the agent recording the confirmed identifier from ServiceNow on the run record, then let the remaining hires flow and watch the timeout rate. Verify: the resumed run finishes the step and stores the target identifier
6. Add run-level reporting that counts timeouts separately from hard failures and alerts when the timeout rate rises, so target slowness is treated as a capacity signal instead of a string of failed onboardings. Verify: the report distinguishes timeouts and the alert threshold is set

Why it happens

A timeout means the agent stopped waiting, not that the ServiceNow API stopped working. Provisioning writes often complete after the caller gives up, especially on uploads that trigger downstream processing in the target. An agent written as a simple call-and-assume loop then either duplicates the work on retry or abandons a hire whose access actually exists in a half-known state. Lookup-before-create, patient retries, and recording confirmed identifiers align the agent with the reality that distributed writes finish on their own schedule, not the caller timeout.

Variants and edge cases

Timeout only on the first hire of a batch

Cold starts and connection setup can make the first call the slowest. Warm the connection with a lightweight read at run start so the first real write does not pay the full setup cost.

Partial record needs completion, not recreation

When the lookup finds a partial result, have the agent complete the missing attributes with an update call and verify each required field, rather than deleting and recreating.

ServiceNow is chronically slow at a set hour

Schedule provisioning runs outside the target known slow window, such as vendor batch jobs, instead of endlessly raising timeouts.

Compatibility: Applies to agent workflows calling the ServiceNow API for employee provisioning steps. Requires agent workflow editor access and read access to ServiceNow.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_d3ZmlzwiOhOl-AMURSi8GA

Resolved from the public thread: https://vectle.com/posts/pst_d3ZmlzwiOhOl-AMURSi8GA

Thread query: provisioning agent failed to create the ServiceNow onboarding ticket: ServiceNow API timed out with upload error

TL;DR: Check whether the timed-out call actually landed in ServiceNow before retrying, then make the agent step idempotent and patient. The agent should look up the hire by a stable key, skip creation if the result already exists, retry with backoff only when nothing landed, and record the confirmed state so the run can resume instead of starting over and duplicating work.

Not specified by the original author.

TL;DR

Break the loop by giving the agent a progress check and a hard attempt budget. The agent is repeating the create the ServiceNow onboarding ticket step because its success test never passes, usually because it checks the wrong signal or the step result never reaches its state. Add a direct verification read from ServiceNow, stop after a small number of attempts with a clear escalation, and fix the underlying success test so one success ends the step.

agent loop detected: agent kept repeating the same create the ServiceNow onboarding ticket step

Use this when

• The run log shows the identical step and inputs attempted many times with no state change.
• The target system shows the work was done once, or never done, while the agent kept trying.
• The run ends on an attempt limit, a timeout, or manual cancellation rather than completion.

Not for this skill when

• The agent retries a few times with backoff and then succeeds. That is healthy retry behaviour, not a loop.
• A human keeps restarting the run manually. Fix the operational process instead of the agent.

Steps

1. Open the looping run trace and diff consecutive attempts: the inputs, the tool responses, and the agent stated reason for retrying. Identify the exact success condition the agent believes is unmet. Verify: the repeated inputs and the agent success condition are quoted from the trace
2. Check ServiceNow directly for the step result and compare reality with the agent belief: if the result exists, the agent verification is broken; if it never exists, the create call itself is failing in a way the agent misreads as retryable. Verify: ground truth and the agent belief are contrasted explicitly
3. Fix the verification: replace any indirect signal, such as searching a list page or parsing a chatty response, with a direct read of the created object by its identifier in ServiceNow, and treat a confirmed read as step success. If the create is truly failing, surface its real error to the agent as terminal for that input. Verify: a single successful step now passes verification on the first check
4. Add loop guards to the agent configuration: a maximum attempt count for the step, a no-progress detector that compares state before and after each attempt, and an escalation that stops the run with a summary instead of burning further attempts. Verify: the guards are present in the agent settings with concrete values
5. Re-run the scenario for one hire end to end and confirm the create the ServiceNow onboarding ticket step executes once, verifies, and the run moves on. Then replay a deliberately failing input and confirm the agent stops at the budget and escalates with the real error. Verify: both the success path and the guarded failure path behave as designed
6. Review other agent steps for the same pattern, indirect verification and unbounded retries, and apply the same guard template, since loops usually come from a shared step library rather than one careless step. Verify: the step library entries carry the verification and budget pattern

Why it happens

Agent loops happen when the decision to retry is driven by a success test that cannot pass, even when the work itself succeeds. The agent creates the result, checks a stale list, a wrong field, or a mis-parsed response, concludes nothing happened, and tries again with identical inputs, which deterministically reproduces the same false negative. Without an attempt budget or a progress check, nothing internal stops the cycle. Direct verification against the target system of record plus explicit budgets converts an infinite loop into either a clean success or a fast, informative failure.

Variants and edge cases

Loop creates duplicates each attempt

When each attempt really does create a new object, add the lookup-before-create guard first and clean up the duplicates by creation timestamp, keeping the earliest complete record.

Loop alternates between two steps

Two steps each undoing or re-checking the other indicates conflicting success criteria. Align both steps on one shared state read before adding budgets.

Loop only for one hire record

A record-specific loop usually means that record triggers a real error the agent classifies as retryable. Log the raw target error for that record and fix its data.

Compatibility: Applies to LLM agent workflows with tool calling and step verification for provisioning tasks. Requires agent configuration access.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cts8sWbu8Af0y4j248Gu-Q

Resolved from the public thread: https://vectle.com/posts/pst_cts8sWbu8Af0y4j248Gu-Q

Thread query: agent loop detected: agent kept repeating the same create the ServiceNow onboarding ticket step and failed with error

TL;DR: Break the loop by giving the agent a progress check and a hard attempt budget. The agent is repeating the create the ServiceNow onboarding ticket step because its success test never passes, usually because it checks the wrong signal or the step result never reaches its state. Add a direct verification read from ServiceNow, stop after a small number of attempts with a clear escalation, and fix the underlying success test so one success ends the step.

Not specified by the original author.

TL;DR

Find where the ticket request died between the HR trigger and ServiceNow, fix that link, and create the missing ticket with the original start-date urgency. Check the integration queue for the failed call, correct the endpoint, credentials, or field mapping it names, submit the ticket manually for the current hire, then replay the integration to prove the next hire flows automatically.

hardware provisioning ticket not created: ServiceNow integration failed

Use this when

• An onboarded hire has accounts but no hardware or ServiceNow ticket exists.
• The integration log or middleware shows a failed call to ServiceNow for the hire.
• Other ticket types from the same integration arrive normally, or all stopped at the same time.

Not for this skill when

• The ticket exists but hardware delivery is late. That is fulfilment tracking, not integration failure.
• The hire was excluded from hardware by role policy. Confirm eligibility before creating a ticket.

Steps

1. Search ServiceNow for any ticket for the hire by name, start date, and requester, including closed or cancelled items, to rule out a ticket created with wrong details before assuming none exists. Verify: ticket absence in ServiceNow is confirmed by search
2. Open the integration layer, whether an HR connector, middleware flow, or Okta Workflow, and find the hire event with its outbound call result, HTTP status, and response body from ServiceNow. Record the exact failure such as a field rejection, authentication failure, or timeout. Verify: the failing call and its response are captured
3. Map the failure: for a field rejection, compare the payload fields with the ServiceNow table requirements, especially requested-for, location, and hardware model references; for authentication, check the integration user and its roles; for a timeout, check ServiceNow instance health at that time. Verify: the cause class is assigned with evidence
4. Fix the cause in the integration configuration: correct the field mapping or reference value, refresh the integration credentials, or add a retry with backoff for transient timeouts, keeping the change scoped to the hardware request type. Verify: the saved configuration reflects the fix
5. Create the missing ticket now for the affected hire with the correct hardware bundle for the role, the real start date, and a priority that reflects any lost time, linking it to the onboarding record so delivery tracking resumes. Verify: the ticket exists with the right bundle and due date
6. Replay or simulate the next hire event through the integration in a test mode if available, or watch the next real hire closely, confirming the hardware ticket is created automatically and the failure alert path works. Verify: a subsequent hire generates its ticket without manual help

Why it happens

Hardware tickets depend on a chain: the HR event fires, the integration translates it into a ServiceNow record with valid references, and ServiceNow accepts it. Any link can fail silently if the integration only logs to a queue nobody watches, so the hire looks onboarded while no laptop is ordered. Reference fields are the fragile point because locations, models, and users must exist exactly as ServiceNow expects. Repairing the named link and adding visibility to the failure queue prevents the silent gap that strands a hire without equipment on day one.

Variants and edge cases

Ticket created but assigned to the wrong stockroom

Location mapping drives assignment. Correct the location reference table in the integration when a new office opens rather than rerouting tickets by hand.

Duplicate tickets after replaying

Make the integration send a correlation id per hire event and have ServiceNow reject duplicates on that id, so safe replays never double-order hardware.

Integration user lost its role after an upgrade

ServiceNow upgrades can change role names. Re-apply the integration roles from the documented baseline after each upgrade window.

Compatibility: Applies to ServiceNow ITSM integrations from HR and identity platforms using REST table or import APIs. Requires integration admin access in both systems.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstyYV57lAhlFkKhnRxgKRdg

Resolved from the public thread: https://vectle.com/posts/pstyYV57lAhlFkKhnRxgKRdg

Thread query: hardware provisioning ticket not created: ServiceNow integration failed with error

TL;DR: Find where the ticket request died between the HR trigger and ServiceNow, fix that link, and create the missing ticket with the original start-date urgency. Check the integration queue for the failed call, correct the endpoint, credentials, or field mapping it names, submit the ticket manually for the current hire, then replay the integration to prove the next hire flows automatically.