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 report mail’s subject and body (Step 7) bind these values, and mail fields are plain strings: they bind {{…}} tokens but never evaluate a body path.

Three external parties, three 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 reporting procedure in the sales database; the aggregate port (Step 6) calls it. One aggregate row for the previous day. The SELECT ends in FOR JSON PATH, WITHOUT_ARRAY_WRAPPER so the single row comes back as one JSON object, not an array; that JSON is what the map in Step 4 consumes.

CREATE OR ALTER PROCEDURE dbo.DailySalesSummary
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @day DATE = CAST(DATEADD(DAY, -1, SYSUTCDATETIME()) AS DATE);

    SELECT
        CONVERT(CHAR(10), @day, 23)                       AS ReportDate,
        CAST(ISNULL(SUM(OrderTotal), 0) AS DECIMAL(18,2))  AS Revenue,
        COUNT(*)                                           AS OrderCount
    FROM dbo.Orders
    WHERE CAST(ReceivedAt AS DATE) = @day
    FOR JSON PATH, WITHOUT_ARRAY_WRAPPER;
END;

Under the application’s Maps, create the map the aggregate port’s inbound flow (Step 6) will select:

Because the procedure’s SELECT ends in FOR JSON PATH, WITHOUT_ARRAY_WRAPPER, the single row comes back as one JSON object:

{ "ReportDate": "2026-06-04", "Revenue": 48230.00, "OrderCount": 312 }

and becomes the <Summary> document whose paths the Step 1 promotions read:

<Summary>
  <ReportDate>2026-06-04</ReportDate>
  <Revenue>48230.00</Revenue>
  <OrderCount>312</OrderCount>
</Summary>

Maps are authored in XSLT 3.0 and run on Saxon HE 12.9. JSON in, XML out: parse-json(.) turns the result text into a map, and the ?key operator reads each field:

<xsl:stylesheet version="3.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" indent="yes"/>
  <xsl:template match="/">
    <xsl:variable name="r" select="parse-json(.)"/>
    <Summary>
      <ReportDate><xsl:value-of select="$r?ReportDate"/></ReportDate>
      <Revenue><xsl:value-of select="$r?Revenue"/></Revenue>
      <OrderCount><xsl:value-of select="$r?OrderCount"/></OrderCount>
    </Summary>
  </xsl:template>
</xsl:stylesheet>

Create a receive port MorningReportClock on the Scheduler: Repeat Every 1, Repeat Unit Days, Time Zone yours, Daily Window on with Daily Start Window 06:00:00 AM. Empty Payload.

Create a send port SalesAggregate on the SQL Caller, subscribing on {{Config.PortName}} == "MorningReportClock", the clock from Step 5. Everything it references already exists, so each field is a pure selection. (The dropdowns can also create types and maps inline; building the dependencies first keeps each dialog a selection.)

The procedure takes no parameters, so Input Parameters stays empty.

In the port’s inbound flow, select ResultToDailySummary, from Step 4, so the result row is published as DailySalesSummary.

Create an O365 Mail send port ReportMail subscribing on {{Message.MessageType}} == "DailySalesSummary":

Subject and Body are templated against the promotions from Step 1:

Sales report, {{Promoted.DailySalesSummary.ReportDate}}, {{Promoted.DailySalesSummary.Revenue}}

The Body is plain HTML carrying the same tokens, a modest table of the summary fields reads better in a morning inbox than a payload dump:

<h3>Daily sales report, {{Promoted.DailySalesSummary.ReportDate}}</h3>
<table>
  <tr><td>Revenue (EUR)</td><td>{{Promoted.DailySalesSummary.Revenue}}</td></tr>
  <tr><td>Orders</td><td>{{Promoted.DailySalesSummary.OrderCount}}</td></tr>
</table>

On both send ports, SalesAggregate and ReportMail, set Exception Message Type to SalesReportFailed, from Step 1, so a failed run re-publishes under that type, payload intact.

Create a second O365 Mail port OpsAlert, different recipients and a different sending mailbox than the report itself, subscribing on {{Message.MessageType}} == "SalesReportFailed":

Everything you configure is live the moment you save it, there is nothing to deploy. Start the send ports first, SalesAggregate, ReportMail, and OpsAlert, then the receive port MorningReportClock.

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.

To test without waiting for the 06:00 window, temporarily set MorningReportClock to repeat every 1 Minutes, check the email arrives formatted, then restore the schedule. Verify the run in tracking.

Break the query once, rename the procedure, and confirm operations gets SalesReportFailed at tick time; replaying the run should simply re-send the morning report.