Import files into IFS Cloud with Power Automate and OneDrive

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.

Create a recoverable flow that takes a small JSON file from OneDrive for Business and submits it to an approved IFS inbound integration. The file moves to an archive only after the receiving system confirms acceptance.

Before you start

Prepare three OneDrive folders: /IFS-Lab/Incoming, /IFS-Lab/Archive, and /IFS-Lab/Quarantine. Use a service connection with access only to the required folders and a Power Automate license supporting the HTTP action you select.

An IFS administrator must provide a working inbound endpoint, authentication configuration, routing rule, and accepted message schema. This walkthrough uses the SOAP Gateway’s documented JSON input capability. It does not assume every JSON object automatically maps to an IFS business operation. Prove routing with a single manual request first using SOAP Gateway testing.

1. Prepare a traceable input

Save this fictional file as LAB-FILE-017.json:

{
  "messageId": "LAB-FILE-017",
  "equipmentReference": "LAB-PUMP-04",
  "reading": 18.5,
  "unit": "C"
}

Use this schema only if your configured receiver accepts it; otherwise substitute the receiver’s documented sample. Keep messageId stable when retrying the same business message. Add a new ID only for a genuinely new reading.

2. Create the trigger and read the file

1. Create an Automated cloud flow.
2. Select OneDrive for Business → When a file is created (properties only) and choose /IFS-Lab/Incoming.
3. Set trigger concurrency to one while proving the flow.
4. Add Get file content, using the trigger’s file identifier.
5. Add Parse JSON, using the file-content output as its content and generating a schema from the agreed sample.
6. Add a Condition requiring a nonempty messageId. Send failed validation to the quarantine path without calling IFS.

If Parse JSON receives a binary wrapper instead of text, inspect the actual run output and select/decode the content value offered by that action. Do not blindly apply base64 conversion to already decoded JSON.

3. Configure the outbound request

Add a Scope named Submit_to_IFS. Inside it, add the approved HTTP action:

Setting	Value
Method	POST
URI	Administrator-confirmed inbound gateway URL
Content-Type	application/json
Body	Parsed and validated message
Authentication	Approved IFS service identity/token configuration

Use authentication for token acquisition. Protect token and secret action inputs/outputs with the flow’s secure-input/output settings and restrict access to run history. Do not paste a temporary browser token into a permanent flow.

For the initial test, disable automatic retry on the write action. Enable bounded retries only after the receiver demonstrably deduplicates messageId or provides a reliable status lookup.

4. Separate acceptance from business completion

After the HTTP call, inspect the actual status and response contract. A 202 or a queued application message proves acceptance, not completion of the IFS business operation. Save the response’s message/reference identifier in a run log with the OneDrive file ID and messageId.

If the contract requires polling, use a bounded Do until loop with a Delay and the documented status endpoint. Stop on success, known rejection, or timeout. Never keep a flow polling indefinitely.

5. Add archive and failure branches

1. Add Move or rename a file after confirmed success, targeting Archive and preserving a unique filename.
2. Add a failure Scope configured with Run after for failure/timeout of submission.
3. In that scope, record the run ID and failure category, then move the file to Quarantine.
4. For an ambiguous timeout, mark the item Needs reconciliation; check IFS before replaying it.

An archive-move failure after a successful IFS call must not trigger an automatic business resubmission. Repair the file movement using the stored acceptance reference.

6. Run the acceptance cases

Drop one valid file and confirm one IFS result and one archived file. Then test malformed JSON, an invalid business key, an expired credential, and the same message twice. The duplicate must produce no second business result. Check the administrator’s Application Messages record for queued integrations.

Use the acceptance matrix to record actual outcomes. Turn the flow off before deleting lab files or retiring its credential. A successful flow run alone does not prove the IFS record was created.

Sources and scope

• Microsoft OneDrive connector
• IFS integration decision guide
• IFS SOAP Gateway

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