Write data and handle validation errors

26R1 reference · Documentation-based tutorial draft · Not executed in IFS

Integration learning center

Try the flow interactively

Open the Example flow menu and choose “Create or update a record,” then try a valid update, a validation error, and a stale ETag in turn.

BROWSER SIMULATION · FICTIONAL DATA · NO IFS CONNECTION

A fictional client-credentials token request. Try valid credentials, a wrong secret, or a scope the client was never granted.

Next stepRun to endReset flow

Ready. Choose Next step or Run to end.

Click a node to inspect it. Highlighted arrows show the path taken; the dashed outline marks the current step. On small screens, scroll the diagram sideways.

Start

The external system holds a client ID and secret issued for a dedicated integration user. This teaching flow makes no live network call.

Read the walkthrough

Variables at the current step

No steps executed yet.

Execution trace

1. No steps executed yet.

These fictional flows illustrate a common shape. Confirm the exact endpoints, grant types, and error codes for your environment before building against them.

Outcome and prerequisites

Send a create or update request to a projection API, interpret its success and error responses correctly, and use ETags to avoid silently overwriting a concurrent change. You need a discovered API contract (see API discovery) and a working access token (see authentication and access).

The concept

Writing data through a projection API is not just “the same request as reading, but with a body.” Three ideas matter specifically for writes:

• Required versus optional fields. The contract, not a guess from the page layout, determines what a create or update actually needs. Confirm this during discovery rather than during the first failed request.
• Business actions versus plain CRUD. Some state changes are not a field update at all — they are a defined operation (for example, an approval or a status transition) that carries its own rules. Calling an action is a different request shape than updating a field, and skipping the action to “just set the field” can bypass validation the business relies on.
• Concurrency, via ETags. An update should send the ETag it read earlier. If the record changed since then, the service can reject the update instead of silently overwriting someone else’s change. A caller that ignores ETags is choosing to risk lost updates.

A worked scenario

An external system read a handover record, along with its ETag, an hour ago. It now wants to update the handover’s external reference. If nothing else changed the record in the meantime, sending the update with that ETag succeeds and returns a new ETag. If a coordinator updated the same record five minutes ago, the ETag no longer matches, and the update is rejected as a conflict rather than silently overwriting the coordinator’s change. The external system must then refetch the current record before deciding what, if anything, to resubmit.

Work through it

1. Confirm which fields are required, optional, and read-only for the target operation — do not assume every field in a read response is writable.
2. Decide whether the change is a plain field update or a defined business action, and use the shape the contract expects.
3. For updates, always send the ETag read with the record; never fabricate or reuse a stale one on purpose.
4. On success, store the new ETag returned in the response before making any further update.
5. On rejection, read the error carefully: a validation error names the failing field and needs a data fix; a conflict needs a refetch and reconciliation, not a blind retry.

Try it yourself

An update request fails, and the error response identifies a specific field as violating a business rule. A second, unrelated update to the same record fails with a conflict a moment later. Describe the correct next action for each.

See a suggested answer

The validation failure needs a corrected value for the named field before resubmitting; retrying the same payload unchanged will fail again. The conflict needs the caller to refetch the current record and its new ETag, reconcile whether the original change still makes sense, and only then resubmit with the fresh ETag. Neither failure should trigger an automatic unconditional retry. This connects directly to reliability and security: a correlation identifier makes it possible to tell these two failures apart in a log during a later investigation.

Check your understanding

Treating every write failure as retryable, or treating an ETag mismatch as a bug to work around rather than the concurrency control doing its job. Also common: bypassing a business action by trying to set its target field directly, which can skip validation the action was written to enforce.

Expected result: a written decision for each failure type, and an explanation of why the ETag mismatch is expected behavior rather than an error to suppress.

Cleanup: none; this exercise changes no IFS data.

Sources and review status

IFS Cloud technical documentation, integration. Source consulted 2026-09-23. The scenario and exercise are original fictional examples. This concept draft has not been reviewed by an IFS specialist or executed in an IFS environment. Continue with reliability and security for retry and duplicate-handling design.