[object Object]

Process Mining is usually framed as a way to find inefficiencies in valuable processes. The more interesting use is the opposite: finding the flows that have no value, that are costing real platform cycles, and that nobody has noticed are dead. The pruning produces compounding wins — less runtime, less audit surface, fewer upgrade blockers.

What “low value” actually means

A low-value flow is not necessarily a slow flow or a buggy flow. Low value has a more specific meaning:

  • The flow executes regularly
  • Its outcomes do not correlate with downstream business events
  • Removing it produces no measurable degradation in any tracked metric

The first criterion separates “low value” from “rarely used.” A flow that runs twice a year for a regulatory closeout may be high value at those two moments. The second criterion separates “low value” from “expensive but necessary.” A flow that takes 30 seconds but produces a required compliance record is not low value, just expensive.

Process Mining’s job is to surface flows where all three conditions hold.

The process discovery pass

Before pruning, you need to know what flows exist and how often each one runs. Most tenants underestimate their flow inventory by a factor of 3 to 5.

// Background script — flow execution census, last 30 days
var ga = new GlideAggregate('sys_flow_context');
ga.addQuery('sys_created_on', '>=', gs.daysAgoStart(30));
ga.addAggregate('COUNT');
ga.groupBy('flow');
ga.orderByAggregateDesc('COUNT');
ga.setLimit(500);
ga.query();

while (ga.next()) {
    var name = ga.flow.getDisplayValue();
    var n = parseInt(ga.getAggregate('COUNT'));
    gs.info(name + '|' + n);
}

Take the output and sort by execution count. Three buckets emerge naturally:

  • High volume — the top 20 flows, accounting for most of the platform’s flow runtime
  • Medium volume — flows executing dozens to hundreds of times per month
  • Low volume / dead — flows executing fewer than 5 times in 30 days

The pruning targets live in the third bucket. The first two contain flows worth optimizing, not pruning.

The valued-outcome correlation

For each candidate flow, ask: when this flow ran, did any downstream business event happen as a result? The events to check vary by domain:

  • Did an incident close as resolved?
  • Did a change implement successfully?
  • Did a request fulfill?
  • Did a notification get acknowledged?
  • Did a customer’s case advance state?

If a flow runs and no downstream business event is detectable, the flow may be doing nothing of value. The keyword is “may” — there are legitimate cases (audit logging, compliance recording) where the flow’s value is in the act of having run, not in a downstream change.

// For a candidate flow, find context records and check correlation
function correlateOutcome(flowName, windowDays) {
    var ctx = new GlideRecord('sys_flow_context');
    ctx.addQuery('flow.name', flowName);
    ctx.addQuery('sys_created_on', '>=', gs.daysAgoStart(windowDays));
    ctx.query();

    var runs = 0, withOutcome = 0;
    while (ctx.next()) {
        runs++;
        var subject = ctx.source_record;
        if (!subject) continue;
        var subjTable = ctx.source_table.toString();
        if (subjTable === 'incident') {
            var inc = new GlideRecord('incident');
            if (inc.get(subject) && inc.state == 6) withOutcome++;
        }
        // ... other table cases
    }
    return { runs: runs, withOutcome: withOutcome, rate: runs ? withOutcome / runs : 0 };
}

A correlation rate near zero is a strong pruning signal. A correlation rate near one means the flow is doing what it claims. The interesting middle ground is rates around 0.2 to 0.5 — flows that sometimes correlate with outcomes and sometimes do not. These need closer inspection before pruning.

The shadow-disable protocol

Never delete a flow as your first action. The protocol:

  1. Identify — candidate from the census.
  2. Investigate — find the owner, find the use case, find the business rule or trigger that fires it.
  3. Shadow-disable — turn off the trigger but leave the flow active. Capture invocations that would have happened in a log table.
  4. Wait — at least one full business cycle (30 days for monthly cycles, 90 for quarterly).
  5. Confirm — verify no complaints, no escalations, no business event correlated with the absence.
  6. Retire — deprecate the flow, then delete after a further grace period.

The shadow-disable step is the discipline. Many flows that look dead in the census were doing something subtle that only becomes visible when they stop.

A would-have-fired log

// Pattern for the shadow disable
(function shadowDisable(current) {
    var log = new GlideRecord('u_flow_shadow_disabled_log');
    log.initialize();
    log.u_flow_name = 'OldFulfillmentNotifier';
    log.u_record_table = current.getTableName();
    log.u_record_sys_id = current.sys_id;
    log.u_trigger_context = JSON.stringify({
        state: current.state.toString(),
        priority: current.priority.toString(),
        assignment: current.assignment_group.toString()
    });
    log.insert();
    // Do not invoke the flow
})(current);

The log captures what would have run but did not. Weekly review of the log answers: “Is anyone, anywhere, asking about cases that should have triggered this flow?” If not, the case for retirement gets stronger.

Ownership archaeology

The hardest part of pruning is finding owners. Flows accumulate over years; their authors leave the company; the business sponsor reorgs into a different group; the use case has long been overtaken by a different flow elsewhere.

The hunting order:

  1. Check the flow’s sys_created_by and sys_updated_by fields.
  2. Check the trigger source — what catalog item, business rule, or scheduled job invokes the flow?
  3. Check the related artifacts — what tables does the flow read or write, and who owns those tables?
  4. Check the change calendar — was this flow shipped with a known initiative?
  5. Ask the platform-ops Slack channel. Forward results.

If you cannot find an owner after this hunt, the flow is by definition an orphan, and orphans are the highest-confidence pruning candidates. An owned flow whose owner says “yes, keep it” stays; an orphan whose only defender is “nobody told us to delete it” goes.

The hard cases: flows that fire constantly but produce nothing visible

Some flows have correlation rates near zero not because they do nothing but because they do something invisible — they write to an external system, they update a CMDB attribute that is not user-facing, they emit a webhook to a partner. These look like prune candidates in the census but are not.

The discipline: before pruning a high-volume zero-correlation flow, trace its outputs. What does the last step do? If the last step writes to a partner system, the value is on the partner side, not visible from the platform.

This is where flow documentation pays back. A one-paragraph description of “what this flow exists to accomplish” in the flow’s description field is worth hours of investigation later.

For the related discipline of process mining on whole task chains, see our piece on Process and Task Mining in the 2026 release line.

The audit benefit

Pruned flows reduce more than runtime. Every active flow is a thing the audit team has to certify, a thing the upgrade has to skip-check, a thing that has to be reviewed when the table schema changes. A 20 percent reduction in active flows produces a roughly 20 percent reduction in audit and upgrade overhead. The benefit is real but invisible until the next upgrade or audit, which is why pruning often gets deprioritized.

UI for the pruning queue

Build a saved list of pruning candidates: flow name, last execution, 30-day execution count, owner, correlation rate, shadow-disable status, target retirement date. Sort by 30-day execution count descending so the highest-volume orphans appear first. Pin the list to the platform ops dashboard.

Review the list at the same cadence as the CMDB cleanup queue — monthly works. Make pruning a routine, not a special project.

Adjacent pruning targets

Once the flow pruning rhythm is established, the same pattern works on adjacent platform constructs:

  • Business Rules — most tenants have BRs that fire on every record save and produce no observable effect. The same census-correlate-shadow-retire pattern applies.
  • Scheduled Jobs — long-tail scheduled jobs that nobody knows the purpose of. Look at their last_run and outcome history.
  • Notifications — emails sent to distribution lists that auto-archive without reading. Check open rates.
  • Inbound action handlers — email inbound action processors for mailboxes nobody monitors anymore.

Each pruning target has its own subtleties, but the discipline transfers. Build the muscle on flows first; extend it once the team is comfortable with the shadow-disable rhythm.

What to measure

If pruning is going to compete for engineering time against feature work, it needs a credit-able metric. Three that work:

  • Active flow count, tracked month over month. A descending line is a credit.
  • Total flow runtime per day, summed across all active flows. Process Mining can produce this directly.
  • Skipped-record count in the next upgrade. The most lagging indicator, but the most convincing one when the upgrade comes around.

Without a credit-able metric, pruning is a quiet act of platform hygiene that does not get noticed until something breaks. Make the work visible.

Tradeoffs to be honest about

Aggressive pruning has a tail risk: the once-a-year regulatory flow that nobody saw in the 30-day census. Mitigate by extending the observation window to one full fiscal year before pruning anything compliance-adjacent. The cost of waiting is small; the cost of pruning the wrong flow can be very large.

Also be honest about effort. Pruning is unglamorous, hard to credit, and easy to defer. The teams that do it well treat it as an explicit allocation — one engineer-week per quarter — rather than a “we will get to it” item.

Key takeaways

  • Low value means three things at once: runs regularly, no outcome correlation, no measurable degradation when removed.
  • Census first, prune later. Most tenants underestimate their flow inventory by 3 to 5x.
  • Shadow-disable before deleting. Capture would-have-fired events in a log; review for at least one business cycle.
  • Orphans are the highest-confidence prune targets. Hunt for owners systematically; document the hunt.
  • The benefit of pruning shows up at upgrade and audit time, not on a daily dashboard. Plan and credit it accordingly.
[object Object]
Share