Long-Running Bulk Job Alert Monitor

Overview

This scheduled cloud flow polls Salesforce for bulk data load jobs that have been stuck in a running state for longer than a configurable threshold. When stale jobs are found, it posts a formatted HTML table to a Microsoft Teams channel and sends a parallel email alert to the IT distribution list so someone can investigate and cancel the job before it burns API hours.

Built as part of the FlowLibs demo library to showcase: (1) periodic polling with time-window filtering, (2) Data Operations Filter Array + length() based conditional branching, (3) fan-out alerting to Teams and Outlook in parallel, and (4) fully env-var driven configuration with zero hardcoded identifiers.

Use Case

Salesforce bulk API v2 ingest jobs can silently hang when upstream data sources are slow or malformed. An analyst kicking off a nightly 2-million-record upsert expects it to finish in ~40 minutes; if it is still InProgress after 4 hours, something is wrong. Rather than having ops staff manually tail the Bulk Data Load Jobs screen, this flow watches the queue on a 2-hour cadence and raises an alert the moment a job crosses its defined age threshold. IT receives both a Teams post (for visibility during working hours) and an email (for after-hours paging) containing the job Id, operation type, object, age, and a direct link to the job record.

Flow Architecture

Environment Variables

Connectors & Connections

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Change the polling cadence

Edit the Recurrence trigger interval/frequency. For sub-hour polling be aware of Salesforce daily API limits.

Watch a different Salesforce state

Change the default of flowlibs_SalesforceMonitoredJobState in your environment. Valid values include Open, UploadComplete, InProgress, Aborted, JobComplete, Failed.

Change the threshold

Edit env var flowlibs_SalesforceJobRunningThresholdHours. The value is parsed as an integer and multiplied by -1 inside the cutoff expression, so positive whole numbers only.

Add a cancellation step

In the If-Yes branch, insert an Apply_to_each over body('Filter_Long_Running_Jobs') and call the Salesforce PatchJobState action with state: Aborted. This turns the flow from passive alert into active remediation — consider adding an approval before the cancel for safety.

Route alerts elsewhere

Replace the Teams post with a Slack PostMessage, or swap Outlook for Gmail. The HTML body will render in any modern mail/chat client.

Suppress duplicate alerts

Add a Dataverse table flowlibs_AlertedJob keyed on job Id and gate the alert branch on get row / add row to ensure each job only pages once per escalation window.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

addHours(utcNow(), mul(variables('varThresholdHours'), -1))

and(equals(item()?['state'], variables('varMonitoredState')), less(item()?['systemModstamp'], variables('varCutoffTimestamp')))

greater(length(body('Filter_Long_Running_Jobs')), 0)

<tr><td>@{item()?['id']}</td><td>@{item()?['operation']}</td><td>@{item()?['object']}</td><td>@{item()?['state']}</td><td>@{item()?['createdDate']}</td><td>@{item()?['systemModstamp']}</td></tr>

<table border="1">...<tbody>@{replace(replace(replace(string(body('Build_Job_Rows_Select')), '[{"html":"', ''), '"}]', ''), '"},{"html":"', '')}</tbody></table>