iFAKT - Supply Chain Visibility - Connecting Suppliers, ERP and Logistics Data in Fabric 00:00:00 Speaker: Receiving the message creates a responsibility. Once your service tells the partner that delivery succeeded, you need a retained copy that can survive a process. Stopping before the next step completes the receiving route should fit the partner's existing arrangement. That might mean managed file transfer for scheduled documents, an API endpoint for incoming notifications, or a business integration service already handling your trading relationships. Keep a working partner connection where it fits. If an existing service already receives supplier documents, reliably extend its handoff rather than asking every supplier to change delivery methods. Just because your internal analytics platform changes for transferred files agree. When a file becomes ready for collection, your intake process needs a clear completion signal, such as an agreed rename after upload so it doesn't collect a document while the sender is still writing it. An endpoint needs an equally clear acceptance point return a successful acceptance response only after the message reaches the durable destination your design requires while respecting the response timing agreed with the sending service. Azure Logic Apps can handle supported integration patterns, where its connectors and business integration capabilities fit the exchange. You can use workflows to receive documents and route them through the required handling steps. Check the chosen plan and connector limits. First message sizes, supported protocols, and execution behavior need to suit the actual partner exchange rather than assumptions based on a small document used during development. Azure functions fits a narrower piece of custom work. You might use a function to unpack a partner specific wrapper, or extract a reference that the standard integration path can't handle. Without custom code, keep that custom work bounded. A function should complete a defined task and pass its result onward, rather than become an undocumented trading platform that only its original developer knows how to repair. Some exchanges need buffering between receipt and further processing a durable queue through a service such as Azure Service Bus. Where appropriate, lets accepted work wait while the next component recovers or catches up. The queue needs an operating policy. Define how long messages can wait and what happens when processing falls behind. Because durable storage gives you recovery time, rather than unlimited capacity or permission to ignore a growing backlog. Retirees should depend on the failure. A temporary connection problem may justify another attempt after a delay, while a document that repeatedly breaks the same mapping needs investigation instead of more identical attempts, put a limit on automatic attempts. After that limit, move the message into a failed message path with the error details and a reference to its retained contents, so someone can investigate without blocking unrelated deliveries. That path needs a person responsible for it. Assign responsibility for reviewing failures and authorizing another attempt with enough information to distinguish a partner. Document problem from a fault in your own handling logic. Retain the original payload before changing its contents alongside it. Keep the platform, receipt time, and partner references, plus an internal intake reference that connects processing attempts back to the same received document. An error description isn't a substitute for the document. When a supplier disputes how you interpreted a dispatch notice, the retained original lets you examine what arrived rather than reconstructed from transformed fields. A mapping repair should allow controlled replay. Suppose the suppliers dispatch notice reaches intake, but a mapping defect prevents your process from reading a valid shipment reference that the document already contains. Correct the mapping, then test the retained document against it before releasing the result downstream. Check which earlier steps completed so replay doesn't repeat a business effect that already succeeded before the failure occurred. Replay also needs its own history. Preserve the original receipt time record, the later processing attempt, and note which mapping version handled it. So recovery doesn't disguise an older document as newly supplied evidence. The handoff into Microsoft Fabric starts after that, receiving responsibility is clear past the retained document or its prepared representation onward with its intake reference and processing outcome, while keeping transport acceptance separate from successful analytical processing that gives recovery a defined boundary. A fabric processing failure can then trigger work from an identifiable retained input, rather than force purchasing to ask the supplier to send the same document again inside fabric. The first choice concerns how each input gets processed. A scheduled purchasing extract and a stream of carrier updates can contribute to the same supply assessment without following the same ingestion route or running on the same schedule. Fabric Data factory pipelines can coordinate supported ingestion and processing steps for a scheduled extract. A pipeline might copy the prepared records into storage, then start the transformation that prepares those records for the supply model. After the copy completes, check the exact source and connector before choosing that route. Support for a particular database or storage service doesn't mean every authentication method, network arrangement, or extraction pattern you need will work in the configuration you've selected. Orchestration describes the sequence of work. In this case, the pipeline establishes that loading the purchasing extract comes before processing it, and that the dependent step runs only when it's required input is available. One lake provides fabric's shared logical storage foundation. A lake house can hold files representing retained source records alongside tables prepared for analysis, giving you somewhere to keep the supply detail and somewhere to build the business representation. Those representations have different jobs. The retained supplier document preserves what arrived, while a clean shipment content table makes the relevant quantities and references easier to combine with purchasing and production records during analysis. Keep that distinction clear in the storage design, you might organize source files by intake route and load period while organizing prepared tables around business objects. Because investigating a document and querying supply coverage require different access patterns. A Lakehouse supports work with files and delta tables that can suit a team, using spark to process varied source structures before publishing consistent tables, especially when the incoming records don't begin as neat relational extracts. But a lakehouse isn't the only useful destination. Fabric warehouse can suit relational reporting workloads, where teams want to build and query structured business tables using Transact-sql, the SQL language used across Microsoft's database tools. Consider the purchasing analyst investigating open order lines. If the work centers on structured joins and reporting tables, a warehouse may fit that workload without requiring the analyst's working process to revolve around file handling or spark jobs. You don't need both. Just to complete an architecture checklist, choose the serving arrangement around the queries, engineering skills, and data management needs you actually have. Then add another store only when its role justifies the extra work. The carrier feed introduces a different processing pattern. Fabric event streams can ingest, transform, and route events through supported sources and destinations, giving suitable event workloads a continuous path rather than waiting for the next scheduled pipeline run, that path still needs a destination matched to its use. An event house provides an environment for event oriented analytics through Kql databases, which can suit querying transport milestones over time using Kusto query language or Kql alongside SQL, where supported. Think about the question each store helps answer. An event focused query might examine the sequence of carrier milestones for a shipment, while a relational reporting query combines that shipment with purchasing records to describe its business context, neither route replaces the other. By default, purchasing extracts may remain scheduled loads, while carrier notifications follow an event path because the source behavior and analytical workload differ even when both concern the same delivery. Connecting those paths takes explicit engineering. Putting records in the same fabric environment doesn't automatically make an event. House query and a lake house table. Part of one synchronized business model. So define where their outputs meet. That meeting point could be a prepared data set. For example, an event processing result describing the latest reported transport milestone could feed a broader analytical table. While the detailed milestone history remains available for event oriented investigation. Choose that exchange deliberately, including its refresh behavior. A frequently updated transport result, combined with an older purchasing extract, still produces an assessment whose parts describe different moments even though every component sits inside fabric. The next requirement applies to both routes whether a record arrives through a scheduled pipeline or continuous event processing, it needs a consistent set of context fields so downstream work can interpret it correctly. The shared structure is the event envelope we'll define next. The envelope describes the evidence, not just the delivery mechanism. It gives downstream processing a consistent way to identify who reported something, what it concerns, and which kind of business occurrence the record claims to describe. Give the source enough detail to distinguish its origin. A carrier name alone might be insufficient if separate regional services issue records under different accounts, with identifiers that are unique only within each service. The business reference identifies what the event concerns for our seals. That could be the carriers shipment reference qualified by the source that issued it with the matched internal shipment reference attached separately when available, the event type states what the record reports user defined meaning such as an observed arrival or a revised arrival estimate. Because those statements describe different evidence even when they concern the same shipment, include event time and platform receipt time as separate fields. An arrival event needs the time reported for that arrival, while a revised estimate needs the time the estimate applies from. According to the source contract. Don't force a missing time into an invented value if the source supplies no event time represent that absence explicitly and retain the receipt time without presenting it as the moment the reported occurrence happened. Identity then determines whether this evidence is already known. A stable event identifier lets processing recognize the same reported occurrence across delivery attempts, provided the partner guarantees that identifiers scope and reuse rules. An identifier needs a namespace. If a carrier restarts its numbering for each customer account, the identity must include that account context rather than treat the carriers event number as globally unique, revisions need a rule of their own. Ask whether a correction receives a new identifier, keeps the original identifier with a revision number, or replaces the content returned under that identifier without an explicit revision field, that answer shapes deduplication. Treating every repeated identifier as disposable could discard a valid correction, while treating every change payload as a new occurrence could count a corrected arrival twice in the event history. Some partners won't provide a dependable event identifier. You may need a documented combination of fields, but test whether it distinguishes genuine repeated occurrences, as well as recognizing repeated deliveries of the same occurrence. A shipment can visit the same depot more than once. Matching only shipment location and status could collapse two genuine visits, so the partner's sequence reference or another occurrence specific field may need to participate. Keep deduplication rules specific to the source contract record which rule identified a duplicate and preserve its connection to the retained input, so an investigator can challenge the decision without guessing how processing classified it. Status interpretation deserves the same traceability. Store the partner's original status, code and wording beside your mapped business, meaning, rather than replacing the supplied values with a cleaner label that hides the interpretation. Take a hypothetical carrier status called delivery complete. Its agreed meaning might be completion of a particular transport leg, so your mapped meaning should retain that scope instead of implying completion at the receiving plant. The mapping itself needs a version. Attach that version to the interpreted record, allowing someone reviewing an older assessment to establish which definition converted the carrier's wording into the business meaning used. Then the envelope also needs an explicit schema version that identifies the agreed structure and field definitions, giving producers and consumers a way to change the exchange without silently making different assumptions about the same record. An added field may be compatible with existing consumers. Your contract can permit consumers to ignore unfamiliar optional fields, while still requiring that existing fields retain their agreed type, purpose and interpretation across that change. A changed meaning needs different treatment. If a partner starts using an existing arrival field for a different destination, unchanged field names won't protect you, so require notification and an agreed version change. Define that change process before it becomes urgent. State who approves revisions, how compatibility gets tested, and what processing should do with an unsupported version, rather than let each consuming service improvise its own response, the envelope now makes interpretation explicit before any interpreted event changes. The trusted shipment or order state, it still needs checks that establish whether its contents and relationships are fit for that use. Quality checks need a consequence attached for every failed check, decide whether the record must stop, needs investigation or can support a limited use while someone resolves the defect that remains. Begin with the references required for the intended use. A shipment update without a usable shipment reference can't update a particular delivery, even if its status and reported location look perfectly reasonable on their own. Check units against the rules for the supplied material. A recognized unit code can still be wrong for a particular part, and a conversion requires an approved relationship rather than a guess based on familiar packaging. Quantity checks need business context. A negative quantity might indicate a valid reversal in one exchange, but in a notice declaring newly dispatched goods, it should trigger investigation unless the agreed document rules explicitly permit it. Relationships need checks beyond whether individual references exist. A supplier purchase order and part can each be valid while the combination is wrong because that order belongs to another supplier or doesn't include that part. A fail check shouldn't produce one generic error outcome. I distinguish rejected records from quarantined records and records accepted with warnings, with each outcome stating what downstream use remains permitted and who must respond. Rejection means the submission can't enter the trusted model. For example, if a required quantity contains text that the agreed format doesn't permit, reject the submission with a precise reason and retain its connection to the received input. Quarantine means the answer requires investigation. The record might be structurally readable, but contain a purchase order reference that doesn't belong to the stated supplier, so keep it outside trusted calculations until someone resolves that conflict. Warnings need a narrower, deliberate permission if an optional package description is missing, but every field required for material matching remains valid, the record might still support that use while carrying a warning for investigation. Don't let warnings become a waiting room without an owner. Repeated defects need review because a field considered optional for one calculation could still matter to another process that receives the same prepared record later. Consider a unit mismatch in our hypothetical seal delivery. Suppose a partner sends a quantity of twenty, but its interface labels that quantity as cases when the receiving transaction actually describes twenty individual seals. Assume the approved pack contains ten seals per case. Applying that conversion would turn the reported twenty into two hundred seals, creating stock cover for production that the actual received quantity can't support at all. The arithmetic works. The interpretation fails. A check that merely recognizes case as a valid unit would pass this record. So validation also needs the parts approved. Purchasing and receiving unit relationships. Even those relationships might not expose this error. If both units are permitted, someone may need to compare the transaction with its receiving evidence before deciding whether the unit or the quantity needs correction. Route that question to the receiving process owner. The Item master owner should verify the conversion relationship while the source owner checks the actual transaction. Because those checks answer different questions about the same discrepancy, supplier mappings need a named owner to assign a person or role to resolve partner reference defects with a clear route to the purchasing or engineering authority required when the proposed correction changes, what material is recognized? Keep source corrections with someone authorized to change the source. An analyst might identify a bad receipt unit, but correcting a reporting table alone would leave the operational transaction wrong and invite the discrepancy to return. Every unresolved defect needs a practical work item. Include the failed rule affected reference, responsible owner and the evidence required to release or correct the record. So investigation starts with a specific question rather than please fix data. Closure needs evidence, not just a cleared flag. Once the owner resolves the defect, rerun the applicable checks and record the correction that permitted acceptance without disguising the original submission or its earlier classification. That gives trusted records a defined admission process. We can now assemble the accepted purchasing evidence into a usable order model, while keeping unresolved records from quietly contributing quantities or commitments that nobody has verified. Eleven model orders below the header level. An order header can't accurately describe the remaining supply. If one line arrives in full while another arrives in stages. A single status for the purchase order hides the distinction the planner needs to understand. I'd give the header a limited job. It holds details that apply across the purchase order, like the buying business and supplier, while separate line records describe each purchased material and its ordered quantity. A delivery schedule sits beneath the line where the purchasing process supports scheduled deliveries. Each schedule record identifies a quantity due at a particular time, rather than forcing several commitments into one line level. Date revisions need separate records to keep the approved changes connected to the header line or schedule they affect, so the model can distinguish today's position from the commitments recorded before those changes. Those records answer different questions. The line tells purchasing how much it ordered, the schedule describes when portions should arrive, and the revision history explains how that arrangement changed during the order's life. Quantity needs more than one field track ordered, confirmed, shipped, received, rejected, and canceled quantities separately. Because each describes a different business condition rather than another name for the same total moving forward. 00:16:45 Speaker: These quantities aren't a set of buckets to add together. A seal already received may also appear within the cumulative shipped and confirmed quantities, so summing those figures would count the same supply several times. Consider another detail in our hypothetical order. Suppose a line requests one hundred seals, the supplier confirms eighty, dispatches fifty, and the plant records forty received, with five of those forty subsequently rejected. Each quantity still has a purpose. Purchasing can see the gap between the request and confirmation, while the difference between shipped and received identifies supply whose receiving outcome hasn't yet been fully recorded. Rejection needs its own interpretation. State whether the rejected quantity belongs within the recorded receipt total or outside it. Because either convention can exist and the calculation must follow the source process cancellation changes the outstanding obligation under agreed rules. If purchasing cancels part of the line, retain that quantity separately and specify whether the sources ordered quantity represents the original request or the current revised amount. Otherwise, subtraction can produce the wrong answer. Deducting cancellation from an ordered quantity that already excludes it would reduce the remaining requirement twice, even though every individual field contains a legitimate source value. Partial delivery also needs a precise attachment point. Apply each received quantity to the relevant line and were supported by the purchasing process, its delivery schedule, leaving the unfulfilled portion visible instead of marking the whole line. Complete completion can include an approved business decision. A buyer might close a small remaining balance without expecting another delivery, so distinguish closure from full receipt rather than inventing received quantity. To make the figures reconcile commitment, history should remain readable after a date changes, preserve the original promise and each subsequent revision. Then identify which accepted commitment currently governs the outstanding quantity without rewriting the earlier record to match today's expectation, a revised date may cover only the remainder if part of the seals already arrived, attach the new commitment to the quantity still due, rather than making the completed portion appear to have arrived against a later promise. Field authority makes this model workable. The purchasing process governs approved order quantities and cancellations, while supplier confirmations and despatch declarations retain their own authority for what the supplier has committed or reported, sending receipt and rejection need their designated operational authorities populate those measures from the processes authorised to record them with corrections applied through those processes, rather than allowing the latest supplier message to replace a receiving result. I wouldn't compress that into one universal order status. A line can be partly received, partly awaiting despatch and carrying an unresolved supplier proposal, with each condition supported by different evidence about a different portion. The model should expose that position without forcing a false conclusion. It can report the quantities received against the order and the balance still expected, while stopping short of claiming that every received seal can satisfy production demand. That boundary brings us to inventory. Receiving tells us what entered the recorded purchasing flow, but deciding what production can use requires another model that represents the conditions attached to that stock. Inventory needs a defined level of detail for each stock record. Specify the part plant storage location lot where applicable, and stock status. So a quantity always describes a particular stock position. That detail is often called the grain. It tells anyone querying the model what one row represents and which distinctions they must preserve before combining quantities into an answer for a specific material requirement. Location matters even within the same plant. Seals in a receiving area and seals in a production supply location might share a material number, but combining them removes information about where that stock actually sits. Lot and status create further distinctions. If one lot occupies several locations or carries different statuses across quantities. Preserve those separate positions rather than assigning one location or status to the entire lot. On hand quantity describes stock recorded as physically present. Keep reservation quantities and stock restrictions separately identifiable because their relationship determines how much of that recorded stock remains available for a particular requirement at that moment. Those categories can overlap. A reservation may refer to Stock already included in on hand quantity, while blocked and inspection quantities may represent status based portions of that same total depending on the source model. So define the calculation before subtracting anything. If a source already excludes blocked stock from its availability field, subtracting blocked stock again in fabric would understate availability without any error in the source records. Usable stock needs a stated purpose. It should describe the quantity eligible for the requirement being assessed under the applicable stock rules, rather than become another unexplained field that different teams interpret differently. Reservations need special care in that calculation, stock reserved for the production order under review can support that order, while stock reserved for different demand normally remains unavailable unless an authorized process changes the allocation and retain the reservation reference with its quantity. That lets the calculation distinguish stock already assigned to this requirement from stock committed elsewhere. Instead of subtracting every reservation and accidentally removing the order's own allocation, the current position also needs a history. Retain stock transactions alongside periodic snapshots with each transaction identifying the stock position it changes and each snapshot stating the point in time its balances represent transactions. Explain movements between positions as well as quantity changes. Moving seals from one storage location to another reduces one position and increases another, while leaving the plant total unchanged. If both sides complete correctly, a snapshot provides a balanced checkpoint to advance that balance. Apply only transactions not already represented in it using the sources supported transaction sequence or cut off rules, rather than relying on approximate extraction times. Reversals belong in that history to preserve their connection to the original transactions where the source provides it, so a corrected movement doesn't remain counted alongside the transaction that canceled its effect. Reconcile the resulting balances against the source inventory ledger, compare at the same grain and a compatible cutoff, then investigate differences instead of inserting an unexplained adjustment just to make the reporting total agree a plant wide match can hide local errors. One location could be overstated, while another is understated by the same amount, so reconciliation needs enough detail to expose differences that would affect the usable stock calculation. Available to promise adds a policy decision to those balances. Often shortened to ATP. It calculates what supply can be committed against demand under agreed rules, potentially including planned receipts as well as current stock. Document exactly which receipts qualify a purchasing commitment, a planned transfer and a planned production receipt. May receive different treatment, so the rule needs to state their eligibility rather than include every future quantity, name, who controls reservations and planned receipt records. The analytical model can calculate coverage using their approved state, but it shouldn't quietly release allocations or change expected supply because a different allocation produces a more convenient answer. Keep that calculation separate from making a commitment. Two users can read the same apparent spare quantity, so an actual promise needs the authorized source process to check current availability and record the commitment that leaves expected supply outside the stock balance. We can include an incoming quantity under explicit planning rules, while still keeping it distinct from on hand stock because the material remains somewhere in the transport network. A tracking number doesn't describe the whole journey to understand where the incoming seals actually sit. We need to distinguish the goods traveling together from the packages, individual movements and stopping points involved. The shipment represents the goods grouped for transport beneath it. A handling unit identifies a physical package, pallet or container that people can move and track separately, even while it remains associated with that shipment. Our Seal shipment could occupy several pallets if the carrier separates those pallets during handling. A milestone for one pallet shouldn't automatically establish that every pallet has reached the same point along the route. A transport leg represents one movement between locations. The journey might include collection from the supplier, travel between depots and final delivery to the plant, with different vehicles or carriers responsible for different legs. A stop describes a planned or actual visit. It identifies where the transport operation calls and what should happen there, allowing a route with several deliveries to distinguish our plant from other destinations. These objects connect, but they aren't interchangeable. A vehicle reaching a stop tells us something about that visit. While a handling unit scan can establish which particular pallet the operation recorded at that location. Attach milestones to the object they actually describe, where a carrier reports only a shipment level event retain that scope, rather than manufacturing pallet level evidence that the carrier never supplied or claimed to observe. Then define what each milestone means operationally. Pick up should describe the agreed collection event while departure identifies leaving a stated location. So completing collection doesn't automatically establish that the vehicle has started its onward journey. Arrival also needs a name, destination and scope. An arrival at the transfer depot completes a different movement from arrival at the plant. Even if both events carry the same short label in the carrier feed. Unloading describes another step in the visit. A vehicle might arrive and wait before unloading begins, so the model needs to distinguish reaching the destination from removing the goods from that vehicle. Proof of delivery records the carrier's delivery confirmation. Depending on the service agreement, it might include a signature or other supporting evidence, but its meaning still depends on what hand over that confirmation actually covers. Map those milestones against the carrier's documented process. If a status means the driver completed the delivery task, preserve that meaning rather than interpreting it as confirmation that every package passed, you're receiving checks. Expected arrival needs the same precision as observed arrival. An estimated time of arrival, often called an ETA, should identify the location being predicted and the source responsible for supplying that particular estimate. Record when the estimate was calculated as well. A carrier prediction produced before the vehicle reached a congested depot can remain visible after circumstances change, so the prediction needs that context attached to its value. Uncertainty belongs beside the predicted time. If the carrier supplies an arrival window, retain the window rather than reducing it to a single minute, that sounds more precise than the source intended. Some services publish only a point estimate. In that case, state that no uncertainty range was supplied. Rather than presenting the absence of a range as evidence that the predicted arrival time is dependable. Different estimates can target different places. A prediction for the plant gate and a prediction for the unloading bay can both be reasonable while describing different moments, so combining them under one arrival field creates confusion for our seals. Gate arrival still leaves work unfinished. The truck may need access clearance and a dock assignment before unloading, and the delivery record needs to preserve those steps rather than declare the material available. Goods receipt is a separate recorded outcome. Unloading provides physical access to the shipment, while the receiving process establishes what quantity the plant records as received, including any discrepancy found during that work. Quality release can follow after that receiving activity. If the seals require inspection, their arrival and receipt, don't remove that condition. Even when the carrier has completed its delivery and closed the transport job. Material availability therefore needs its own stated milestone or assessment. The transport model should provide the arrival evidence relevant to that assessment without relabeling a completed journey. As confirmation that production can take the seals, each step now carries a different moment. Following the journey accurately means keeping those timestamps distinct because the time something occurred and the time its report reached us can describe very different stages of the same delivery. The order in which reports arrive can mislead the planner. Suppose the carrier reports departure from the depot, then sends an arrival report that describes an earlier visit after a delay in its reporting service. Both reports can be correct if processing treats the last message received as the current position. However, the shipment appears to move backward into the depot even though the departure remains. The latest reported physical movement. Separate the clocks before deciding which evidence changes the current assessment. Physical event time describes when the reported movement occurred. Source update Time describes when the carrier recorded or revised it, and platform receipt time describes when your platform received the report. Each clock answers a practical question. Comparing physical event time with source update time helps expose reporting delay while comparing source update time with receipt time helps locate a later delay in passing the information onward. Receipt order alone shouldn't determine business order. Use the sources, documented sequence and revision rules, together with the relevant timestamps, to decide whether a report advances the current position or adds detail to its history. A late report can still change the answer if an earlier arrival report identifies a different depot from the one previously recorded. That correction may affect how you interpret the subsequent journey, even though it doesn't replace the departure milestone. Corrections need an explicit relationship to the evidence they revise. Suppose the carrier corrects a departure time after discovering a scanning error, while the correction itself reaches fabric later than several other reports about that shipment. Apply the correction to its stated target preserve when the corrected movement occurred and when the carrier issued the correction, rather than treating the corrections publication time as another physical departure from the depot, time zones introduce a separate source of mistakes. A supplier timestamp, a carrier timestamp and a plant timestamp may use different local clocks, so comparing their displayed values directly can put valid events into the wrong order. Keep a common reference for comparing instance across systems. Coordinated Universal Time or UTC provides that reference while retaining the supplied local value and offset helps someone investigate how the timestamp entered the model. Local business time still matters to the planner. Converting everything to UTC supports comparison, but receiving hours and shift boundaries belong to the plant's local calendar, including the rules that apply on that particular date. Daylight saving changes make missing context harder to repair. When clocks move backward, the same local time can occur twice, so a timestamp without an offset or another disambiguating reference may not identify one definite instant. Don't guess which occurrence the source intended. Mark the time as unresolved where necessary and seek clarification under the source agreement, especially if choosing the wrong occurrence would change where the material appears to arrive before the deadline. Calendar rules then turn an arrival estimate into an operational constraint. A truck expected after receiving closes may have to wait until the next receiving window, even if the carrier still describes the journey as on schedule. A weekday label doesn't establish that receiving will operate. Apply the receiving locations, actual calendar, including holidays and planned closures. Rather than assume that the production shift calendar also describes when incoming deliveries can be handled. Freshness rules should follow the decision being considered for an urgent collection choice. The planner may need a recent transport observation, while a longer range review can tolerate older evidence if it still supports that particular judgment. Separate the age of evidence from the health of collection. A successful request returning the same milestone proves the request worked, but it doesn't establish that someone recently checked the shipment or confirmed its physical position. Silence leaves the current situation uncertain if an expected update doesn't arrive. Retain the last reported position with its age rather than advance its timestamp or imply that the carrier confirmed nothing has changed. That uncertainty should change what the answer claims. The planner can still use the last known evidence under agreed rules, but needs to know when it no longer supports a confident choice without further confirmation. People asking the same question need the same treatment of time with event ordering, calendar rules and evidence age defined, we can put those interpretations into a shared business layer instead of letting each report produce a different answer. A shared business layer gives those interpretations a place to live in power BI. A semantic model can define relationships and reusable measures over prepared data, so reports draw on agreed calculations rather than rebuilding them separately. I treat that model as a maintained business agreement. The technical team implements the measures, but purchasing and operations need to approve what those measures mean, including which records qualify and which conditions prevent a confident answer. Start with a word people use. Casually overdue for a purchasing measure. You could define overdue quantity as an outstanding obligation whose accepted receipt deadline has passed, excluding balances formally closed under the purchasing rules. Give that measure a specific name overdue against accepted commitment tells the buyer which promise the calculation tests, whereas a label such as late orders leaves the reference date and quantity basis unexplained. Requested date performance answers another question a supplier could meet an accepted revised commitment while missing the date your plant originally requested, so publish those as separate measures rather than asking one overdue figure to represent both judgments in transit also needs an agreed boundary. For example, your definition might include quantity supported by collection evidence that hasn't reached the agreed delivery endpoint while keeping supplier declared dispatch outside that narrower measure until collection is confirmed. Choose a definition that suits the business question. Whatever boundary you choose, record the entry and exit conditions, then test whether aggregating the result preserves that meaning across the shipment quantities represented in the model. Usable stock needs a similarly precise measure name instead of publishing one unrestricted total, expose a calculation whose description states the relevant eligibility rules and assessment context so users know what question that quantity can answer. Expected shortage adds a comparison against the requirement. Define it as the uncovered quantity at a stated requirement time under a named supply scenario, with the treatment of uncertain receipts documented alongside the calculation itself. 00:33:37 Speaker: Keep the scenario visible in the result. A shortage calculated using accepted commitments can differ from one using current arrival expectations, and both can inform discussion if people can distinguish the assumptions behind each answer. Dates need separate roles within this model. The requested receipt date describes the buyers requirement. The confirmed receipt date represents the selected supplier commitment. The expected receipt date carries the current forecast and actual receipt records the receiving outcome. Use those roles deliberately when filtering a measure. If someone asks about receipts expected next week, the calculation should use expected receipt dates rather than quietly selecting order lines whose requested dates happen to fall within that week. One calendar can support several date relationships in power by the model. Designer can use separate role specific date tables or explicitly selected relationships, provided each measure consistently applies the date role its name promises. Test questions in ordinary business language. Ask what received this month includes which date governs due this month, and whether changing the reporting period changes only the intended part of each calculation rather than unrelated quantities. Control definitions also need control changes when purchasing revises the overdue rule record the change in its effective use, then review dependent measures so an improvement to one calculation doesn't silently alter another team's interpretation. Traceability makes those definitions open to challenge from an expected shortage measure. A user should be able to reach the contributing records, inspect the quantities and dates selected, and identify which exclusions shaped the reported result. That path needs engineering. It doesn't appear automatically preserve source references through the prepared tables and provide a supported, detailed query or drill through route so the semantic models answer can be checked against identifiable business evidence. Freshness belongs on that investigation path to show the assessment time and the relevant evidence ages with their source references. Because a recently refreshed semantic model can still contain an old supplier commitment or transport forecast. I test that path with a disputed answer. If a buyer challenges an overdue quantity, someone should be able to explain the selected deadline, remaining obligation source records and calculation version without manually reconstructing the report. Agreement now gives us a consistent answer to a defined question. The next question concerns production. When that answer identifies an expected shortage, which work actually depends on the missing quantity and when does that dependency become a problem? A part number gives us a starting point, not an impact assessment. We need to connect the delayed quantity to specific material requirements, then establish which production orders still lack eligible supply when those requirements fall due. The Bill of material describes the product's component requirements. Often shortened to Bom, it specifies which components a product needs, but the production orders demand records describe the requirements actually created for that particular work. Use the order specific requirement where it's available. Engineering changes, order quantities, and permitted variations can mean today's general product structure differs from the material requirement attached to an order released earlier under another approved revision. Timing belongs to the requirement itself if seals enter during a later assembly operation link. There need time to that operation rather than assuming every component must be available when the production order starts for a pump plant built a time phased coverage calculation. That means following eligible supply and demand through time, applying each expected receipt and material requirement at its relevant point. Instead of comparing whole day totals, imagine sufficient seals arrive halfway through the shift. The day's total supply could exceed the day's demand, yet an early assembly operation could still lack material because the incoming quantity arrives after that operation needs it. Begin with usable inventory. At the assessment cutoff, apply the planned consumption that remains after that point, then introduce expected receipts at their estimated usable times, preserving which supply supports each requirement along the way. Count each quantity once within the selected scenario. If a receipt already contributes to the opening inventory balance, it must not appear again as incoming supply and consumption already posted mustn't remain as an unchanged future requirement. Shared demand makes allocation policy part of the calculation where several orders require the same seals. Apply existing reservations and the agreed demand priority. Rather than letting the database row order determine which production order appears covered. Keep the uncovered requirement attached to its order and operation. A projected balance below zero identifies a timing gap, while that connection tells the planner which work lacks coverage under the allocation policy being tested. Eligibility can vary between requirements for the same part. One pump configuration might permit an alternative seal, while another prohibits it, so the dependency model needs approval. Relationships that connect substitutes to their permitted applications and validity periods. Substitution also needs the correct quantity relationship. If an approved replacement requires a different quantity per assembly, the coverage calculation must use that requirement rather than exchange the original and replacement quantities one for one lot. Rules can further limit apparent coverage. An order might require all seals from one approved lot, meaning several smaller eligible balances can't necessarily combine to satisfy that requirement, despite providing enough seals in total quality restrictions need the same requirement. Level treatment a lot released for one application may remain restricted for another, so eligibility should follow the applicable approval rather than a plant wide assumption that release permits every use. These relationships can live in ordinary relational tables. Prepared tables and fabric can connect requirements, eligible supplies and approval records without requiring another modeling technology, provided those joins remain understandable and perform adequately for the workload. A knowledge graph becomes worth considering when traversal dominates the questions. It represents objects and their relationships explicitly, which can help explore several connected dependencies. When repeatedly joining fixed tables becomes difficult to maintain or extend. Consider a question spanning more than the immediate component which assemblies depend on this restricted seal revision, including intermediate products that consume it and which open production orders require those assemblies within the period under review. A digital twin may fit a broader maintained operational model if you already represent production assets, material flows and their changing states. Connecting supply dependencies there could support related operational questions beyond this particular shortage calculation. Neither choice supplies missing business rules. Your organization still has to define valid dependencies and eligibility conditions, while fabric provides data processing and analytical capabilities. Rather than automatically supplying a complete manufacturing dependency model, I choose the simplest model that answers the required questions whether relationships sit in tables or a graph, test the result against known requirements, and check that every allocated quantity remains traceable to eligible supply. The output should narrow the planner's work, carry forward the uncovered requirements with their affected orders, and need times so the next step can turn dependency results into a small set of actionable exceptions. An uncovered requirement doesn't always justify interrupting someone. The alert rule needs to combine the projected shortage with the production need, time, uncertainty around incoming supply, and the time required to carry out a response. Start with the last practical moment for intervention. If arranging a collection takes longer than the remaining window. A warning about that option has already arrived too late, even though production hasn't reached the material requirement yet. Arrival uncertainty can move that warning earlier, where an arrival window extends beyond the usable material deadline, the rule could flag exposure before a shortage becomes certain, with the notification clearly stating that the outcome remains uncertain. Keep that distinction explicit in the rule result. Confirmed shortage under current supply and coverage depends on an uncertain arrival warrant different wording because the planner needs to know whether the evidence establishes a gap or identifies a risk. A sensible rule also considers how much work is exposed. Losing coverage for a small remaining quantity can threaten an entire operation if that operation can't proceed without it, so quantity alone shouldn't determine alert severity. DeLay duration can be a poor guide. A shipment delayed until next week might need no immediate intervention if sufficient eligible stock remains, while a shorter delay could remove the final workable option for today's production. I'd base severity on consequences and remaining choices, escalate the urgency when affected, work can't proceed, and the response window is closing. Rather than assigning every late shipment the same red label, regardless of its production impact. Options can disappear while the shortage stays unchanged. If the deadline for arranging alternative transport passes, the exception may deserve a higher severity. Even when neither the missing quantity nor the latest arrival estimate has changed. That means rules need time based re-evaluation to processing. Only incoming carrier events would miss an approaching intervention deadline during a quiet period, so evaluate deadline conditions on a schedule suited to the response window. Fabric activator can support rule driven detection and notifications on supported inputs. Check the available source condition and action capabilities for your chosen configuration, then establish how the prepared shortage assessment reaches the rule being evaluated. Other workflow services can handle notification where appropriate. The important engineering choice concerns which component evaluates the business condition and which delivers the message with a clear hand-off that avoids competing versions of the same rule. Now give the exception a stable identity. Several evaluations of the same unresolved shortage should update one continuing exception using an identity based on the affected requirement and rule, rather than on each evaluation time. Notification deduplication belongs above transport event deduplication even after repeated carrier messages have been removed, successive valid assessments can keep finding the same shortage, and that shouldn't generate another identical interruption every time. Processing runs suppression needs explicit limits. You might suppress unchanged notifications for a defined interval while still allowing another notification. When severity increases, more work becomes exposed or the remaining response time crosses an agreed threshold. Small estimate changes shouldn't cause repeated opening and closing. Where appropriate. Use separate trigger and clearing thresholds or require a recovery condition to persist. While checking that this delay won't conceal a fast developing shortage, escalation should follow a stated condition if an exception remains unattended as its intervention deadline approaches, notify the agreed escalation route instead of repeatedly sending the same message through the original route and calling that follow up closure requires a business condition as well. Close the shortage exception when the qualifying exposure has cleared under the agreed rule, not merely because a carrier changed its label or someone dismissed the notification. Missing evidence mustn't masquerade as recovery. If an assessment stops arriving, retain the unresolved exception with an explicit stale evidence state, rather than treating the absence of another shortage result as proof that coverage has returned. Test the notification behaviour across repeated evaluations. Feed the same unresolved case through unchanged results, worsening estimates, temporary improvement and sustained recovery, then verify exactly which notifications appear and when the exception closes. The recipient needs a reason to interrupt their work. What reaches them should explain the affected requirement, the condition that triggered attention, the uncertainty involved, and the time remaining for a response rather than simply announcing another transport status. That's the hand-off from detection to action. A notification earns its interruption when someone can understand why this work needs attention now, and has enough evidence to begin choosing a response without reconstructing the entire chain. Someone needs to accept responsibility for the exception itself. Create a persistent work record that connects the warning to the affected production orders, preserves the supporting evidence, and gives the assigned planner somewhere to record what they're doing. The notification should lead to that record. Email can tell someone attention is needed, but the work record should hold the current assignment and decision history when several people participate in the response. Include the action deadline as a specific time. The record should also identify the assessment being reviewed with links to its contributing evidence and the age of that evidence. When the planner received it preserved the evidence used for each decision. If a carrier estimate changes during investigation, the planner needs access to the new estimate without losing the earlier version that supported a recommendation already sent for approval. Assignment needs to reach a person, not disappear into a queue. You can assign through a team initially, but the workflow should establish who accepts responsibility and record any handover when another planner takes over. Use a workflow service that fits the operating process. Power automate or Azure Logic apps can coordinate supported assignment and approval steps, while an existing service workflow may already provide the ownership and approval controls your plant needs. Fabric supplies the assessment. The workflow manages the response. Connect them through a defined interface, so the exception identifier and assessment version remain attached to each assignment, approval request, and return decision throughout the process. I'd keep the business states plain open means the case awaits. Acceptance acknowledged means someone has accepted responsibility, and investigating means that person is actively collecting or checking evidence needed for a response. Acknowledgement doesn't mean the material problem has improved record who acknowledged the case and when, but keep that event separate from any recommendation, approval or confirmation that the affected requirement now has adequate coverage. Approved needs an object attached to it to the state should identify the proposed change, its scope and the assessment version the approver reviewed. Rather than merely record that someone selected an approval button for our Seals approval might permit a reservation change. The request should name the quantity and affected order so the approver knows exactly which allocation they authorize, rather than granting a general permission to rearrange stock resolution requires its own evidence, and approved response can still await execution, so retained that distinction until the applicable business condition is satisfied and the record contains evidence supporting the move to resolved execution needs a controlled route back into operations. If the response changes in ERP allocation or purchasing record, send that change through a supported source interface that applies the source system's validation and authorization rules. Don't update operational database tables directly. A shortcut can bypass business checks that the normal transaction applies, leaving related records inconsistent even when the field you intended to change appears to contain the right value. Permission to approve isn't necessarily permission to execute the integration. Identity needs only the rights required for its defined transaction, and the workflow must verify that the business approver holds authority for that particular change. Check the current source state before applying the instruction. A reservation could change while approval is pending, so compare the approved request with the current record and stop for review if its assumptions no longer hold. Treat a timeout as an uncertain result before trying again. Check whether the source already applied the instruction using a supported request reference or transaction lookup so one approved action doesn't create duplicate operational changes. Keep the audit trail connected across that boundary. Record the requestor approver approved content's execution, identity source, transaction reference, and outcome with timestamps that let someone reconstruct the actual sequence without searching unrelated workflow histories. A failed write back leaves work outstanding. Return the failure to the assigned owner with the source response, rather than marking the exception resolved because the approval workflow completed its own steps successfully. That still leaves the hardest part of the decision. Ownership and approval give us a controlled way to act, but the planner must now establish whether the proposed response can actually work for the affected production orders. A response can solve the shortage and still disrupt the schedule. Bringing another pump order forward might avoid waiting for seals, yet require a fixture that's already committed to another machine during the same shift. That's a scheduling question. The ERP may hold routings, work calendars, and planning functions, but whether it can test that change in sufficient detail depends on the system and its configuration. I check what the planning calculation actually assumes. Some planning runs work with capacity aggregated across a day or week. While the proposed change depends on whether a particular resource is free during a specific interval. Detail matters more than the application label. An ERP with suitable scheduling capabilities might answer that question directly, while another installation needs a specialist planning service to evaluate the same proposed production change. Advanced planning and scheduling or apps can provide that capability given an appropriate model. It tests how material availability. Finite resource capacity and sequencing rules constrain when each operation can run and which alternatives remain feasible. The model has to reflect the plant for the pump orders. That could mean assembly capacity. A shared test station and changeover rules that depend on which pump variant ran immediately before the next one. A resource calendar alone won't capture those sequence effects. If switching between two pump variants requires a different setup from repeating the same variant, changing the order changes the amount of production time available within that shift. Let's test the expedited delivery option against those constraints. The scheduling calculation should place the affected assembly work after the proposed material availability time, then check whether the remaining operations can still finish within their required windows. Earlier material doesn't guarantee earlier completion if the test station has no suitable opening afterward, paying for faster transport might leave the customer completion date unchanged, even though assembly can begin sooner than before. Substitution creates a different scheduling case. An approved alternative seal might involve a different assembly method or test requirement, so the scenario needs the applicable routing and operation times rather than only a replacement material reference. Splitting the order needs another calculation. Separate batches may require additional setups or compete for the same downstream resource, meaning the schedule must represent both portions instead of treating the split as a smaller original order. 00:50:29 Speaker: Resequencing changes the neighboring work as well. Compare the proposed sequence across the affected resources, including the operations displaced by the replacement job, so the planner can judge the resulting completion times rather than one isolated start. I'd compare alternatives from the same starting position, otherwise an expedite scenario calculated before another order changes and a resequencing scenario calculated afterward can appear different for reasons unrelated to the responses you're trying to compare. Scheduling and simulation can answer different parts of that comparison. A scheduler can construct a plan under modeled constraints, while simulation can test how a candidate plan behaves when processing times or other operating conditions vary. Feasibility still depends on the assumptions. A schedule that works with fixed operation times may need further testing. If the remaining margin is small, and normal, variation could push downstream work beyond its available window. Fabric can supply prepared inputs and retain scenario results. The scheduling engine provides the constraint logic, while your production team defines the operating rules and decides whether the modeled alternatives reflect choices the plant can actually execute. Return a selected plan as an explicit set of proposed changes. Depending on the integration, that might include revised operation times, resource assignments, or order splits expressed through interfaces. The receiving planning and Execution system support approval applies to that particular plan version. Before releasing it, compare its starting assumptions with current source records, especially resource availability and order progress. Because work may have advanced while the alternatives were being evaluated. A mismatch needs review or another calculation if an operation has already started on its assigned machine. The approved scenario can't simply move it elsewhere because that move remained possible when the scenario began. The planner also needs to understand the trade off. Once the scheduling work has established what each option permits and delays, industrial AI can help explain those differences without taking over the calculation that established feasibility. I'd give the assistant a specific question to answer for our seal shortage. That question could be why the recommended response changed after the latest assessment, and which new evidence explains the difference to the planner. Explanation is a useful bounded job for generative AI. The assistant can turn the assessment and planning results into plain language, provided it receives the relevant records, rather than trying to infer the factory's situation from general knowledge. Finding supporting evidence is another practical task. A planner could ask for the supplier response supporting an incoming quantity, and the assistant could retrieve that response with the relevant passage and its business reference. That retrieval needs to preserve context. A sentence promising delivery on Friday means little without the order, line, quantity, destination and date of the message, especially when the conversation contains several revisions to the same promise. I'd require references attached to individual claims. If the assistant explains that one option depends on supplier confirmation, the planner should be able to open the specific record supporting that statement rather than receive a general list of documents. Timestamps need equally clear labels. The answer should distinguish when the supporting statement was issued from when the assessment used it, so the planner can judge whether the explanation still describes the decision now under consideration. Missing support should narrow the answer. If the assistant can find a dispatch declaration but no collection evidence, it should state that limit directly rather than supply a confident account of movement beyond what the retrieved records establish. Access checks belong before information reaches the model. Retrieval should use the permissions applicable to the requesting planner, and any tool that obtains further records should enforce the same boundary instead of assuming the conversation grants access. A reference doesn't prove that a claim is supported. Test whether the cited record actually supports the sentence beside it, because a plausible explanation with an irrelevant citation can still send someone toward the wrong response. Keep stock calculations outside the language model. A defined calculation should produce coverage using the approved inputs and rules, then return its result and assumptions for the assistant to explain without changing the arithmetic during conversation. Feasible schedules need the planning tools. Answer. The assistant can request a permitted scenario through a controlled tool interface, but the planning tool must establish feasibility and identify the assumptions under which that result holds. The assistant should preserve those assumptions in its explanation. If a scenario depends on a confirmed collection time, it shouldn't describe the result as unconditional merely because the planner asks which option sounds best for tomorrow. Drafting supplier follow up is a useful next step. Using the unresolved questions in the assessment, the assistant could prepare a message requesting confirmation of the quantity available for collection and the earliest time the carrier can release it. Keep the draft separate from sending it. The buyer should review the requested commitments and wording, particularly where a message might imply acceptance of a revised delivery date or authorization for an additional transport charge. Supplier text also introduces a security risk. An incoming email could contain instructions telling the assistant to ignore its rules, retrieve unrelated records or send information elsewhere, even though that email enters through an ordinary business exchange. Treat that text as evidence, not operating instructions. The application should restrict which tools the assistant can call and validate their inputs, while keeping partner content separate from the instructions that define its permitted behavior. A warning in the prompt isn't enough. Tool permissions and application checks need to prevent an incoming document from expanding the assistant's authority, even when the document presents its instructions as urgent business guidance. Human approval remains necessary for consequential business actions. If the assistant proposes changing supply commitments or releasing a planning change, present the exact proposed action for authorized review. Rather than treating a conversational suggestion as permission, that creates a question beyond the assistant's wording when it searches purchasing records, or calls a planning service whose permissions apply, and can those permissions cross boundaries the planner couldn't cross without the assistant. Those boundaries span suppliers, plants, planners and service accounts before connecting. Another tool we need to establish which identity can obtain each record, and whether its result can safely reach the person asking the question. Start by separating identity from permission. Microsoft Entra ID establishes the user or application identity while each connected service must enforce what that identity can read, change or administer within its own authorization model. Use distinct identities for distinct integration responsibilities. The application collecting career milestones shouldn't inherit permission to read supplier pricing, simply because both activities belong to the same supply visibility project and share an administrator. Managed identities can reduce stored credentials where the connection supports them, where they aren't supported. Use a dedicated application identity with narrowly scoped rights, rather than a person's account whose access changes when that person changes roles define permission at every service boundary. Being allowed to run an ingestion workflow shouldn't automatically grant access to its destination tables, and being allowed to query those tables shouldn't automatically permit exporting their contents elsewhere. Fabric permissions need testing along the actual access paths, workspace roles, item permissions and data level controls interact differently across workloads, so check the supported behavior for each lakehouse, warehouse and semantic model you expose to users. A report is only one possible entrance, someone might query a so-called endpoint, connect another analytical tool, or access underlying files if their permissions allow it, bypassing restrictions that exist only within the published report. Test with the intended user's identity and administrator checking a report can't establish what a purchasing analyst can reach through another permitted route, especially when that analyst also belongs to groups granting broader workspace access. Semantic model security has a defined scope. Power BI. Row level security can restrict rows for users to whom it applies, but it doesn't impose the same restriction on independently accessible source tables or files elsewhere. Supplier separation needs to survive outside the report. If you publish a shared delivery data product for partner access, enforce each supplier's permitted scope through supported data access controls or separate secured outputs rather than relying on a report selection. Consider a supplier querying its open deliveries. It should receive only its permitted records, even if it requests another supplier's reference directly removes a report filter, or connects through a different interface you've authorized. Make those negative tests part of acceptance check denied requests as deliberately as successful ones, including whether quantities aggregated across suppliers disclose commercial information that individual row restrictions were intended to keep private partner entitlement needs a controlled source. Maintain Who may access which supplier sites and business records with an owner approving changes, rather than deriving access from a supplier name supplied inside an incoming document. Sensitive fields deserve separate treatment. A planner may need the expected quantity and arrival time without needing negotiated unit prices, rebate terms or bank details that happen to accompany the original purchasing extract. Publish only the fields required for the task. Restrict access to retained source documents more tightly where they contain additional commercial information. Because hiding a price column in a report doesn't remove it from the underlying payload. Credentials need protection outside the data model to store secrets in an approved secret store, such as Azure Key Vault, where the integration supports it, and prevent tokens or passwords from appearing in pipeline parameters, diagnostic output or support tickets. Rotation needs a tested owner and procedure. Verify how each connection obtains its replacement credential and how the previous credential is revoked without granting permanent access simply to avoid interruption during the change. Retention should distinguish evidence from access convenience agree how long original documents, prepared tables, exports and audit records must remain based on contractual obligations and applicable rules, rather than one blanket period for everything. Deletion needs to follow those copies, document the supported removal process and any backup or recovery retention constraints so the business understands when expired partner data stops being accessible and when retained recovery copies expire. Audit access is itself a permission decision. Logs can expose order references and commercial details, so limit who can inspect them while recording enough identity and access information to investigate disputed use through the services involved, recovery must preserve those same restrictions. A retained document copied into a support workspace still contains partner data, so the people and services handling failures need. Controlled access rather than an informal exemption because something broke a broken feed. Needs an operational response of its own. If the carrier connection fails overnight, the morning planner needs to know which shipment assessments remain usable and which now require confirmation before anyone relies on them. Monitor the path at several points. Check whether the source can be reached, whether expected inputs arrive, whether processing completes, and whether the resulting business assessment advances within the time its users require those checks. Describe different failures a receiving service can accept carrier updates successfully, while a failed transformation prevents those updates from reaching the shipment model, leaving collection healthy. But the planners answer increasingly stale. Measure progress, not just successful execution. A pipeline can finish without errors while repeatedly reading an old extract, so compare the source cut off and processed business records with the progress expected for that feed. Ingestion lag needs a defined measurement point. Track how long accepted inputs, wait before processing and how long completed transformations wait before their results become available to the supply assessment rather than reporting one unexplained delay. Source silence needs a baseline grounded in actual activity. A carrier might send nothing because no tracked shipments moved because its publishing service failed, or because your subscription stopped receiving notifications despite the carrier continuing to operate. Don't classify all three as a partner outage. Compare connection tests, subscription status where available, and the presence of active shipments that should produce evidence. Before deciding which support team needs to investigate the missing updates. A successful connection test narrows the investigation. It can establish that a service responds without establishing that its business data is current, so check a documented source watermark or relevant shipment record where the partner supports that inspection. Give the incident a specific affected scope. If one carrier account stops publishing while others continue, identify the shipments dependent on that account. Instead of declaring every transport assessment unavailable across the entire plant. The operating team needs a practical investigation route. Start with the last completed hand off, inspect the next expected output and follow the failure forward until someone can identify whether the missing progress sits inside or outside your platform. Recovery starts before the connection returns. Establish the last verified processing checkpoint and the affected interval, then determine which retained inputs or source records are needed to reconstruct the missing period without assuming the interruption. Lost nothing. Restore processing under controlled conditions. Run the affected inputs through the repaired path. Inspect failures separately and confirm that completed results reach the business model rather than stopping at a successful ingestion status. Reconciliation then tests whether recovery is complete, compare affected open shipments and their relevant quantities or milestones against a source query with a known scope, checking for missing changes as well as records processed incorrectly during the interruption. A cleared backlog isn't enough. Some changes may never have entered that backlog, so recovery needs evidence about the missing interval, as well as confirmation that everything already retained has now finished processing successfully. Keep the service in recovery until those checks pass. Assign someone authority to restore trusted status with recorded evidence that the affected records reconcile and the resulting assessments meet the operating agreement again. Meanwhile, the plant still needs an answer. Degraded mode should identify the affected material assessments, retain their last verified evidence, and state which decisions now require direct confirmation because automated updates can't support them. Make that mode usable during a shift. Give the planner a named contact route and a specific question to resolve, such as whether the seals remain at the depot or have been released for onward transport. Manual confirmation needs a place in the incident. Record capture who provided it, what they confirmed and when. While keeping its limited scope explicit. So confirmation about one shipment doesn't restore confidence in the entire failed feed. Escalate when confirmation can't arrive before the decision deadline. The operational owner then needs to choose under the agreed uncertainty rules, rather than wait indefinitely for the integration team to restore a connection that production can't wait for. Maintaining that readiness takes ongoing work. The freshness promise carries the cost of monitoring, investigation, reconciliation and manual cover during interruptions, not just the cost of moving records. While every connection works, you can price that promise before committing to it. For each decision, work backward from the action window and decide how much delay the business can tolerate between a source change and an updated assessment spend on the delay that could change the response. If a purchasing decision remains open until tomorrow afternoon, making its evidence available within seconds might cost more without changing what the buyer can usefully do. The urgent collection decision deserves a different budget, where a new depot update could determine whether purchasing books a vehicle before the collection cut off. Faster processing has a specific purpose you can explain and test that gives you different freshness targets within one service price those targets separately, including the slower workloads. Rather than choosing the fastest route for everything and discovering afterward that most decisions don't need it, fabric capacity planning should follow the work those targets create. Estimate what ingestion, transformation, event queries and reporting will consume together, then test their combined behavior instead of sizing each workload as though it runs alone. Concurrency can change the result. A purchasing load that finishes comfortably during a quiet test may take longer. When transformations and morning reporting compete for the same capacity during the plant's busiest planning period. I test that overlap deliberately, run representative data volumes with realistic report activity and event queries, then measure whether processing still meets its deadlines and whether users receive answers within an acceptable time. Average consumption won't explain every missed deadline. Examine bursts and competing work, because a capacity choice that handles a typical hour may still delay the specific assessment purchasing needs during its short approval window. Incremental loading deserves measurement, not automatic approval. Reading only change records can reduce work, but the extraction method and downstream transformations determine whether that smaller input actually avoids scanning or rewriting. Much larger tables follow the change through the full processing path. A small purchasing update provides little saving if every run rebuilds the complete supply table and recalculates unaffected records, simply because that's how the first version works. Partition choices need the same practical test. Organizing large tables by an appropriate date boundary may reduce scanning for some workloads, while excessive small partitions can add file management work without helping the queries people actually run. Use representative questions to judge the layout. Test a planners focused requirement lookup alongside broader purchasing analysis. Because a storage choice that speeds one query can leave another reading far more data than expected. Retention changes that workload over time estimate storage, and query behavior as history grows, separating frequently queried detail from older retained evidence while keeping each record accessible for the users. Its retention policy requires measure the cost of access as well as storage. Keeping older records cheaply helps only if the supported retrieval path can still answer an investigation within the time and processing budget the business accepts. The fabric bill is only part of the cost model. Depending on your arrangements, partner services may charge for API access or calls, while message handling, network transfer and intermediate storage can add costs outside fabric capacity. 01:07:22 Speaker: Duplicate data has a carrying cost to. Each extra copy can require storage, processing, permission checks and maintenance, so give every retained representation a stated use rather than copying entire data sets whenever another team needs a few fields. Partner onboarding also needs an explicit budget. Allow for obtaining sample documents, interpreting agreements, testing mappings, and coordinating changes with the supplier, including the time your own purchasing and integration staff spend. Getting that exchange accepted. Operational support belongs beside those delivery costs. Estimate the effort required to maintain connections and adapt to partner changes. Then assign a budget owner rather than assuming those hours will disappear into existing support arrangements. Compare designs against the same business requirement. The useful comparison is the full cost of meeting a stated decision deadline under realistic workloads, not the cheapest ingestion run or the fastest isolated query. I'd require that comparison before widening the commitment with the freshness, target workload and ongoing costs made explicit, the next delivery can stay small enough to test the complete decision path without financing every possible connection. First. For the first delivery, I'd keep the pump plant as the boundary. Select a small group of sealed suppliers whose deliveries support the same production area, and limit the pilot to deciding whether tomorrow's sequence needs changing because of a seal shortage. Choose suppliers that expose some variation without overwhelming the team, including one supplier with structured dispatch messages and another with less complete updates, lets you test the proposed service against different evidence within a manageable operating scope. Keep the response equally specific. The pilot should help the assigned planner decide whether to propose a sequence change before the afternoon planning cutoff, rather than attempt to support every possible purchasing and production intervention. Put the exclusions in the pilot agreement. Other plants, unrelated materials and decisions outside that planning window should stay outside this delivery. Even when someone points out that the same connection could eventually help them, then spend time with the planner during the existing process. Follow an actual review from the first stock. Check through the calls and spreadsheet updates, recording what the planner consults before reaching a decision or leaving a question unresolved. Capture what happens between the official steps. A warehouse call might establish that a recorded balance needs checking. While a note beside a spreadsheet row might explain why the planner doesn't trust a particular supplier's date. Ask what each call contributes to the decision. Record the question asked, who answers it, and where the answer goes. Because the pilot needs to preserve useful judgment rather than merely replace the places people enter information. Leave unanswered questions in the baseline. If nobody can establish whether a dispatch includes the required seal revision, record that unresolved gap. Instead of describing the manual process as though it always produces a complete answer, the spreadsheet deserves a careful reading to. Its formulas might be straightforward, but comments, color conventions, and manually excluded rows can reveal operating rules that haven't yet appeared in the proposed data product. Use that baseline to define the first deliverable for each production requirement in scope. The Prepared Fabric data product should connect the relevant purchase order line, shipment contents, eligible stock and production need within one Inspectable assessment. Make the planners work in question the entry point. Starting from tomorrow's affected production order, the planner should be able to follow the requirement to its proposed supply without searching several unrelated data sets or translating partner references manually. The product needs to carry unresolved relationships as well. Where shipment contents can't yet be attached confidently to an order line, show that missing connection alongside the assessment. Rather than presenting the affected requirement as fully evaluated. Build a review view before building an interruption. Give the pilot owners a way to inspect candidate exceptions and their supporting records with enough detail to compare the proposed answer against the decision, they would make themselves run that view in shadow mode first. The existing process continues to guide operations, while the new service produces assessments for the same review window without sending live shortage alerts into the planners normal work queue. Name the people who will validate those assessments, the production planner should judge whether the flagged requirement needs attention, while a buyer and warehouse representative should be available to check disputed supply statements and stock eligibility, review the cases while the operating context remains available. If the team waits until the end of the week, a quick phone confirmation or an unrecorded warehouse observation may be difficult to reconstruct accurately from memory. Record disagreements as specific questions, not general impressions. A planner rejecting a candidate exception should identify the missing fact or mistaken relationship, and the reviewer should distinguish a defect from a legitimate difference in judgment. Don't ask shadow operation to prove itself through a polished demonstration. Keep the existing checks running through ordinary planning reviews, including cases where the expected delivery changes in cases where the new service finds no shortage. That gives the pilot a concrete acceptance discussion before switching on live alerts. The named owners need to agree that the cases they've reviewed justify handing this particular decision path a place in daily operations. Expansion needs its own evidence. The next question isn't whether another plant wants the report, but whether the pilot has earned enough trust to support a broader operating commitment. I'd judge that commitment through decision performance, not report visits. A planner opening the report every morning tells you they consulted it, but doesn't establish whether the evidence helped them recognize a problem or respond in time. Coverage needs a denominator. The business recognizes. Measure how much of the agreed supplier to production flow. The service can assess and distinguish complete assessments from requirements where an essential connection or source remains unavailable. Don't average away the gaps that affect urgent work. Coverage across all open purchasing lines can look encouraging, while the requirements due during the next shift remain poorly represented, so report coverage against the decisions actually in scope. Freshness should show compliance with the agreed evidence. Age limits count assessments supported by sufficiently current inputs, and identify which source most often leaves an assessment outside its permitted age. Rather than reporting only an average refresh interval, match rate needs an equally explicit definition report the share of relevant records matched through approved relationships, separating automatic approved matches from unresolved candidates. So a high figure doesn't reward quietly accepting uncertain identities. Reconciliation gaps and quality backlogs reveal different weaknesses. Track unexplained quantity differences alongside unresolved defects, including their age and affected requirements. Because a small backlog can still contain the one issue preventing tomorrow's decision. Then measure the exceptions as decisions requiring attention. Precision means the share of raised exceptions reviewers judge warranted under the agreed rule and the evidence available when the system raised them. Outcome alone can't tell you whether an alert deserved attention. If the planner intervenes successfully and production continues, that doesn't make the warning false. So evaluation needs the original exposure and the response recorded against it. Missed cases require looking beyond the exception list. Compare actual planning problems and manual interventions with what the service detected, then identify cases it should have raised but didn't, including cases nobody initially recorded as shortages. Acknowledgement time measures whether responsibility reaches someone promptly measure from exception creation to explicit acceptance by an owner, while distinguishing that interval from the time spent investigating and approving a response after acceptance. Time left to act gives that speed operational meaning. Record the remaining window when the exception appears and when someone accepts it, because quick acknowledgement still achieves little. If the usable response window has already closed, I'd examine distributions rather than rely on averages, separate urgent cases from longer range cases, and inspect the slowest responses since a comfortable average can conceal the exceptions where the plant repeatedly loses its remaining options. Operational results belong in the review, with some restraint track material related disruption, expediting cost and delivery performance for the covered flow. But examine the other changes that could explain movement in those measures during the same period. A lower expediting bill doesn't establish that visibility improved different demand, fewer supplier problems, or a decision to accept later completion could reduce spending to. So inspect the cases behind the total before attributing the change. Delivery performance needs the same discipline separate supplier arrival performance from production completion and customer delivery. Then examine where an exception response plausibly influenced an outcome, rather than crediting the service for every improvement. Planar corrections provide evidence for improving the service when someone rejects an alert capture, whether the cause concerns an incorrect match, a faulty rule, missing evidence or a difference in the operating judgment being applied, rejection shouldn't automatically change the rule. Compare the planner's explanation with the evidence an agreed decision boundary, then determine whether the system needs correction or whether the case exposes an unresolved policy question. Route confirmed defects back to their specific owners. A wrong part relationship needs a mapping correction, while an inappropriate trigger needs a rule change, with each proposed change linked to the rejected cases that justify it. Check those changes against previously reviewed cases. Confirm that the repair addresses the original defect without hiding other genuine exposures, then watch whether the same rejection reason returns during subsequent planning reviews after release. These measures should expose where confidence remains unearned. Before accepting the results, I deliberately challenged the service with a case that strains its assumptions and check whether its exception still gives the planner a defensible decision. Let's challenge the pump plant case with a partial delivery. In this hypothetical test, the suppliers dispatch notice covers only part of the outstanding seal order, while the planners next review still needs an answer about tomorrow's assembly sequence. The notice arrives through the agreed EDI connection intake, retains the document and its prepared records. Enter fabric with references connecting the declared seal quantity to the supplier Shipment and purchase order line. Then the supplier sends the same notice again. Its document identity and contents match the accepted submission, so processing recognizes another delivery of the same declaration and prevents that quantity from appearing twice in the shipment model. The retained copy still records that second arrival for the planners assessment, though, one declared shipment quantity remains attached to one portion of the purchasing obligation, leaving the unshipped balance separate rather than making the whole line appear dispatched. Next, the carrier API supplies a revised arrival estimate. It places the shipment at the transfer depot and predicts plant arrival after the first assembly operation needs its seals, changing the expected coverage for that requirement. The purchasing commitment hasn't changed with that prediction. The assessment now carries the accepted purchasing date beside the carrier's later expectation, allowing the planner to see precisely which evidence creates the exposure without interpreting the difference as a revised agreement. The inventory calculation then evaluates the stock already recorded at the plant. It excludes the batch awaiting inspection from usable supply, and preserves the seals reserved for other work, rather than assuming those quantities can cover the first assembly order. That leaves a smaller eligible balance for the affected demand. Applying the remaining requirements in their agreed allocation order shows that the early operation lacks coverage, while a later operation could still receive seals after the expected delivery. The exception identifies that early requirement, not the entire purchasing line. Its supporting assessment connects the uncovered quantity to the partial shipment and remaining usable stock, with the carrier estimate explaining why expected incoming supply no longer covers the operation's need time. Now the assigned planner receives a case they can investigate. They accept responsibility and review the linked evidence, checking that the shortage concerns the quantity still needed rather than seals already consumed or supply belonging to another delivery. For this test, the planner proposes running another pump order first. That replacement order doesn't require the delayed seal, but the proposal still goes through the scheduling check to establish whether its resources and downstream operations fit. The calculation finds a workable sequence under the stated assumptions. It moves the seal dependent assembly, later, places the replacement work in the earlier slot, and checks the displaced operations. Rather than judging success from the assembly line alone, one assumption needs particular attention before approval, the delayed seals must become usable before the revised assembly slot, so the proposed response remains conditional on that availability time rather than on the carrier reaching the gate. The planner submits that exact sequence change for authorization. The production manager reviews the affected orders and the conditional supply assumption, then approves the proposed plan version rather than granting permission for unspecified changes throughout tomorrow's shift, execution checks the current planning records before applying the change. In this hypothetical run, no affected operation has started and the relevant allocation still match the approved assumptions, so the supported planning interface accepts the revised sequence. The workflow records the returned transaction reference. Approval alone doesn't close the shortage case because the seals remain outstanding, and the revised operation still depends on their eventual receipt and release for use. The planner can now distinguish completed action from remaining exposure. The sequence change has been executed, while the exception retains the supply condition that still needs confirmation before the delayed assembly, work can proceed as planned. That's a more demanding result than a successful document load. The test follows one declared quantity through a duplicate submission. A partial order allocation. A changed arrival expectation and an approved response without losing. Which evidence supports each step. Yet the successful path still has a boundary. Every connection in this test could operate correctly. While the assessment remains limited by what the participating businesses actually report. Which leaves us with the question of what this architecture can reasonably claim to know. A complete record of reported activity still leaves unreported activity outside your knowledge. That's the boundary I'd put in writing when the business accepts the service, because successful integration can otherwise create confidence that extends beyond the evidence available. Supplier capacity is one example. Unless your agreement provides dependable capacity information, an accepted delivery promise doesn't reveal whether the supplier has secured enough equipment, time or labor to fulfill it alongside other customers orders. Even a capacity figure needs a defined scope. A supplier might report available hours for one production area without exposing the tooling constraint that governs your particular seal, leaving the figure unsuitable for judging that commitment independently. A subcontractor creates a different blind spot. If a supplier depends on an outside process and doesn't report its progress, your assessment can't establish whether that process threatens delivery before the supplier acknowledges a problem, treat that exposure as unknown, not as a confirmed delay. The service can identify the absence of upstream evidence, but it shouldn't manufacture a reassuring status or infer a disruption simply because direct observation isn't available. Transport coverage needs an equally honest boundary. If a partner changes carriers during the journey without supplying the onward reference, the final leg can fall outside your observed coverage even while earlier milestones remain complete. That gap belongs to the particular journey. Adding a carrier connection doesn't establish coverage for every service that carrier operates, so acceptance should identify which accounts, routes, and handovers the connection can actually represent. I'd preserve an evidence classification throughout the assessment, a supplier promise states an intention. A verified event records an occurrence within its stated verification scope, and a calculated estimate expresses an expectation derived from identified inputs. Verification also needs a named method. A collection scan might verify that a handling unit entered the carrier's custody under its process, without verifying the contents or condition of every package within that unit. An estimate carries a different responsibility. Whoever maintains the calculation needs to define its inputs and permitted use, while the assessment keeps that output distinguishable from something a business partner committed to or physically observed, those distinctions should remain visible after aggregation. If an availability assessment combines observed stock with promised supply and estimated handling time, its conclusion inherits those dependencies rather than becoming verified merely because the calculation completed successfully. Fabric supports that analytical work. It doesn't assume operational authority. Its place here is to bring evidence into a usable analytical structure, connect the relevant business relationships, and produce assessments whose basis remains open to inspection. The operational owners still control their records. Purchasing governs accepted supply commitments. The relevant stock processes, governance, inventory transactions and specialist planning retains responsibility for testing the constraints represented in its scheduling model. I'd make those boundaries part of expansion approval before another plant joins require evidence that it's supplied records reconcile at the level needed for its decisions, rather than assuming the first plant's acceptance transfers automatically. Working ownership needs a separate test. Ask the incoming plant to demonstrate who resolves a disputed assessment and who takes responsibility when an exception crosses departmental boundaries using an actual operating review rather than an organization chart. Recovery deserves its own acceptance evidence. Have the expanded service recover from an interrupted feed and demonstrate that restored results remain trustworthy, including any new partner behavior that differs from the connections already in operation. A past test should authorize a defined scope. Adding another supplier or material family can introduce different restrictions, so expansion approval needs to specify what the evidence supports rather than grant confidence to everything connected afterward. Failed gates should limit the commitment. A connection can remain under evaluation without becoming an operational dependency, allowing the team to resolve its shortcomings before planners are expected to rely on its answers. The final boundary is time. Even with accepted data assigned responsibility and demonstrated recovery, the service only supports a particular intervention if its evidence arrives before that intervention stops being practical for the plant, trustworthy evidence needs to reach the planner, while a response remains possible. If the first dependable shortage alert arrives after the seals run out, production stays stopped. However carefully, the system explains the cause and documents its sources. Where does your own supplier to production data path lose that opportunity? I'd like to compare the hardest gap you're working through, especially where the evidence exists, but reaches the person responsible after their workable response window has closed.