Introducing Sourcing Auditability for Responsive Sourcing
Release
Author:
Kirill Gaiduk
Changed on:
7 Sept 2026
| Target release date: | 2026-09-07 |
|---|---|
| Release status: | Released |
Description
Sourcing Auditability brings full transparency to Responsive Sourcing. You can now see why each sourcing decision was made for any Order or Fulfillment Choice, directly in the Fluent OMS Web App.Every time Responsive Sourcing runs, it captures an immutable record of the decision. From the new Sourcing tab you can review:- Which Sourcing Strategies were evaluated or skipped, and which Conditions passed or failed
- Which Locations were considered and how each one scored against every Criterion
- Which Location was selected and why, and what each Location could not fulfill
- The selected Location side by side with any other candidate
- Operations: investigate complaints and unexpected sourcing outcomes faster
- Product: validate the impact of Strategy, Conditions, and Criteria changes
- Customer service: explain delivery behavior with confidence
- Data and analytics: keep a historical record of sourcing decisions for downstream analysis
- Engineering: trace decision flows when debugging sourcing behavior
Changelog
Initial release of Sourcing Auditability across the platform and the Fluent OMS Web App.Sourcing Auditability GraphQL API- New GraphQL API for Sourcing Audits: the
`createSourcingAudit`mutation records a completed Sourcing Request, and the`sourcingAudits`query reads audits back - Audits are keyed by entity - the supported
`entityType`values are`ORDER`and`FULFILMENT_CHOICE`, and each audit carries an`entityRef`for a human-readable reference. Querying by`ORDER`aggregates the audits across all of the Order's Fulfillment Choices - An audit captures the full decision: the evaluated Strategies and their status, Condition results, the Locations considered and how they scored against each Criterion, the resulting Fulfillments, and the overall outcome (
`FULLY_SOURCED`,`PARTIALLY_SOURCED`, or`NOT_SOURCED`) - Per-Location detail is retained for the successful Strategy, up to 100 Locations
- New
`SOURCINGAUDIT_VIEW`and`SOURCINGAUDIT_CREATE`permissions gate reads and writes. The Sourcing Profile is included on an audit only when the caller also holds`SOURCINGPROFILE_VIEW`
- New Sourcing tab in the standard and Mixed Basket reference manifests, driven by
`sourcingAudits`for the current Order and shown only to users with the required permissions - A Sourcing Requests list with per-request Entity Type, Entity Ref, Requested At, Strategy Type, Sourcing Profile, Active Strategy, Items, Fulfillments Allocated, and Status, plus summary tiles for Items, Locations Considered, Strategies Skipped, and Strategies Evaluated
- A new Sourcing Result Enricher Component (
`fc.sourcing.result.enricher`) that resolves Strategy names, Condition and Criterion descriptions, and expands the audit's positional quantity arrays into full item detail. Strategies defined in the Profile but absent from the audit are shown as`NOT_CONSIDERED` - A new Location Comparison Component that shows the selected Location side by side with any other candidate, including each Location's Criterion scores and any items it could not fulfill
- New Data Injector (
`fc.data.injector`), Page Grid (`fc.page.grid`), and Styled Text (`fc.styled.text`) Components - New
`arrayFindField`and`arrayCountWhere`template helpers - The Accordion Component gains
`summaryRight`and`detailsElevation`options, and new compliance background theme tokens support outcome badges
Screenshot
Limitations
- Grant
`SOURCINGAUDIT_CREATE`to the role that runs sourcing so it can write audits, and`SOURCINGAUDIT_VIEW`to any role that reads them back - Order Reference Module v2.3.0+ is mandatory for sourcing audit generation
- Per-Location detail is retained for the successful Strategy, up to 100 Locations
- The complexity weighting of 400 is used for the Sourcing Audits query (i.e., about 25 sourcing audits per page limit)
| Released capability depth: | New capability |
|---|---|
| Release bundle / Capability type: | Platform, Fluent OMS |
Use case
Problem
As sourcing logic becomes more sophisticated, the reasons behind each decision become harder to see. The Responsive Sourcing Framework evaluates sourcing profiles, strategies, conditions, and criteria against real-time inventory to select a fulfillment location. Once multiple profiles, seasonal strategies, and custom criteria are in play, the outcome of that evaluation is visible but the path to it is not.Without a record of what was evaluated and how each location scored, businesses commonly experience:- Unexplainable outcomes: An order ships from a distant location while a closer one appears to hold stock, and no one can say which criterion drove the decision or whether inventory was the constraint.
- Slow issue resolution: Operations and customer service teams reconstruct decisions from application logs, or escalate to engineering, extending the time to resolve a single customer complaint from minutes to days.
- Validating changes: A strategy, condition, or criterion is adjusted with no reliable way to confirm how the change affected real fulfillments, so tuning becomes guesswork and teams hesitate to make improvements.
- Governance and compliance exposure: Enterprise governance frameworks require that automated decisions affecting cost, service levels, and labor allocation can be evidenced after the fact.
- No basis for optimization: Without historical decision data, analysts cannot identify which criteria configurations produce the best outcomes, or feed those findings back into new sourcing criteria.
Example
A specialty outdoor retailer operating a distribution center in Reno, Nevada and 40 stores across the western United States received a customer complaint about a three-day delivery on an order placed in Denver, Colorado. The retailer's own store in Boulder held the item, and the customer expected same-day dispatch from there. The order was instead sourced from Reno.The operations manager could see the fulfillment record and the selected location, but nothing that explained the choice. The Boulder store's availability at the time of the decision was unknown, and the retailer had recently activated a second sourcing strategy for high-value orders, so it was unclear which strategy had even run. The investigation moved through three teams over four days, ending in an assumption rather than an answer. The same pattern repeated across dozens of similar complaints each month, and the retailer deferred a planned change to its distance criterion because there was no way to measure the impact.
Solution Overview
Fluent Commerce Order Management System (OMS) solves this through Sourcing Auditability: an immutable audit record written at the end of each sourcing request that captures the inputs, the evaluation, and the outcome. Every sourcing decision becomes explainable after the fact, without reconstructing it from logs.How it works at a glance: As the framework runs, the sourcing utilities collect the key inputs, evaluation results, and outcome of the sourcing request. At the end of the request the record is submitted through the`createSourcingAudit` mutation, stored as a compressed JSON document in cloud object storage, and read back through the `sourcingAudits` query. Audit records are presented in the Sourcing tab of the Order Management Interface to users who hold the required permissions.1. Record Every Sourcing Decision as an Immutable Audit
Each completed sourcing request produces one`SourcingAudit` record. It captures the entity and retailer context, the resolved sourcing profile and its version, the master list of items sourced, and the overall status of `FULLY_SOURCED`, `PARTIALLY_SOURCED`, or `NOT_SOURCED`.- A single order can produce more than one sourcing request, for example one at creation and another when a short pick occurs, and each produces its own audit record.
- Records are immutable, with no update or delete operation, and are retained in line with the order and fulfillment data they describe.
- Audit capture never changes the sourcing outcome. A failed write is logged and the sourcing result proceeds unchanged.
2. See Which Strategies Ran and Which Conditions Passed
Each strategy considered is recorded in priority order with its status:`SKIPPED` where a condition failed, `EVALUATED` where its conditions passed and it ran, or `NOT_CONSIDERED` where an earlier strategy had already produced the required fulfillments.- Every condition is recorded with its pass or fail result, showing exactly why a strategy did or did not apply to the order.
- The resolved sourcing profile and version identify the configuration in force at the moment of the decision, which distinguishes a logic change from an inventory change.
- Fallback behavior is visible, so you can see when a primary strategy was bypassed and a fallback produced the result.
3. Compare the Selected Location Against Any Considered Location
For the strategy that produced the fulfillments, the audit retains per-location detail: each considered location, its evaluated-criteria results, and the items it could not fulfill. Location comparison places the selected location alongside any other candidate evaluated by the same strategy.- Each criterion is shown with its normalized score and actual value, identifying which criterion separated the two locations.
- The location position, the rank of a location before the final available-to-sell check, shows whether the most suitable candidate was the one selected.
- Missing items are recorded per location, distinguishing a location ranked lower on criteria from one excluded by an inventory shortfall.
4. Support Governance, Analytics, and Change Validation
Audit records are access-controlled and available through the Fluent APIs, which supports both enterprise governance obligations and downstream analysis.- Access requires the
`SOURCINGAUDIT_VIEW`permission, and sourcing profile detail is populated only for callers who also hold`SOURCINGPROFILE_VIEW`. - Immutable, tenant-isolated records provide the evidence trail that regulatory and internal audit requirements call for.
- Historical decision data supports analysis of which criteria configurations produce the best outcomes, and can be consumed into monitoring and analytics tools.
- Product and engineering teams can confirm how a change to a profile, strategy, condition, or criterion affected real fulfillments before rolling it out more widely.
Solution
Sourcing Auditability Overview
Sourcing Auditability records why the Responsive Sourcing Framework made each sourcing decision. For each Sourcing Request, it records the inputs evaluated and the outcome reached, so you can review the decision later.It helps teams understand:
- Which Strategies and Conditions were evaluated
- Which Locations were considered and how they scored against their Criteria
- The Location(s) selected, and why
- What Sourcing Auditability captures and why it matters
- What you can see and answer with it
- Where audit data appears, and where to find interface and API detail
Sourcing Auditability GraphQL API Overview
This article provides technical users with information about the Sourcing Auditability GraphQL API, which writes and reads Sourcing Audit records within the Responsive Sourcing Framework.
