Import media attachments into IFS Cloud

Explore this learning path

Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.

Upload one media file to an IFS business record, identify the supported upload contract, and automate only after you can reproduce the same result under the integration identity. Media metadata, file bytes, and the record connection may be separate operations; treating them as one guessed POST often leaves incomplete attachments.

Before you start

Choose a development business object with Media Library enabled, two fictional records, and one small PNG you own. Use a business user who can attach media and an integration identity with the intended API grants. Record the target business key and file size/type.

This procedure uses the installed web client’s actual supported operation as its starting point. Media Library and Document Management are different attachment mechanisms; identify which one your page uses before automating it.

1. Prove the manual upload

Open record A and its Media attachment area. Use Upload Media Item or Manage Media as offered by the page. Upload the lab PNG, give it a distinctive description, and save. Reopen the record and verify the image is visible.

Open record B and confirm the image is not connected there. This establishes the correct record scope before you examine API traffic.

2. Capture the upload sequence

Repeat with a second lab filename while browser Developer Tools → Network → Fetch/XHR is recording. Use request tracing to find the requests.

Record, in order:

Stage	Evidence to capture
Create media metadata	Method, projection/action, request fields, returned media key
Transfer bytes	Upload URL, content type, binary/multipart body format, concurrency headers
Connect to business object	Logical unit/key-reference values and supported connection operation
Confirm content	Read/preview request and returned media identifier

Some implementations combine stages. Preserve the observed order rather than imposing this table as four mandatory calls. A temporary upload URL may be valid only for one item/session; do not hardcode it as a permanent endpoint.

3. Confirm the contract in API Explorer

Locate each captured projection/operation in API Explorer. Check its integration suitability, parameter types, and stream handling. Resolve a business key to the correct object connection through the documented API. Do not concatenate a key-reference string without confirming its full key fields and escaping rules.

If only a UI-internal operation is available, have the development owner expose an approved integration service. The browser capture reveals behavior, but it does not grant supportability or bypass API permissions.

4. Reproduce one upload in Postman

1. Create a private collection with the verified requests in their observed order.
2. Replace browser cookies/tokens with a token for the integration identity.
3. Run the metadata/create request and copy its returned media identifier into a local collection variable.
4. In the bytes request, select Body → binary if the contract accepts a raw stream, and select the PNG. Use multipart form-data only if the contract specifies it.
5. Set the exact content type and required ETag/concurrency headers.
6. Run the supported connection operation with record A’s verified key.
7. Reopen record A in IFS and inspect the image and metadata.

Expected result: one new media item, correct bytes and filename, and one intended business connection. A metadata row without viewable bytes is not success.

5. Add an import manifest before batching

Create a manifest outside IFS with these columns:

source_id,target_reference,file_name,sha256,media_id,status
LAB-MEDIA-01,LAB-RECORD-A,pump-front.png,COMPUTE_FROM_FILE,,Pending

On Windows, calculate the hash with Get-FileHash -Algorithm SHA256 ./pump-front.png. After each verified upload, save the returned media ID and outcome. On restart, reconcile that ID before creating another item. A matching filename alone does not prove content identity.

Use sequential uploads initially. If the bytes transfer fails after metadata creation, retry the permitted stage or remove the orphan through its supported API; do not create another record on every retry.

6. Validate failures and retire the lab

Test a missing business record, denied attachment permission, unsupported MIME type, duplicate source ID, and interrupted upload. Inspect both the business connection and the media library for orphaned items.

Remove lab connections and media through the normal UI/API, considering whether an item is shared with another record. Do not delete storage BLOBs directly. Preserve a sanitized request manifest and the exact installed release/operation contract for the production implementation.

For a documented business-page example, see Part Media Combination upload actions.

Sources and scope

• IFS integration decision guide
• IFS Connect architecture

Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.