Under the application’s Message types, create the two types this flow routes on. A message type is a name plus a format, no schema required:

Promotions live on the message type, so add them while you are here. The looping port’s header parameter (Step 7) and the alert subject (Step 9) bind these values, and adapter parameters are plain strings: they bind {{…}} tokens but never evaluate a body path.

A failed invoice re-publishes payload intact, but promotions are type-qualified, so the exception type needs its own:

Three lines, the document the Step 10 test posts:

{
  "invoiceNumber": "PI-88421",
  "supplier": "NordicGear",
  "currency": "EUR",
  "postingDate": "2026-06-05",
  "lines": [
    { "lineNumber": 1, "glCode": "5010", "description": "Trail Pack 45L x40", "amount": 2448.00 },
    { "lineNumber": 2, "glCode": "5010", "description": "Hex Stove x60",      "amount": 1125.00 },
    { "lineNumber": 3, "glCode": "6420", "description": "Inbound freight",    "amount": 180.00 }
  ]
}

Two external systems, two credentials. Under the application’s Authentications, the dialog asks for a Name, the Adapter it pairs with, and a Definition, the credential shape that adapter offers, with the Application preset; the Definition decides the config section that follows.

Create the ledger and the posting procedure; the looping port (Step 7) calls it once per pass. The primary key on (invoice, line) makes posting idempotent; an unknown GL code THROWs, the per-line failure that stops the loop and raises LinePostFailed (Step 9). The final SELECT echoes the whole invoice JSON back and ends in FOR JSON PATH, WITHOUT_ARRAY_WRAPPER, so the result is one JSON object carrying that string; the response map (Step 5) lifts it back out.

CREATE TABLE dbo.GlAccount ( GlCode VARCHAR(10) NOT NULL PRIMARY KEY );

CREATE TABLE dbo.Ledger (
    InvoiceNumber VARCHAR(40)   NOT NULL,
    LineNumber    INT           NOT NULL,
    GlCode        VARCHAR(10)   NOT NULL,
    Amount        DECIMAL(18,2) NOT NULL,
    PostedAt      DATETIME2     NOT NULL CONSTRAINT DF_Ledger DEFAULT SYSUTCDATETIME(),
    CONSTRAINT PK_Ledger PRIMARY KEY (InvoiceNumber, LineNumber)
);

CREATE OR ALTER PROCEDURE dbo.PostInvoiceLine
    @InvoiceNumber VARCHAR(40),
    @LineNumber    INT,
    @GlCode        VARCHAR(10),
    @Amount        DECIMAL(18,2),
    @InvoiceJson   NVARCHAR(MAX)
AS
BEGIN
    SET NOCOUNT ON;
    IF NOT EXISTS (SELECT 1 FROM dbo.GlAccount WHERE GlCode = @GlCode)
        THROW 50010, 'Unknown GL code', 1;
    MERGE dbo.Ledger AS tgt
    USING (SELECT @InvoiceNumber AS InvoiceNumber, @LineNumber AS LineNumber) AS src
        ON tgt.InvoiceNumber = src.InvoiceNumber AND tgt.LineNumber = src.LineNumber
    WHEN NOT MATCHED THEN
        INSERT (InvoiceNumber, LineNumber, GlCode, Amount)
        VALUES (@InvoiceNumber, @LineNumber, @GlCode, @Amount);
    SELECT @InvoiceJson AS InvoiceJson
    FOR JSON PATH, WITHOUT_ARRAY_WRAPPER;
END;

Under the application’s pipeline components, create CountLines; the receive port (Step 6) references it in its inbound pipeline. JPath cannot count an array (Newtonsoft.Json has no length function), and components are the write surface for Variables, so the component counts the lines once and writes both the countdown counter and the forward-indexing total:

using CC.Art2link.Pipelines.Domain.Models.PipelineComponents;
using Newtonsoft.Json.Linq;

public sealed class CountLinesConfig { }

public sealed class CountLines : PipelineComponentBase<CountLinesConfig>
{
    public override string Name => "CountLines";

    protected override Task<PipelineComponentOutput> ExecuteAsync(
        PipelineComponentInput input,
        CountLinesConfig config,
        CancellationToken cancellationToken)
    {
        var count = (JObject.Parse(input.Body)["lines"] as JArray)?.Count ?? 0;
        return Task.FromResult(new PipelineComponentOutput
        {
            Success  = true,
            Messages = [new PipelineMessage { Body = input.Body }],
            Variables = { ["iLines"] = count.ToString(), ["Total"] = count.ToString() }
        });
    }
}

Under the application’s Maps, create the map the looping port (Step 7) selects on its response side. The posting procedure’s final SELECT echoes the invoice JSON back as a column; this map lifts it out of the SqlCallerResult result so the original body republishes.

The procedure echoes the invoice back in one column and ends in FOR JSON PATH, WITHOUT_ARRAY_WRAPPER, so the result is one JSON object whose InvoiceJson field carries the original invoice as a string:

{ "InvoiceJson": "{\"invoiceNumber\":\"PI-88421\", ... }" }

Maps are authored in XSLT 3.0 and run on Saxon HE 12.9. JSON in, the original body out: parse-json(.) reads the result and ?InvoiceJson returns the echoed invoice string unchanged:

<xsl:stylesheet version="3.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="text"/>
  <xsl:template match="/">
    <xsl:value-of select="parse-json(.)?InvoiceJson"/>
  </xsl:template>
</xsl:stylesheet>

Create a receive port InvoiceIntake on the API Listener, one-way, classifying as ApprovedInvoice, from Step 1. (The dropdowns can also create types and maps inline; building the dependencies first keeps each dialog a selection.)

In the port’s inbound pipeline, reference CountLines, from Step 4.

Create a send port PostLine on the SQL Caller, two-way, because the republish that drives the loop is the response: a two-way port publishes back what the SQL call returned. It subscribes on the type while the counter is still above zero:

{{Message.MessageType}} == "ApprovedInvoice" && {{Variable.iLines}} > 0

In Open Variables the port computes the forward index first, then captures the line’s three values by that index. Both reads belong in the assignments: the JSONPath engine does no arithmetic, so idx must resolve to a literal first, and the parameters below bind the captured variables. Add one assignment per row (select the variable, then enter the expression):

Add the Input Parameters (key/value), one row per parameter; the header’s invoice number binds the Promotion from Step 1:

In Close Variables, decrement the counter:

On the response side, select the map from Step 5 as a Universal assignment and set Publish Message Type Fallback to ApprovedInvoice: the republished message is the same invoice under the same type with the counter one lower, so it matches the subscription again until the counter reaches zero.

Create a null port subscribing on {{Message.MessageType}} == "ApprovedInvoice" && {{Variable.iLines}} == 0 so the finished invoice has a subscriber and does not dead-letter on its last lap.

On PostLine, set Exception Message Type, on the port’s General step, to LinePostFailed, from Step 1.

Create the OpsAlert O365 Mail port for finance subscribing on {{Message.MessageType}} == "LinePostFailed":

Everything you configure is live the moment you save it, there is nothing to deploy. Start the send ports first, then the receive ports.

Set Tracking to Enabled + Body on every port the flow touches, so you can walk each run step by step, with its message body, in tracking.

Post a test invoice with three lines, and watch tracking: three passes through PostLine, counter walking 3 → 0, three ledger rows, the null port absorbing the final pass.

Post an invoice with a bad GL code on line 2 and confirm the loop stops there, finance gets the alert, and replay after the fix resumes without double-posting line 1. Remember the constraint: one ApprovedInvoice loop in flight at a time.