Power Platform for Manufacturing: Shop Floor Apps Operators Actually Use

iFAKT - Power Platform for Manufacturing - Shop Floor Apps Operators Actually Use 00:00:00 Speaker: Imagine a shift handover where the operator has already completed the app form, but the production record still hasn't appeared and a paper note sits beside the machine. The next shift enters it again. Now you've got repeated entry, an unclear status, and another reason for operators to keep paper close, even though the app appears to work as designed. What makes that app worth using during a busy shift? Let's follow one production issue from operator input through offline use and system integration, then into the long term ownership that decides who handles the report when something doesn't reach its destination. I'd start with the job, not the app requirements. Before you choose power apps or sketch a form, ask what someone needs to finish while they're standing beside the line, with production still demanding their attention. Report a defect sounds clear until you ask the operator what that means for them. The job might include recording what they found and knowing whether someone will deal with it, rather than simply sending a description into a system. A material request has a different finish line. The operator needs the right material at the right place before the current supply runs out, so a submitted request only covers part of the work. Recording a check deserves the same care. You need to understand whether the person is confirming an observation, recording a measurement, or raising a concern that needs a response before they can move on. Those tasks might share a device, but they don't share the same purpose. If you start with a generic form, you can miss the reason someone picked up the tablet and what they need from it before putting it down. Then there's the gap between desk work and line work. A person sitting at a laptop can usually pause, read a long label, and correct a mistake without having to keep an eye on material moving past them. That isn't the setting we're designing for. Your operator might wear gloves, struggle to hear a colleague over the line, and reach for a shared device during a short gap between physical tasks. Even finding the device takes time. If the tablet sits somewhere convenient for charging, but awkward for the work, the operator has to leave the task, find it, and return before entering anything. That effort belongs in your assessment of the app. Counting taps from the moment a form opens, ignores the walk to the device, and the work someone has to hold in their head while they use it. I wouldn't treat paper as proof that people resist change. A note beside the machine may stay useful because it sits exactly where the next person needs it, and nobody needs to find a free tablet to read it. The spreadsheet deserves a closer look to. Someone may have added a column because the official process never answered a question that matters during a shift, such as whether a request still needs attention. Those additions give you evidence about unmet needs. Ask what people write in the margins, which cells they keep checking, and what information they copy elsewhere because they can't afford to lose track of it. There's often a practical reason behind the extra work. You don't have to preserve every habit, but you need to understand what each habit protects before you ask someone to give it up for an app. Here's the distinction I'd use when judging the first idea faster. Data entry means someone records information with less effort. A completed production task means the work reaches the point where that person can safely and confidently move on. You can improve one without improving the other. An operator might finish a new form much faster than the paper version, and still spend the rest of the shift asking whether anyone has acted on it. So I'd ask a plain question before discussing the build. When this person puts the device down, what should they know and what should they no longer need to chase through a separate conversation or handwritten note? Keep the answer tied to one task. Improve shop flow Shopfloor communication leaves too much room for a form that collects plenty of information, but doesn't help anyone finish a specific piece of work. Let's use a hypothetical packaging line to make that concrete. We'll stay with one operator who finds damaged material during a work order, because that gives us a clear job to follow rather than a collection of unrelated app ideas. The operator notices torn edges on a bundle of packaging blanks in this hypothetical plant. Those blanks are feeding an active work order, and the damage raises a question about whether more material from the same batch could be affected. The first question concerns the batch the operator needs to connect the damaged material to the batch actually beside the line, rather than assume it matches whichever batch the work order originally called for. A replacement pallet might have arrived partway through the shift. If the report names the planned batch instead of the material in use, quality could investigate the wrong stock while the damaged material remains unaccounted for. Then the operator needs to describe the damage. A useful report explains what they found and where they found it, with enough detail for someone else to understand the concern without first walking over to ask. There's a difference between an observation and a judgment. Several blanks have torn edges, records what the operator can confirm while the whole batch is unusable, reaches a decision that may belong to someone else. The operator also needs help, not just a place to write. Depending on the plant's procedure, that might mean contacting quality or the shift supervisor with a clear reason for the request and a location they can act on. Meanwhile, the line still needs a permitted next step. The operator needs to know which approved instruction applies while they wait, including whether they should hold the affected material or take another action defined by the plant. We shouldn't invent that instruction inside the reporting process. The plant needs to define who can decide what happens to the material and what the operator may do before that decision reaches them. Several responsibilities now sit around the same incident. The operator records the finding, but quality might need to inspect the material and decide whether to reject it, accept it, or ask for further checks. An inventory update answers a different question. If material leaves usable stock, someone needs to record the approved quantity and stock change through the plant's established process rather than infer it from the defect description. Production has its own response. To manage, a supervisor may need to arrange replacement material or adjust the immediate work, even while the final decision about the damaged batch remains with quality. Those actions can finish at different times. Replacement material might reach the line before quality completes the investigation, so production resumed doesn't necessarily mean the defect report can close or the inventory record is correct. Now put the tablet near a weak wireless spot. The operator enters the batch and damage description, presses submit and waits. While the app gives no clear indication of whether anyone received the report. After another pause, they press submit again. We now have an uncertain incident count as well as damaged material, because the operator can't tell whether they're repeating a failed attempt or creating a second report. Move the tablet somewhere with better coverage and another problem remains the shift supervisor is dealing with a stoppage elsewhere, so a report can reach its destination without reaching someone who's available to respond. Who should the operator approach while the supervisor is unavailable? Unless the plant has settled that question. The person beside the line still has to find help while keeping track of material that needs attention. The uncertainty spreads when another shift takes over. One person remembers reporting the damage, another remembers arranging replacement stock, and neither can confirm whether quality decided what to do with the remaining batch. Nobody needs to behave carelessly for this to happen. Each person can complete their own part, yet leave a gap between the initial observation and the decisions needed to settle the incident. Consider what a digital copy of the existing form would capture. It might collect the batch number, damage description and operator's name perfectly while leaving unanswered who responds when the supervisor can't, and what counts as a finished report. The form captures only part of this incident. Before we copy its fields into an app, we need to examine the work around it, including the decisions and handoffs that the paper never explains. Put the existing form on the table with the people who use it for each field. Ask which decision depends on the answer, who needs that answer, and whether anyone checks it before the incident can move forward. Some fields will earn their place straight away. A material identifier or an observed quantity may support an investigation, while a department code might exist only because someone once sorted a monthly report by department, don't delete a field just because nobody remembers its purpose. Ask the process owner to check whether it supports a record requirement or an obligation that isn't obvious to the people completing the form today. Other fields may belong later in the work. Asking the operator for a final cause at the moment they discover damage invites a guess when the investigation should supply that answer after someone examines the evidence. I'd separate observed facts from information added during follow up that lets you keep the evidence the plant needs without forcing the first person reporting a problem to answer questions they can't reasonably settle at that moment. Next, trace the work using an actual completed case if one exists. Ask people to reconstruct each action from the first observation to the point where the plant accepted the resolution, including the steps nobody wrote on the form. Pay particular attention to the gaps between actions. A report might spend most of its life waiting for someone to review it, clarify a quantity, or confirm that a requested correction actually reached the right person. Right? Those weights into the process description. Center quality doesn't explain whether someone checks incoming reports throughout the shift, accepts responsibility for each one, or notices when a report arrives without enough evidence. Every handoff needs a receiving person or role. The sender needs a clear way to know that responsibility has transferred, rather than assuming the next team has accepted the work because a message reached their department. That discussion often changes how you interpret repeated entry. Suppose a supervisor copies a defect report into a separate register because nobody has agreed who maintains the incident record. Once the investigation moves beyond the line, the supervisor is protecting a responsibility they still carry. Removing their register without assigning that responsibility elsewhere leaves the same uncertainty. So another list will probably appear even if the new app prevents duplicate forms. Ask what makes the second entry feel necessary. You might discover that one team needs evidence of receipt, while another needs a record of unresolved work that remains available after the original reporter leaves. Solve that ownership problem before policing the extra record agree which record people should follow, who keeps it current and how the next person accepts responsibility when the incident moves into their part of the process. For the first release, I'd keep the scope narrow. Take this defect reporting workflow from initial observation through its agreed resolution, rather than collecting several unrelated forms and calling the collection a shop floor app. Narrow doesn't mean stopping at the easiest handoff. If the pilot ends when the operator submits the report, you haven't tested whether the revised workflow removes the uncertainty that prompted people to keep their own records. Define completion with the people responsible for accepting it. For this hypothetical plant, that could mean the required decision is recorded, the resulting actions are confirmed, and no assigned work remains open without an agreed reason. Check that definition against a case that needs no further action. Someone still needs authority to accept that outcome and record why. So an investigation doesn't remain open simply because there isn't a corrective task to finish. Then walk through the proposed process without building anything. Have each person explain what they receive, what they contribute, and what allows them to pass responsibility onward while another person challenges any step that relies on an assumption. Any disagreement now gives you useful design work. It's much cheaper to settle who accepts a resolution during that conversation than to discover after launch that different teams interpret the app's completion state in different ways. That leaves a practical question about where each action belongs. Once you've agreed the workflow, you need to decide which parts the shop floor app should handle and which parts must remain with the plant's core production systems. I'd give every system a specific responsibility in that workflow. Otherwise, a convenient new app can gradually take over decisions that another system already manages without anyone deliberately choosing to move those decisions or their consequences. Start with enterprise resource planning or ERP. Depending on your implementation, that's where the business maintains production orders, material planning records, inventory transactions, and the financial effects of consuming or rejecting stock during production. The system name alone doesn't settle ownership. Your plant might record a material movement directly in ERP, or another approved system might initiate that movement and pass the result into ERP through an established process for our damaged packaging material. Ask where stock start is actually changes. The answer needs to name the system and the accepted transaction, because recording a defect beside the line doesn't automatically change whether that material remains available for another order. Then consider the manufacturing execution system or mess within its configured scope. It can manage production execution, track material, and work in progress, and enforce rules about which production steps people can complete under specific conditions. That scope varies between plants, even within the same business. One Mess implementation might control material consumption and quality checks, while another mainly records progress and leaves more decisions to separate systems or established plant procedures. You need to inspect the implementation, not assume the boundary. If your mess already prevents consumption of material with a particular status, a separate app shouldn't create an alternative route that lets someone bypass that restriction. Power apps can provide a focused way into this existing process. In our scenario, that could mean giving the operator a simpler way to initiate the approved defect workflow. While the relevant production system retains responsibility for its own records and rules. I think that's a useful role for a shop floor app. You shape the interaction around the task someone needs to perform while keeping the business meaning of that action consistent with the systems responsible for accepting it. The boundary needs to survive a request for one more button. If someone asks to add release material beside report damage, you need to establish whether that action belongs in this app or in an existing controlled workflow. Sometimes the best answer is already inside your mess before building. Ask the team responsible for it to demonstrate how its current functions handle the task, including any options your plant hasn't configured or put into use. Judge that demonstration against the operator's actual work. A function buried in an awkward sequence may still need improvement, but a configured task page or supported adjustment might solve the problem without creating another application to maintain. Next, examine the extension routes the vendor supports. You might find a supported way to simplify the existing interaction at a task specific entry point, or connect an external app without recreating production logic outside the Ms.. A supported extension still deserves a practical review. Ask what happens when the vendor updates the system, which changes remain supported, and whether the extension preserves the checks that the standard workflow applies to the same action. Then compare a separate PowerApps built on those same terms. Its strength may be a tailored interaction across existing system boundaries, especially when the operator's task doesn't fit neatly inside the interface of any one system. Convenience alone won't justify moving production rules into the app. If the build needs to reproduce a large part of the Ms. just to complete one task, I'd reconsider whether we've chosen the right place for that work. I document the decision in plain language before approving development for the defect task, name, what the app collects, what action it requests, which system accepts that action, and where the operator receives the accepted production result. Include the reason for choosing this route over the alternatives that gives the next architect or plant engineer something firmer than we already knew. Power apps, especially when another department later asks to extend the same application. There's still a separate decision after you've assigned those responsibilities. A task can sit outside ERP and Mez and still demand operating conditions that make power apps a poor fit, so we need to test the platform against the work itself. A useful starting point is work that can tolerate a short delay. Defect capture can fit when the operator records an observation and requests action, provided the plant has a separate approved way to handle any immediate risk. Material requests are another candidate, but timing changes the assessment. Requesting a replacement pallet while enough stock remains gives you a different problem from calling for material when the next missed delivery will stop the line maintenance intake can also suit a task focused app. An operator can describe a leak or unusual noise and request inspection, while the maintenance team follows its approved process for assessing urgency and planning the work shift checks need the same distinction between recording and responding. A routine condition check might fit well, but a check that determines whether equipment can operate demands a closer review of the consequence when the result arrives late, I'd assess each candidate against its worst credible working conditions. Ask how long the person can wait for a response, what equipment they'll use, and whether the task must continue when the connection becomes unreliable during production. Response time needs a business, meaning not just a performance target. Waiting several seconds for a maintenance request number might be acceptable while waiting the same time for confirmation before a time sensitive physical action could make the proposed workflow unsuitable. Device support needs proof on the equipment you intend to deploy. Check the app type and required controls against the actual operating system, runtime scanner, and peripheral hardware. Rather than assuming that a successful laptop demonstration proves plant readiness. Connection needs can rule out an otherwise sensible candidate. If the task depends on consulting current server data before every action, assess whether the available connection can support that requirement wherever operators need to perform the work. Volume deserves a workload test rather than a guess. Consider the number of submissions during a shift. Change the number of simultaneous users and the calls each task generates against connected services under your proposed design. Average traffic can hide the difficult part of that workload. A shift check that everyone completes at roughly the same time creates a different demand from occasional defect reports. Even if both produce similar daily record counts. Then ask what failure costs the plant. A delayed housekeeping request might create follow up work, while a missing result used to authorize production could affect material, equipment or people. Before anyone notices the record hasn't arrived. That gives you a firm boundary around machine control. Keep time sensitive control functions and safety functions within approved industrial systems with the required response, behavior and safeguards assessed by the engineers responsible for those systems. An app can still help someone request engineering attention, but a request to inspect a guard fault must leave the protective function intact, and no app response should substitute for the approved conditions that permit equipment to run. Treat production release steps as a separate fit assessment before adding a release action. Establish what evidence must exist, who may authorize it and which requirements apply to the record and the act of authorization. 00:17:00 Speaker: Regulated work needs review from the people accountable for compliance. Depending on the applicable requirements and intended use, they may need documented validation, controlled records, and specific electronic signature controls before accepting the application for that task. Assigned in user doesn't automatically satisfy an electronic signature requirement, you need to establish how the signature connects to the exact record, what the person confirms, and which controls your applicable requirements. Demand for that action. The answer may be a narrower scope. You could collect the initial observation through Power Apps, while keeping the regulated decision in an established system. If that division preserves the required evidence and accepted process, platform fit is a decision about the whole task. I'd record the operating assumptions and the consequences of failure beside the proposed use, so approval doesn't quietly extend to a more demanding task added later. Now take those assumptions back to the people doing the work. A candidate can pass a technical review and still fail in practice, because the review assumes operators have more time, access or freedom to pause than their shifts allow. Spend time beside the task while production runs. Arrange the visit with the shift lead. Explain what you're studying and let the operator know you're checking the proposed workflow rather than grading their performance. Your presence can change how people work. Someone may follow the written procedure more closely while you stand nearby, so ask whether the task usually takes this route when nobody from the project team is watching. Visit more than the day shift in our hypothetical packaging plant. A night operator might depend on different people for help. While the project team has only observed reporting when every support desk has someone available. Watch an experienced operator and someone still learning the station. The experienced person may skip an explanation because they know it by heart. While a temporary worker needs that same explanation before they can choose the right response. Include the supervisor, but don't let them answer every question. Give operators room to describe what they actually do. Then speak with the supervisor separately about what arrives from the line and what they need to understand it. Small workarounds deserve careful questions. If someone writes a batch number on paper before approaching the device, ask when they first need that number and what forces them to carry it between those moments. A note on a glove can tell you something different. The person might be keeping a reminder close while both hands stay occupied. So ask what the note means rather than assuming it's another version of the formal record. Treat shared login habits as evidence to investigate, not endorse. If people avoid changing users because they expect the next task to arrive immediately. Record that constraint without accepting the habit as the future design. Don't turn the observation into a disciplinary interview. You need an honest account of where the proposed task clashes with the shift, and people won't explain those clashes if each answer sounds like evidence against them. Bring operators into the draft. While choices remain open for the damaged packaging report, ask them to work through the proposed fields and explain which answers they can provide at discovery, and which require another person. Ask them to challenge the order to. A developer might group fields by how the data will be stored, while an operator naturally follows the sequence in which they find the label, inspect the damage and seek help. Use a rough draft to test that sequence. Let the person describe their next action before you explain your intended route. Because an explanation from the designer can hide a step that wouldn't make sense during normal work. Error wording needs that same direct review. Give the operator a sample message about a batch they can't select, then ask what they think it means and what they try next. Without coaching, a technically correct message can still send someone the wrong way. If invalid, batch leads them to copy a different number just to continue. The wording hasn't explained the problem or supported the action you expected them to take. Ask about recovery as part of the task. Present an interrupted report or a mistaken entry and have the operator explain how they'd establish what remains unfinished before they decide whether to continue or start again. Avoid asking only whether people like the app. That question invites a polite answer, especially when the person asking has spent weeks building it, and clearly hopes the trial will confirm their design choices. Give feedback a specific job instead, ask the participant to report the damaged blanks using a sample case, then note where they pause. Ask for help or reach for information outside the proposed task. Keep your prompts neutral while they work. What are you trying to do now? Tells you more than. Wouldn't you choose this option? Because the second question supplies the answer you're supposed to be testing. Compare observations across shifts before accepting a change. A request from one experienced operator may solve their own difficulty, but leave a temporary worker guessing. So take the revised draft back to both and repeat the task. Record what changed and the reason behind it. Those notes let you carry the operator's needs into interaction design, where the device and the sequence of actions must work in the conditions you've just observed. The first physical test is whether someone can select the intended control, give touch targets enough space that an operator wearing the required gloves can choose one without brushing the next, especially when the device sits at an awkward angle. Test with the gloves. People actually wear a control that works with thin, disposable gloves may behave differently with thicker protective gloves, and changing the app layout won't fix a touch screen that can't detect the touch text needs testing from the working position. Place the device where it will sit during production, then check whether someone can read the task without leaning forward, lifting the tablet, or changing their stance. Keep labels close to the information they describe. If a field asks for the amount of damage material, state the unit beside it so someone doesn't have to remember whether the form expects bundles or individual blanks. Typing should earn its place in the task. Use clear choices for known answers and leave free text for observations that genuinely need it. Rather than asking someone to type details, the task can already supply errors. Need to explain a workable correction? Enter a whole number of bundles. Give someone a specific action while a technical validation message leaves them guessing whether the problem concerns their entry or the app. Hardware choices belong beside these design decisions. A handheld tablet might suit occasional reporting, but a fixed amount could work better where the person needs both hands free immediately before and after using the app. Check the amount through the full physical task it needs to stay reachable without blocking access, creating an awkward reach, or placing the device where normal work exposes it to knocks and material spills. Cleaning rules can change which equipment you choose. Ask the plant which cleaning agents and methods apply, then check the device, case, mount and accessories against those requirements before settling on the setup. Battery life needs a working routine to test the intended shift pattern with the actual device settings and accessories, and decide where charging happens without leaving the station dependent on a tablet. Nobody remembered to charge the scanner needs can affect the whole arrangement. If the task requires a scanner, check whether the operator can reach and use it from the working position without juggling the tablet or removing required protective equipment. Interruptions deserve equally deliberate design. In our damaged material task, someone might start describing torn blanks, step away to help a colleague, then return after the physical situation around the line has changed. Preserve the unfinished entry where the design supports it. Keep enough context with that draft to show what the person started, while clearly distinguishing unfinished work from a report they've already submitted for someone else to handle. Returning should include a deliberate check before the operator continues, present the task context and ask them to confirm it still applies, rather than dropping them into the last empty field as though nothing changed. Make correction possible without starting everything again. If the material or situation has changed during the interruption, the person needs a clear way to revise or discard the draft without accidentally sending the earlier details. Keep that check proportionate to the risk. A long confirmation ritual encourages automatic tapping, so ask people to verify the details that could change the meaning of the report rather than approve every field again. Status cues need more than a change of color. Pair color with plain words and where useful, distinct symbols so someone can tell whether a draft needs attention without having to distinguish a red marker from a green one. Use terms the plant staff understand consistently test translated labels and messages inside the actual task. Because a word that seems correct in isolation can carry a different meaning when someone applies it to material beside a line. Leave room for different text lengths. A translated label shouldn't lose the part that explains the action, and enlarging text shouldn't hide the control. Someone needs to correct an entry or leave the task. Easy input still leaves one question. Someone can complete a clear, comfortable form without a single typing error and still attach the report to the wrong work. So the next design decision concerns identification. A scan should narrow the choice, not settle every question for our packaging operator. Scanning a machine label could bring up the work associated with that machine, rather than opening a search across the whole plant. The next choice should follow from that machine. If several work orders remain relevant, let the operator choose from that smaller set with enough detail to distinguish current production from preparation for the next run. Keep the distinction clear when two orders share a product, an order number alone might mean little beside the line, so include a recognizable product description and the operation the operator is trying to report against. Material identification needs its own check. After the operator scans the packaging label, the app should establish whether that label identifies a material type, a particular batch, or something else, such as a pallet. Those aren't interchangeable answers. A code that identifies the packaging design may help select the material, but it doesn't establish which batch supplied the damage blanks the operator is reporting. Ask what the label actually proves, where the available code doesn't contain or resolve to a batch. Guide the operator to select or enter that missing detail instead of treating the scan as complete identification. Filtered selection provides a practical alternative. When scanning fails, someone should be able to find the machine work order material and batch through a constrained search without scrolling through unrelated records or guessing an exact internal code. Keep each filter tied to a defensible relationship. For example, selecting the work order could narrow the material choices to those expected or recorded for that work, while allowing an agreed route for reporting an unexpected material device location can reduce the effort further. A tablet assigned to the packaging line can suggest that line when the task opens, provided the app describes it as a suggestion rather than an established fact. A move tablet can carry the wrong assumption with it. If someone borrows the device for another station, the operator needs to confirm or change the suggested machine before that context attaches to the report. Ask for confirmation where a mistake changes the report's meaning. In this case, confirming the machine and current work order together gives the operator a chance to catch a borrowed device or an order change before selecting material, then test a scan that succeeds technically but identifies the wrong thing. Present a readable label from a nearby pallet and check whether the app catches the mismatch or quietly accepts a batch unrelated to the selected work. A readable barcode isn't proof of the right context. Your test should include a label left on an empty container, because the code can resolve perfectly, while the material now beside that container comes from somewhere else. Try a work order that no longer applies to. Suppose the operator scans an order sheet left at the station after a changeover, and the app still recognizes its number. Even though another order now occupies the line. Recognition should lead to an explanation, not automatic acceptance. The app needs an agreed response to that situation, such as asking the operator to choose the current order or use a controlled route to report against earlier work. Defaults should come from records the plant has agreed to trust. If the app proposes a batch from a recorded material assignment, explain that basis briefly so the operator can distinguish a recorded assignment from a guess based on the last report. Make a wrong default possible to correct. Give the operator a defined way to select another permitted record or request a correction when the right record isn't available, rather than encouraging a substitute that merely passes validation. Check the effect of each correction on later choices. When someone changes the work order material and batch selections that depended on the earlier order. Need another check rather than remaining in place because those fields already contain answers, that behavior depends on more than a search box to narrow choices correctly and revisit them. When context changes, the app needs explicit relationships between the machine, the work order, and the material records it presents. Those relationships determine which choices the app can safely suggest. Before adding more forms, we need to define how those records connect. So a convenient default has a clear basis, and a correction doesn't leave the report internally inconsistent. Give each relationship a meaning beyond these records belong together. A work order can run across several assets, and an asset can handle several orders over time. So the relationship needs to describe the work and when it applies, start with the physical place the plant contains the packaging line, while individual assets belong to that line for a defined period rather than through an assignment everyone assumes will remain unchanged forever. Work orders describe activity within that setting for our defect report record, which operation connects the order to the asset. So the report refers to the work underway when someone found the damaged material. Material lots connect through actual use or assignment. A lot may supply more than one order, and an order may consume more than one lot. So neither relationship should imply a permanent one to one match. The defect report describes an observation at a particular time. Attach it to the relevant lot and production context without implying that every order using that lot contains damaged material. Because that conclusion needs evidence beyond the original observation. Keep uncertainty visible in those relationships. If the operator can identify the material but can't confirm its lot, the report should preserve that distinction. Rather than attach a convenient lot number that turns an unknown into a false fact, identity needs a separate decision from description. A line name can change after a plant reorganization, and an asset label can change during refurbishment, while earlier reports still need to refer to the same physical equipment, use a stable identifier for that continuing identity. Keep the readable name and physical label beside it as separate values. So changing what people call the asset doesn't break its connection to earlier production records. System specific codes need their source attached. An asset code from one plant's maintenance system might match a different asset code elsewhere, so the code alone can't establish which physical asset the report concerns. Maintain an explicit mapping between those identities. Your shared model can connect its asset identifier to the relevant source system record, while retaining the source system and plant context needed to interpret that reference correctly. Status words deserve equally careful definitions. I'd ask the people responsible for the workflow to agree what evidence permits each state, because the same word can otherwise describe different events to different teams. Reported could mean the incident record has entered the agreed reporting process. Acknowledged should require a responsible person or team to accept the report for attention, rather than merely confirm that a message reached an inbox. Nobody has checked, rejected, needs an object and a reason. Rejecting a report because it concerns the wrong lot differs from rejecting the material after inspection. So those outcomes belong to different records or clearly distinguished status fields resolved should describe the incidence agreed completion conditions posted should identify an accepted transaction in the named source system with its transaction reference, rather than become a loose substitute for any action someone considers finished one status field may not cover those meanings. The incident can remain under investigation while an approved stock transaction reaches its posted state. So preserve those separate facts instead of forcing both into a single sequence, assign authority to each record and field. The app might own the operator's observation, while another system owns the work order description, and the people maintaining the shared model need to document that boundary. Corrections should leave a readable history if someone changes the affected quantity after inspection, retain the earlier value alongside who changed it when they changed it, and the reason for replacing that value distinguished the original observation from later findings. A reviewer should be able to establish what the operator knew at discovery without treating a later investigation result as information. The operator supplied in the first report links back to source records. Make that history traceable, retain durable source references as well as any navigation link, because a changed address or application route shouldn't erase the connection to the production record behind the report. Now we've defined what the app's records mean. Dataverse becomes a candidate for holding those records and their relationships, but its role follows the ownership decisions we've just established rather than deciding those responsibilities for the plant. Give Dataverse a defined part of the defect workflow. It can hold the report and its supporting app records, with tables that separate the initial submission from evidence and follow up information added during review. Build those tables around the records people need to manage. A photograph, for example, can belong to a report through a relationship rather than sit in an unrelated folder whose connection depends on someone remembering a file name. Relationships also help you control what happens when records change. Decide whether removing a draft should remove its attached evidence, and whether deleting a submitted report should be blocked because the plant still needs that. Record. Permissions belong in Dataverse, not just in the app interface. Security roles let you control access to tables and records, so an operator's ability to create a report doesn't automatically grant permission to delete reports or alter protected review information. Test those permissions using real role combinations. Someone with several assigned roles may receive broader access than you intended, because restricting one role doesn't cancel access granted through another role assigned to that person. Auditing needs explicit configuration and a retention decision. Enable it at the required environment, table and column levels, then check whether the resulting history captures the changes your process owner expects to investigate later. An audit setting isn't a complete records policy. You still need to decide which information must remain available, who can review the history and how much storage that history will consume over the app's working life. Keep copied reference data visibly separate from app owned data. The defect description belongs to this application, while a material description copied from ERP remains a local representation of information maintained under another system's authority, that distinction should affect editing rights. If someone spots an incorrect material description, the app needs an agreed correction route rather than letting them edit a local copy that the next refresh silently replaces. 00:33:59 Speaker: Copy only what the task needs for each reference table document, why the copy exists, which source supplies it, and which attributes the app may use without treating those attributes as locally maintained production records. Rules in the form help people enter sensible information required fields and clear input checks reduce mistakes while someone works, but they don't protect the record against every other route that can write to the same table. Protect important constraints on the server as well. Where supported Dataverse business rules can apply at table scope. More complex requirements may need synchronous plug ins or another supported server side mechanism appropriate to the transaction. Choose the mechanism against the actual right path. A rule that must prevent an invalid quantity needs to reject that right before acceptance, rather than depend on later automation. Noticing and correcting the value check capacity before photographs become part of every report. Dataverse accounts for database, file and log storage separately, so record counts alone won't tell you whether your proposed evidence and audit policy fit the available capacity. Test attachments using realistic files from the intended device's camera defaults can produce much larger images than the report needs, and reducing them requires checking that the evidence still supports the inspection rather than simply shrinking everything. Request demand needs the same practical check. Opening a report can generate several calls for reference records, permissions, and related information, so count the service activity behind the task rather than counting only completed submissions. Review both request entitlements and service protection limits. There are different constraints, and the workload test should cover busy periods, repeated lookups and the effect of your design when several people use the application together. Licensing belongs in that assessment. Before you approve the design, check the current terms for the intended power apps. Use Dataverse access and connected services rather than assuming an existing Microsoft subscription covers the proposed production workload. Put those findings beside the operating assumptions. The plant should understand what storage, access rights and request capacity the design requires. Before anyone treats a successful prototype as evidence that the production service is funded, the operator won't judge any of this by table structure. They'll judge it when they press save and decide whether they can put the tablet down or whether they still need that paper. Note beside the machine. Saved needs to describe a specific event. When the operator presses that button, the app should tell them where the report now exists and which part of the requested work still needs confirmation. Start with capture on the device. If the details exist only on that tablet, the message should explain that the report hasn't reached the plants reporting service, and nobody elsewhere can yet act on that copy. Server receipt is a separate event. Once Dataverse confirms receipt, the app can tell the operator that the reporting service holds the submission without implying that every connected system has accepted the actions it requests. Business validation answers another question. The receiving process checks whether the submitted information meets the rules for the requested action, and the app should distinguish that result from merely receiving a record containing those details. Source system acceptance completes a different part of the journey. If the workflow requests an inventory transaction, acceptance means the responsible inventory system has accepted that transaction with evidence the reporting process can connect to this incident. The operator doesn't need those technical labels. They need plain wording that describes the current position, such as report received, followed by a separate explanation of any action that still awaits an accepted result. Return to the damaged packaging blanks. Assume the report reaches Dataverse, passes its required checks, and later receives the approved quantity and decision needed to request a stock change through the established inventory process. That stock change hasn't been accepted yet. The operator could read defect report received inventory update pending with a clear instruction explaining whether they need to do anything while the responsible team follows up on the pending transaction. Avoid presenting that situation as a failed report. The report exists and remains available while the inventory action awaits a result, so telling the operator to submit everything again would miss describe the problem they actually face. Retry guidance should name the action to repeat if the device hasn't received confirmation of server receipt, the app needs to explain how the operator can check the existing submission before deciding whether another attempt is appropriate. Sometimes waiting is the correct instruction where the service already holds the report and processing continues. Tell the operator that no new submission is needed, rather than leaving an active submit button as the apparent recovery route, a rejected action needs different wording. Explain which action couldn't proceed and what correction or assistance it requires, while preserving a clear distinction between an accepted defect report and an inventory request that needs attention. Give uncertainty its own honest message. If the app can't establish whether an action succeeded, checking confirmation describes the situation better than either announcing success without evidence or instructing someone to start again immediately. Every unresolved state needs somewhere to go. The message should name the plant's designated contact for this workflow, such as the Shift Quality Coordinator, and explain when the operator should contact that role about an unchanged status. Make that route usable. Beside the line, include the approved contact method and the report reference, so the operator can ask about a specific pending incident without reconstructing the entire submission during a separate conversation. Confirmation should remain available after the message disappears. Give the operator a report reference and a way to return to that report's current position, rather than relying on a brief notification they might miss during an interruption. Keep receipt evidence separate from later acceptance evidence. The report can show when the reporting service received it. While any accepted inventory action carries its own source system reference and confirmation time. Once that information returns, that helps the next shift. Ask a precise question. Instead of debating whether somebody submitted something, they can identify the report and establish which requested action still lacks confirmation from the system responsible for accepting it. Use timestamps with labels that describe their meaning received at and inventory accepted at. Tell the operator more than a single updated time that could refer to a minor change unrelated to the pending work. Connection loss makes these distinctions harder to communicate. If coverage disappears after the operator enters the damaged details, the app still needs to state what it can confirm, even when it can't obtain a fresh response. The wording must follow the evidence available at that moment. That brings us to offline use, because losing the connection shouldn't leave the operator guessing whether they're holding the only copy of a report. Define exactly what must remain possible without a connection. For our packaging operator, recording the damage might need to continue during a coverage gap, while obtaining a new quality decision could require contact through another approved route. Works offline is too broad to test. Write a task statement instead, such as capturing a defect against already available production information while disconnected, without claiming that the device can complete every related action. Outage length changes that requirement. A brief loss while someone walks between stations creates a different need from an area where the device might remain disconnected throughout the working period. Ask which situation the plant actually needs to support if the requirement covers extended disconnection. Assess whether the operator can still perform the intended task using only information and functions available on that device. the device and runtime belong in that statement. A PowerApps application running in a desktop browser doesn't have the same supported offline behavior as an application running through the supported native PowerApps mobile player. Don't treat browser storage as a substitute for supported offline operation for canvas apps. Microsoft supported offline scenarios rely on the native mobile player, so a browser demonstration won't establish that your disconnected workflow is supported. That distinction can affect a fixed station immediately. If the plant expects to open the app through a browser on an existing terminal, check that expectation before designing around mobile offline capabilities it won't receive through that route. Name the intended operating system and app type, then verify the supported runtime on the actual device. Because tablet describes the hardware shape and tells you very little about how the application will run Dataverse offline. First is a specific implementation choice in supported configurations. It lets the app work with local Dataverse data and synchronize through the platform, rather than requiring the maker to build every offline behavior from scratch. The support boundary still needs checking. Review Microsoft's current documentation for your chosen app. Type the tables involved and the controls the task depends on before treating offline first. As an accepted design, a supported app doesn't make every component work offline. Model driven apps and canvas apps have different setup requirements and limitations, so assess the particular design rather than borrowing assurances from a demonstration built with another app type, inspect the whole path through the defect task. A report form might support local entry, while a required lookup, custom component or connected action still depends on a live service and prevents the operator from finishing test the task with the connection deliberately unavailable. Starting from the supported preparation state, ask the operator to complete the intended steps, including any device control or lookup that the proposed workflow requires. Be precise about what that test proves. Demonstrating local capture establishes that the supported app can record that information under those conditions. It doesn't establish that disconnected users can perform actions against remote systems. Cloud services still need a route to the cloud. The disconnected device can't invoke a cloud backed operation and obtain its result. Whether that operation checks a live production record or requests a new decision elsewhere. Power automate cloud flows don't execute on the tablet. A flow may continue running in the cloud for work it already received, but a new submission held only on the disconnected device can't trigger that cloud processing yet. Separate those two situations in the design. The service might remain healthy and continue processing other reports while this operator has no connection, so the limitation concerns this device access rather than a plant wide automation failure, define which actions remain available during that gap. Let the operator perform the supported local task and restrict actions that require a current server response, instead of making them appear available until they fail. Some workflows need an online checkpoint. If completing a step depends on information the device can't establish locally, specify that boundary openly, and provide the plant's approved alternative for handling the work during disconnection. That decision gives. Offline use a practical scope. You can now state which task continues under which outage conditions, on which supported device, and where the operator must stop or use another route. The remaining question concerns what supports that local task. Once you've agreed what the operator may do while disconnected, you need to decide which production information and permitted rules the device must carry with it. The device needs a bounded set of production information for the packaging task, I define that set around the work the operator can report against, rather than download every order available to the plant. An offline profile defines which Dataverse data is available locally. Its table selections, relationships, and supported filters need to match the task, so the report can reference the records it needs without carrying unrelated production history. Start from assigned work and follow its dependencies. An order number won't help much if the device lacks the product description, material references, or other related records. The operator needs to identify that order correctly. Check each relationship through a realistic task. If selecting an assigned order requires a related operation record, include that dependency deliberately, then confirm the profile brings down the intended records under the supported configuration. Filtering needs a practical review as well. The filtering options and relationship behavior depend on the chosen offline implementation, so verify the current support rather than assuming every online query can become an offline profile filter. I'd use a small sample to inspect the result, prepare a device for the packaging line, then check which orders and related records actually arrive, including records you expected the profile to exclude from local storage. Reason codes need the same attention if the operator classifies torn packaging while disconnected, the approved choices and their meanings must already be available without depending on a separate reference service. For an explanation, keep that reference set under a named owner's control. A short code list can still cause trouble if two descriptions overlap, or if a retired reason remains selectable after the plant changes. Its reporting procedure include only the supporting detail the operator needs material descriptions and permitted units may belong locally. While years of completed incidents probably don't help someone record damage against the work assigned to the station today. Preparation now becomes part of device readiness before someone takes a tablet into an area without coverage. The initial download needs to finish and provide the records required for the intended work. Test preparation from an empty local state. A device that already contains yesterday's records can hide missing dependencies or long download times that become obvious when a replacement tablet needs preparation before a shift. Measure storage and download time together. A profile that fits comfortably on the device might still take too long to prepare over the plant's actual connection, especially when several tablets need their initial data together. Use representative record volumes during that test include the related data the profile really retrieves, because a small order selection can still bring a much larger set of supporting records through its configured relationships. Shared devices add. Another reason to limit the download information stored locally remains a device exposure concern, so examine what each supported user arrangement leaves available and avoid distributing records merely because storage seems plentiful. Freshness needs its own rule for each consequential record, a reason description might remain usable for an agreed period, while a production instruction could become unsuitable as soon as the responsible team issues a revision. Give those limits a clear basis. The process owner should define how long locally held information permits a particular task using the consequence of stale information, rather than one expiry period. For everything downloaded, the app must apply that rule during use where the chosen design supports it. Check the locally available validity information before allowing the task, and explain which action becomes unavailable when that information expires. Expiry doesn't prove that nothing changed earlier. An order could change elsewhere while its local copy remains within the permitted age, so the plant still needs to accept the uncertainty for each allowed offline action that may justify different restrictions. Within the same report, the operator could record an observation against known work while being prevented from treating an old instruction as permission for a step requiring current production information. Keep the observations separate from that permission. In our packaging case, the damage remains worth recording, even if the device can no longer establish that its downloaded work assignment still represents the line's current activity. Eventually, the device will receive newer information if the order changed while the operator recorded the damage. The report and the current production record may now describe different circumstances that need an explicit decision when the connection returns. Suppose the packaging order closes while the tablet remains disconnected. The operator recorded the damage before closure, but the report reaches the service afterward. When the current order record no longer permits the usual reporting action. The observation still needs a place in the record. Closing the order doesn't erase the damaged blanks, so the plant needs a rule for accepting that evidence without silently reopening production work or changing its recorded completion. I'd root that case for review. Under an agreed exception process, the reviewer can establish whether the report concerns work performed before closure, whether its references remain correct and what correction the responsible process permits after closure. That decision belongs to the plant, not the synchronization engine. Platform synchronization handles supported exchanges between local and server records. While your process determines what a late observation means when the production circumstances have changed, check the platform behavior independently using your chosen app configuration test. What happens when server records change during disconnection, including whether local writes succeed, fail, or produce errors that need attention through a supported recovery route? Don't infer the business outcome from a completed sync. A report reaching Dataverse establishes a technical result, but someone still needs to determine whether its relationship to the closed order satisfies the plant's rules for accepting that observation. Keep enough evidence to reconstruct the sequence. Retain when the operator captured the report, when the service received it, and the source identity connecting that submission to its originating record and user with device context where appropriate, those times answer different questions during an investigation. Device clocks can drift, so capture time shouldn't become unquestioned proof that an event preceded order closure, especially where that timing changes which actions the plant permits. Preserve the original values. When someone resolves the exception, record the review outcome beside them, rather than replacing the captured order reference or time until the report appears to have arrived under ordinary conditions, then test recovery without giving the operator advance warning. Restart the app after local entry and again during synchronization. Checking whether the supported design preserves the report and presents an understandable route back to unfinished work. Session expiry deserves a separate test. Let the session expire while the device holds Unsynchronized work. Then establish what happens during Re-authentication and whether the intended user can recover that work under the supported sign in arrangement. Avoid promising recovery before you've demonstrated it. Clearing application data, reinstalling the player, or changing users could affect locally held records, so the support instructions need to identify which actions risk removing the only remaining copy. Partial synchronization can produce a less obvious failure test a report whose main record reaches the service while related evidence still needs attention, then check whether the receiving process can distinguish an incomplete transfer from a complete submission. Give unresolved errors a named person to follow them. Support needs enough detail to locate the affected record. Establish what remains only on the device and decide which supported recovery. Action won't destroy evidence or obscure the failure device. Loss needs an equally honest response. If a tablet disappears before its report leaves local storage, the server may contain no copy, and the team shouldn't confuse an absent server record with proof that nobody entered one. Rehearse that case with the shift lead and support team. Establish how they identify potentially missing work. Ask the reporter for confirmation and record any reconstruction as reconstructed information rather than pretending it came from the lost device. Record the recovery result for every test, a restart that preserves text but loses its order reference isn't a pass, and neither is a transfer that finishes technically while leaving support unable to locate the remaining error. 00:51:36 Speaker: The test ends when the affected work has an accountable outcome. That might mean a recovered submission and accepted exception, or a documented loss requiring follow up. But it shouldn't mean leaving the operator to repeat attempts until something disappears. Recovery also exposes the next boundary. Once the report reaches the reporting service intact, any action requested from another production system needs its own dependable handoff, with evidence that survives failures beyond the tablets connection, a recovered device only settles part of that problem. We now need to examine how the receiving production system accepts the reports requested action, so successful synchronization doesn't leave another uncertain transaction waiting somewhere else in the plant. Ask the production systems owner to identify its supported entry points. An application programming interface, or API, defines how another application can request information or actions without needing to manipulate the system's internal storage directly. A supported connector can make that interface easier to use in Power Platform. It can expose operations through a configured connection, but you still need to check which operations it supports for your particular system version. The connector name doesn't establish the full agreement. An inventory connector might retrieve stock balances, yet lack the specific transaction your plant uses to change material status, so inspect the actual operations before committing to it. A custom connector may suit a documented API that gives your app or automation a defined way to call the interface, while leaving the receiving system responsible for interpreting and accepting the requested business action. Get the system owner to confirm the intended use. An interface documented for importing planning data may apply different checks from one intended for production reporting, even when both accept fields that appear to describe similar information. Then write down the integration contract. That's the agreement between sender and receiver about what a request means, what information it must contain, and how the receiver communicates its outcome to the calling process. For our packaging incident, begin with identifiers. Establish which order reference the destination expects, whether a lot number needs a plant or material reference alongside it, and how the request identifies the affected stock. Location units need an explicit agreement as well. If the operator reports damaged bundles but the inventory transaction expects individual blanks, define where conversion occurs and which approved conversion value applies to that material. Never leave that conversion to an unexplained assumption. A bundle quantity only becomes an inventory quantity when the receiving process knows the pack size that applies, including how it should handle material with variable packaging. Required fields belong in the contract to specify whether the transaction needs a reason code, a stock category, or another reference that wasn't necessary when the operator first described the damage beside the line. Status values need their permitted meanings documented. If the destination distinguishes restricted stock from rejected stock, the integration must request the intended category rather than translate both into whichever value happens to look closest. Failure responses deserve the same precision as accepted responses. Agree how the caller distinguishes missing information from an unsupported action or an unavailable service, and what details the receiving system returns to explain each result. A generic error leaves too much interpretation downstream if the destination rejects the quantity because it exceeds eligible stock. The response should preserve that business reason rather than reduce it to an unexplained connection failure. Keep information requests separate from requests that change records. Reading available stock answers a question about the system's current data, while requesting a stock status change. Asks that system to carry out a controlled business action. Those operations can require different permissions and checks. A connection allowed to retrieve material descriptions shouldn't automatically receive authority to create inventory transactions, merely because the same app needs access to both operations. A read result also has a limited meaning. Finding enough eligible stock during a lookup doesn't guarantee that a later change will succeed, because another accepted transaction could alter that stock before your request reaches the destination. Let the destination validate the change. When it processes the request, it can then evaluate the quantity, stock status and other applicable rules against the records it controls, rather than relying solely on an earlier check elsewhere. Avoid writing directly into production database tables. A table update can change a stored quantity without invoking the supported transaction logic that maintains related records, checks, permitted movements, or records the associated business effects correctly. Database access doesn't establish permission to bypass that logic. Where a vendor supports a particular database procedure as an integration interface. Assess that documented contract specifically, rather than treating general write access as an equivalent route, the contract should make the response understandable to its caller. Once you've established the supported operation and its acceptance rules, you can decide whether the person using the app needs that response immediately or whether the request can wait for processing. Timing should follow the action the operator is trying to complete. If their next permitted step depends on a current answer, the workflow needs that answer before it lets them proceed. Not a promise to check later. Consider a check on whether a stock location can receive material if the operator needs that result before moving the pallet under the approved procedure, putting the question into a queue won't support the task they are performing. The person needs a bounded wait and an explicit outcome set. An acceptable response window with the process owner. Then define what the operator should do if the service can't answer within that window during production. Other work can wait without blocking the operator. Once the damaged material has been handled under the plant's approved procedure, a subsequent administrative update might tolerate a delay while the receiving system processes other requests. That's where queued processing can fit the receiving service stores the request for later processing, allowing the operator to leave the interaction while the requested action remains pending under an agreed timing expectation. Make that choice action by action. Our defect workflow could need an immediate response for one check, while allowing a later inventory request to wait, rather than treating the whole incident as either immediate or delayed. Dataverse receipt becomes the starting point for measuring that wait from their track. The elapsed time until ERP or Mes accepts the requested action, so the plant can distinguish slow onward processing from slow operator interaction set a limit on how long pending remains acceptable. If the receiving system won't process requests during a maintenance window, the process owner needs to decide whether that delay fits the work or requires a different operating arrangement. A queue also changes how you handle bursts, instead of requiring the destination to accept every request at the moment, operators submit them, you can hold accepted requests and process them at a rate the destination supports. Buffering doesn't create more destination capacity. If requests keep arriving faster than the system can process them, the waiting time grows, so the design needs workload, evidence and a defined response. When that delay exceeds the agreed limit, Microsoft services can support that separation where the workload warrants it. Azure Service Bus, for example, provides messaging capabilities that can hold requests between components, while the integration design determines what those messages mean within the production process, custom processing may justify an Azure function. You could use one to prepare a request for a supported destination interface, or evaluate integration specific logic, provided that work warrants custom code rather than an existing supported operation. Neither choice removes the need to engineer the service. Someone still needs to configure message handling, manage access and test processing behavior under the expected load. Because adding a queue doesn't settle how quickly production receives an accepted result. I'd introduce those components only for a demonstrated requirement. A small workflow with an adequate supported integration path may need no separate messaging layer, and every extra component adds another dependency the plant will have to operate. The same restraint applies to promises about real time visibility. Ask which decision needs fresh information and how old that information can become. Before, it would change what the person should do at that point in the task. Different facts can have different freshness targets. A displayed count of open incidents might tolerate some delay, while a response used to determine whether an action can proceed may need a current check from the responsible system. State those targets in terms people can act on for a pending inventory request, specify when acceptance normally needs to arrive and when the delay needs attention. Rather than calling the connection real time without defining an acceptable wait. Test the targets under busy conditions, not just an empty queue. Measure the time to source system acceptance when requests accumulate, because a quick acknowledgement from the first service can hide a much longer delay before the business action finishes. That delay creates a practical question for the person holding the tablet. If confirmation hasn't returned, they may try again. While an integration component could also repeat its own request without knowing whether the earlier attempt changed anything, we need to settle who owns that uncertainty before allowing either person or service to repeat the action. The transaction design needs a way to establish what already happened and who remains responsible for obtaining the accepted outcome. Suppose the inventory system accepts the stock change, but its response never returns. In our hypothetical plant, the operator sees no confirmation and tries again, while the integration service also prepares another attempt at the same request. Both attempts concern the same damaged bundles if the destination treats each arrival as a new instruction, one approved stock change could produce several transactions, even though nobody intended to report any additional damage material. The transaction needs an identity that survives those attempts. Assign that identity when the business action is first created, then preserve it whenever a person or service retrieves that action after an uncertain response. That's the purpose of Idempotency. It means repeated requests for the same business action produce no additional business effect, so repeating an accepted stock change doesn't remove more material from usable stock. Define the action carefully before assigning its identity. A defect report might eventually require several legitimate transactions, so using the report number alone could incorrectly block a later action that the plant genuinely needs. Retries reuse the action identity. Separate actions receive separate identities. If quality authorizes another stock change after inspecting more material, that instruction needs its own identity, even though it still belongs to the original defect report. A change quantity needs explicit handling to Two. Receiving the same action identity with different transaction details should trigger a defined response, rather than quietly treating a change request as either an ordinary retry or fresh authorization. Now distinguish that identity from a correlation identifier. A correlation identifier connects related activity across components, helping support follow the report through processing, while the action identity determines which requests must share a single business effect. Tracing and duplicate prevention need to work together. A log showing two related calls helps explain events, but it won't stop the receiving system from accepting both unless something enforces the rule for that action. Assess the destination support before designing that enforcement, its interface might accept a unique external transaction reference, detect repeated requests, and return the existing result. But you need documented behavior and tests before relying on that protection. Ask what happens when identical requests arrive together? Protection that works for sequential calls may still permit duplicates. If simultaneous requests both pass a preliminary check before either one finishes creating its transaction, a deduplication record can track the action and its known outcome. It might retain the submitted details, processing state and destination reference with a controlled way to claim work, so two processors don't independently execute the same pending action. That record alone doesn't close every failure gap. If the destination commits the stock change and the processor stops before recording acceptance, the local record can remain pending even though the requested business effect already exists. This is where destination support determines your recovery options. Ideally, the integration can retrieve the transaction using its external action reference or safely repeat the request under a documented duplicate prevention guarantee from the receiving system. Without that support, automatic retries need tighter limits. An uncertain result may require reconciliation before another attempt, because a local record of not confirmed doesn't establish that the destination rejected or ignored the original request. Reconciliation compares the intended action with evidence from the destination. Use the action reference and transaction details to establish whether the accepted record exists, then record the confirmed outcome or assign the unresolved discrepancy for investigation. Partial failure can involve several accepted steps. Suppose the inventory change succeeds, but the corresponding incident update fails. Recovery should repair the missing update rather than execute the already accepted inventory transaction. Again, a correction isn't always an automatic reversal. If the accepted stock change itself needs undoing, the responsible team should use an approved corrective transaction that preserves the original reference and explains why the correction became necessary. Give support a decision path for each uncertain outcome. They need to know which evidence establishes acceptance, which retry remains safe, and when. Further processing must pause for someone authorized to approve the next step, then test failures immediately before and after destination acceptance. Those tests expose whether your transaction design can recover a known outcome without requiring the operator to guess, or creating another stock change. While searching for confirmation, Power Automate can participate in that design. Its place depends on which steps it performs and how those steps respect the action, identity, recorded outcome and recovery rules we've just established. For the transaction. I'd put Power Automate around the coordination work first. In our packaging scenario, a cloud flow could route a newly received defect to the relevant quality team, notify the shift coordinator, and create an agreed follow up task. Each step needs a clear purpose. The notification tells someone that work needs attention, while the task records what they need to do and gives the process something to track until that work finishes. Acknowledgments can make that coordination easier to follow. A flow could record that the assigned team has picked up the report, provided that acknowledgement reflects an explicit response rather than simply successful delivery of a notification. Start by examining what actually triggers the flow. A Dataverse trigger configured for broad record changes can start processing when unrelated fields change, so use supported filtering and trigger conditions to match the event you intend to handle. Follow the updates the flow writes back to. If recording a routing result changes the same record being watched, check whether that update starts another run, and whether the configuration correctly excludes that unintended cycle. Concurrency needs a decision for each workflow. Parallel runs might suit independent reports, but two runs changing the same assignment can overwrite each other's decisions unless the design controls access to that shared task. Serial processing has a cost as well. Restricting concurrency can protect a sequence, but it can also leave urgent notifications waiting behind slower work, so test the resulting wait against the plant's agreed escalation timing. The connected service can impose its own pace connector throttling can delay calls or return errors during busy periods, even when the flow itself starts successfully, and the underlying report remains available for people to read, inspect, retry settings rather than accepting them unseen. An action that retries for an extended period can delay later steps, so decide whether the workflow should keep waiting, notify support or record an exception sooner. Check execution limits against the specific flow design. Current limits on run duration requests. An individual connector operations can affect the workflow differently, particularly when an action waits for a response or processes many related items, a test notification isn't enough evidence for production. Run representative bursts and delayed responses, then measure when the intended person actually receives usable work, including what happens when one connector remains unavailable through several attempts. Keep escalation separate from the decision it requests, a flow can alert another quality contact when the damaged material report remains unacknowledged. But that escalation shouldn't change the material's disposition merely because a timer expired. The same boundary applies to inventory. A successful escalation run confirms that the configured coordination steps completed. The authoritative quality decision or inventory transaction still needs its own accepted record from the responsible process. Email alone leaves a weak operating record. Someone can read a message without accepting the task, forward it without transferring responsibility, or overlook it. While the flow history still reports successful delivery to their mailbox. Create a durable task record for the follow up. Link it to the defect. Identify the responsible team and retain its current state and expected response time, so pending work remains discoverable without searching individual inboxes. Notifications should point people back to that task when someone accepts or completes the work. Update the tracked record through the agreed interaction so other participants can establish its position without interpreting a chain of replies. Monitor exceptions independently of the original notification path. If the email action fails, sending the only failure alert through that same unavailable connection won't give support. A dependable way to discover the problem during production. Give support a monitored view of unresolved automation. Failures include the affected task and failed step. Then define who checks that view and how they record that an exception has received attention rather than merely appeared in a run log. A completed flow runs still needs a precise interpretation. It may mean the task reached the right queue and its notification left successfully, while the human work requested by that task remains entirely untouched. That brings us to the person receiving the request. Once automation has delivered the work, the next question is who has authority to make the requested decision and what their recorded response actually authorizes. Authority needs to attach to a specific decision. In our packaging case, the person assessing the torn blanks might be permitted to decide their disposition without being authorized to release the wider batch or permit production to restart. Those decisions need distinct wording in the app. Accept inspected bundles for use, describes a narrower act than release batch, and the person responding needs to understand exactly which material and conditions their response covers. Avoid a button labeled only approve before someone confirms a decision. Present the proposed outcome and its scope, including any conditions that limit where, when or how the affected material may be used. For example, quality could authorize a restricted use. The decision might permit selected bundles after an additional inspection, while leaving the remaining stock on hold until someone completes the checks required by the plant's procedure, that response needs to retain its conditions. If the app records only an approved status, the next person could interpret a limited permission as unrestricted acceptance and use material the reviewer never intended to release. 01:09:06 Speaker: Define eligibility with the people accountable for each decision, a department role might establish someone's general responsibility, while current qualifications, plant policy and applicable requirements determine whether they can authorize this particular outcome for this material. Membership in the quality team may be insufficient. Someone qualified to inspect packaging could lack authorization for a batch release decision, so the assignment process needs more detail than a list of everyone in that department. Eligibility also needs a point in time check. Establish whether the person's authority remains valid when they decide, rather than relying only on the authorization they held when the task first entered their workload earlier that week. Shift boundaries expose gaps in that arrangement. Suppose the designated reviewer leaves before completing the inspection, and the incoming shift sees their name against a decision that nobody currently available believes they can take over. Specify how that responsibility transfers, the incoming authorized reviewer needs the evidence, and any unfinished assessment, plus a clear indication of whether they are continuing an investigation or making a decision another person has already formally recorded absence needs a defined route as well. If the usual approver isn't available, the plant should identify an authorized alternate or an escalation path. That leaves the decision pending until someone with the required authority responds. Delegation needs limits that people can check, record who may delegate, which decisions to whom and for what period, rather than treating an out of office message or a forwarded request as sufficient permission to exercise another person's authority, an overdue decision still remains a decision awaiting authority. The plant can escalate the delay and specify how production handles the wait, but elapsed time shouldn't turn unanswered. Work into permission to use held material. Restart permission requires its own operational meaning. A quality acceptance can settle whether material meets the specified criteria, while leaving other conditions for restarting equipment to the approved production procedure and the people responsible for carrying it out. Key protective functions outside the APS approval logic safety controls must continue to operate independently, and a recorded response must never override an interlock or replace the checks required under the plant's approved safety procedures. Record requirements deserve a separate assessment. Decide what evidence must connect the reviewer. The exact decision, its scope and the applicable record version, including how later corrections preserve the decision originally authorized by that person. Electronic signatures need their own requirements. Review where a signature is required. Assess the applicable controls for its meaning and binding to the record, rather than assuming an ordinary approval response satisfies every obligation attached to that decision. Give the reviewer enough context to consent deliberately. If the underlying quantity or proposed disposition changes while they assess the request, require an agreed recheck before accepting authorisation against details, they may no longer recognise that brings the shared tablet back into the discussion. When two qualified people use the same device during a shift handover, the recorded decision still needs to belong to the person who actually exercised that authority. The device can't answer that question by itself. We need an identity and access arrangement that lets the right person act without allowing the next person holding the tablet to inherit their decision making authority. Sharing the hardware doesn't require sharing an account. Several operators can use one tablet during a shift, while each consequential action remains attributable to the person who performed it through a supported individual sign in arrangement. Decide where individual attribution is required before choosing that arrangement. For our packaging report, the plant might require a named reporter, while its quality decisions require a separately identified reviewer whose access reflects their own authority. A name selected from a list doesn't establish identity. If anyone holding the device can select a colleague's name, the record tells you which name they chose, rather than demonstrating who actually submitted the action. Assess Microsoft Entry ID alongside the device configuration, its access policies, the device management settings, and the application supported authentication behavior need to work together on the exact operating system and runtime the plant intends to use. Check shared device support rather than assuming it applies everywhere. A supported shared device mode depends on the participating applications and configuration, so signing out of one application doesn't automatically prove every other application has ended. That person's session include device management specialists in the practical trial with Microsoft Intune or another approved management service. Establish which configuration, compliance checks and device restrictions your chosen equipment supports, then test their effect during normal operator changes. Access policies can introduce a physical problem beside the line. If authentication requires another device or a step unavailable in that working area. Resolve that requirement with the identity team instead of teaching operators to keep somebody else's session open. Try the changeover at the actual workstation. Measure how someone ends their session, how the next person starts, and whether the app clearly identifies the current user before accepting an action that requires personal attribution. Then test access without relying on the visible controls. A hidden review button only changes the interface, so the underlying Dataverse permissions must prevent an operator account from performing protected rights through another available access route. Read access deserves the same attention as write access. Confirm that users can retrieve only the records their duties permit, including through searches and related records. Rather than assuming a plant filter inside, the app establishes the security boundary. Three. Offline storage makes the handover more demanding and one person's session with downloaded records and unfinished work present. Then establish exactly what the next signed in person can access under that supported device and application configuration. Use distinguishable test records for each participant that lets the team detect whether earlier data remains accessible, whether Unsynchronized work retains its original attribution, and whether changing users affects the ability to recover that work. A disconnected handover needs its own acceptance test if the required sign in or sign out behavior can't complete without connectivity, the plant needs an approved operating restriction instead of letting another person continue under the previous user's identity. Check what remains accessible after the device locks. A lock can protect immediate physical access without proving that locally stored information has been removed, and the support team needs to understand that difference when assessing exposure loss response needs evidence about remote actions for the intended device enrollment and operating system. Establish what remote lock access, blocking, selective removal, or full wipe can actually do and which actions your configuration supports. Remote actions also depend on reaching the device. A disconnected tablet might not receive a management command promptly, so the response can't assume that issuing a wipe immediately removes every locally held production record. Rehearse the response with a prepared test device. Check how support identifies the tablet blocks. Further authorized access where supported follows command status and handles any unsynchronized reports that may disappear when local storage is removed. Record the limits in the support instructions. The shift lead needs to know whether a requested action has completed, remains pending, or can't address information already accessible on the missing device without further safeguards that gives operator access a testable boundary, we can establish who used the tablet, what their account could reach, and what remains exposed during a handover or loss. Rather than relying on an account name displayed in the app, there's another boundary beyond the person holding the device. Even a correctly authenticated operator needs a controlled connection to production information. Which brings us to how those connections cross the plant network without granting broader access than the task requires. Start by naming who owns each side of the connection information technology, or it typically manages enterprise services and cloud connectivity, while operational technology or OT manages the systems that monitor and control physical production equipment. The boundary needs joint ownership. It needs to understand the production consequence of a connection change, and OT needs to understand which information leaves the production network and which services can request it. Give the connection itself a name. Technical owner. That person needs agreement from both teams about its permitted purpose, the systems it reaches, and who can authorize changes to the network path during production. For the packaging line, consider a request for machine State. The app team wants to associate the damaged material observation with whether the line was running, stopped, or changing over when the operator discovered the torn blanks. That requirement doesn't justify a route into the control network. First, ask whether an approved production service already exposes the required state, so the application can consume that information without reaching further toward the equipment. Trace the permitted path from the equipment outward. An industrial interface collects the relevant signal and approved integration service makes a defined representation available, and the application accesses that representation through a controlled enterprise facing endpoint. Each crossing needs a specific purpose. The network teams should define permitted endpoints, communication direction, and protocols rather than approved broad access. Because an application happens to support production work inside the plant. A gateway can participate in that approved path. Microsoft's on premises data gateway supports access to certain on premises data sources, but its presence doesn't establish that every source behind it is appropriate for a shop floor application. Placement and reach still need engineering review. Configure the gateway or integration service so it can reach only the approved sources with the required network rules, instead of placing it somewhere that exposes unrelated production systems. A working connection isn't the entire acceptance test. Have the network teams verify that the service can perform its intended exchange, and that attempts to reach systems outside that agreement remain blocked by the network controls. Keep programmable logic controllers or PLCs behind suitable industrial interfaces. These controllers execute equipment, logic and any collection of their data needs to respect the communication capacity and operating constraints of the installed equipment. The app shouldn't become another machine polling client if every tablet independently requests controller values, application demand starts shaping traffic near equipment whose communication behavior should remain under the control of the responsible industrial engineers. Use the approved collection layer to absorb that demand. Depending on the installed architecture, a historian or industrial connectivity service can provide machine information without exposing controller addresses and device protocols to each application that needs context. Now, separate machine signals from operator statements, an Internet of Things or IoT pipeline can carry equipment, events, and measurements, while the app records the operator's observation and the production context attached to that observation. Those streams have different meanings. A machine signal might establish that the packaging line stopped, while the operator's report explains that they found torn blanks and identifies the material they were examining at that moment. Connect the records without merging their claims. Retain the asset reference, event time and signal source for the machine information alongside the operators separately recorded account of what they observed and where they found it. A stopped signal doesn't establish the cause. If the operator reports damage near the same time, the system can present those events together. But an investigation still needs to establish whether the damage caused the stop preserve the signals quality and freshness as context. A last known running state from an interrupted collection service needs to remain distinguishable from a current observation, particularly when someone later uses that information to reconstruct the incident. This architecture also gives future app teams a defined access route. They can request the production information exposed through approved services, rather than negotiate another direct connection to equipment whenever a new task needs machine context. The next challenge is keeping that route intact as apps spread. Once plant teams can build their own applications, governance needs to make the approved boundary usable enough that another maker doesn't solve a missing data field by creating a new path into the control network. Give the plant maker an approved place to start. A production engineer who understands the task should be able to build a useful draft without first negotiating every platform decision or finding their own connection to production data. That's the practical purpose of citizen development here. People close to the work can shape applications within agreed limits, while platform specialists provide the environments, connection choices and technical review that those applications need before anyone depends on them. Make those limits available before the first build. If the maker discovers the rules only after demonstrating an app to their supervisor. Governance becomes a demand to dismantle something the department already expects to use. An approved starting pattern can prevent that argument. Provide a maintained example for a common request workflow with agreed record structures and permitted connection choices, so makers can adapt the task without inventing the surrounding architecture themselves. Patterns need instructions about their limits. A template intended for requesting supplies shouldn't carry an implied approval for changing inventory, even if a maker can add that capability through another operation exposed by an available connector. Connection review should examine the proposed operation. The reviewer needs to understand which service the connection reaches, what authority it uses, and whether the app needs to read information or request changes within that service. Give experimental work somewhere separate to happen. A development environment lets makers explore a draft using appropriate test information without placing their unfinished tables and automation beside the records operators depend on during production use a distinct test environment for acceptance. Its purpose is to check the proposed application under controlled conditions before it enters the production environment, where only accepted versions should support the plant's actual work. Name an owner for each environment that owner needs authority to manage, who can build there, which resources belong there, and how. Exceptions receive a decision. When a maker needs something outside the agreed boundaries. Separation needs more than different environment names. If a development app connects directly to live inventory with permission to change stock, its location in the development environment hasn't contained the consequence of an experimental action. Connector policies add another layer of control power platform. Data loss prevention, or DLP policies can restrict which connectors may be used together, helping prevent business information from moving through combinations the organization hasn't approved. Be precise about what those policies enforce. Connectors classified into business and non-business groups can't exchange data within the same app or flow under that policy. While connectors that support blocking can be blocked from use, those classifications. Don't inspect the meaning of every record. Putting a connector in the business group doesn't establish that every destination reached through it is suitable for every category of plant information a maker might handle. Record level security still needs its own design. DLP addresses permitted connector use and combinations, while permissions determine which production records a particular user or connection can read or change within the services involved. Let makers check policy constraints early. Provide an accessible route to ask whether a proposed connection is permitted with an explanation of the decision, rather than leaving them to discover restrictions through unexplained errors during the build review effort should follow the consequence of the workflow. A request for replacement cleaning supplies may need a modest review, provided it doesn't create purchasing commitments or change another controlled record through an added automation step, a quality or inventory workflow needs closer examination. Reviewers should examine the actions it can initiate and the authority behind those actions, rather than estimate risk from how many fields or pages the application contains, a small app can carry a large consequence. One control that changes production status deserves more scrutiny than a lengthy checklist that merely gathers observations. Even when the checklist takes far more effort to build, write down what triggers that deeper review. Makers need to recognize when adding a stock transaction, quality decision, or production status. Change moves their draft beyond the permission granted for its original, simpler purpose. Governance needs a route to an accepted production app. Once the maker understands the boundaries and the reviewer accepts the intended use, the next question is how that test at work reaches production without bypassing the controls that permitted it. Treat each production release as a controlled change to working equipment. Application lifecycle management, or ARM is how you prepare, test and move app changes into production while retaining enough evidence to identify exactly what you released. a release needs an identifiable version and a repeatable deployment route. If someone manually edits the production app after testing finishes, the plant is no longer running the version whose behavior the acceptance team actually checked. Power platform solutions package supported application components for movement between environments include the relevant app tables and automation dependencies. Deliberately then check that the package contains what the release requires, rather than assuming everything travels with the app. Connection references help separate those components from their destination connections during deployment, bind them to the approved connections for that environment, and verify the binding before enabling processing that could send requests to a production system environment. Variables hold configuration that changes between destinations. An integration endpoint or plant specific setting can belong there, but deployment still needs a check that its production value points to the intended service rather than yesterday's test destination. Deployment pipelines can provide a controlled route through those steps. Depending on the tooling and configuration you choose, they can support approvals and recorded deployments while your release process determines which evidence permits a version to advance. Record the package version beside the configuration used for deployment. That combination helps explain a failure where the app components match the tested release, but an incorrect endpoint or connection sends its request somewhere the test never exercised. Compatibility needs attention before the release date arrives. Suppose we add a required packaging classification to the defect request while a tablet remains disconnected, with reports captured under the earlier version of the app, those reports won't acquire the missing answer by reconnecting the receiving integration needs a defined response for the older request format, such as accepting that version under documented rules or routing it for controlled completion version the integration contract, so that response is deliberate. Specify which request versions the receiver accepts, how it distinguishes them, and when. An older version will stop receiving ordinary processing rather than fail unexpectedly after deployment. Changing a field's meaning deserves the same scrutiny as removing it. Keeping the field name while changing its permitted values can break older requests just as effectively. Especially when a returning device submits information that previously passed validation. 01:26:30 Speaker: Test that returning device as part of Release Acceptance, prepare it with the earlier app and local records disconnected, deploy the proposed changes elsewhere, then reconnect it and examine both synchronization and onward processing. Production like testing also needs representative configuration and data relationships run the release against the intended security arrangements and integration versions, including pending records created before the update, rather than testing only fresh submissions created afterward agree the release window with production, including the night shift, specify whether people can keep entering reports during deployment, what restrictions apply, and who confirms that the updated workflow can resume its normal operating pattern. A quiet daytime window might still leave night operators exposed. They could be the first people to encounter a tablet returning after hours offline, so include that situation in the release checks before declaring deployment complete. Rollback needs a realistic description of what it can restore. Reinstating an earlier app version won't automatically undo changed records, reverse accepted inventory transactions, or remove consequences already produced by the newer automation. While it ran. Some schema changes also limit a simple return before deployment. Establish whether the earlier app can still operate against the change tables, and whether any solution changes require a forward correction instead of an uncomplicated reversal. Prepare a data repair plan alongside the release plan, it should explain how to identify affected records, preserve their history, and apply reviewed corrections without repeating business actions that the receiving system has already accepted during the faulty release. Set a clear point for stopping further processing. If acceptance checks reveal a problem, the release team needs an agreed way to contain new effects while it establishes which records need correction and which remain safe. The release record should outlast the person who clicked deploy. When the original maker moves on, someone else must still be able to identify the running version, interpret its deployment decisions, and carry out the next controlled change. A controlled release doesn't guarantee a supported application six months later. Shadow. It can exist inside an approved power platform environment where nobody accepts responsibility for the working service, its dependencies, or the people who rely on it, the gap concerns ownership, not just permission to build an app, can meet platform policy and still leave the night shift without help, because its creator changed jobs and nobody inherited their operational responsibilities. In our hypothetical plant, imagine the defect app still opens. Normally, reports continue arriving, but a question about an unresolved inventory request reaches a former maker's unattended mailbox because everyone still treats that person as the application owner. Assign a business owner who accepts responsibility for the workflow. That person decides whether the app still meets the plant's needs, resolves disputes about its intended use, and authorizes changes to what the service is expected to accomplish. Give technical ownership to someone with an explicit remit. They need responsibility for maintaining the application and its dependencies, with enough access and documentation to investigate problems without asking the original maker to return from another role. Support needs a team, not an informal promise. Specify who receives an incident during each operating period and who can investigate it. Including the hand off when the first contact can't resolve the reported problem, name an integration contact on the receiving system side as well when a report reaches the app service, but it's requested, transaction remains uncertain. Support needs someone authorized to investigate the destination rather than merely confirm that the app appears healthy, one person might hold several responsibilities in a small plant. Record those responsibilities separately anyway, so an absence or role change exposes exactly which duties need cover. Instead of leaving a vague instruction to contact engineering, an app inventory makes those commitments discoverable for each operational app record its purpose supported plant activities owners and support root in a maintained register that the relevant teams can access without locating the maker. Include dependencies that don't carry the application's name, a shared reference data service, or a separately maintained flow could affect several plant apps, so the inventory needs to show those relationships and identify who maintains each dependency. Record permissions and connections with their operational purpose Support should be able to establish which identity authorizes a connection, what that connection can reach, and which approved task requires its access without exposing passwords in the register. Describe the records the application maintains and where responsibility ends. Include who controls their retention and what must happen to outstanding work if the application closes. Rather than treating retirement as simply removing the app from people's devices. A retirement plan needs an accountable destination for unfinished records. For our defect workflow, somebody must accept the pending investigations and preserve the necessary references before the plant withdraws the application that people currently use to find them. Personal connections deserve a deliberate review before the maker leaves a flow that depends on their individual account can lose access when that account changes or closes, even though every operator still has permission to open the application. Use approved service identities where the relevant components support them. Depending on the connector and operation that might involve an application identity or another organization managed arrangement, but verify support rather than assuming every connection accepts the same authentication method. Keep the identities authority limited to its assigned work. An organization managed account shouldn't inherit broad access simply because several automations use it, and someone needs responsibility for reviewing that access and maintaining any credentials it requires. Removing personal dependencies also means checking ownership and recovery access. Confirm that authorized maintainers can manage the app, its flows, and its connections through supported arrangements without needing the departing maker's password or borrowing their session. Ask the replacement team to demonstrate that independence. Give them a realistic support question and check whether they can locate the relevant records. Reach the integration contact and explain who must decide the next action without calling the original creator. Named ownership creates a commitment to provide actual working time. Once a team accepts responsibility for maintaining the application and responding during production. The plant needs to establish whether that team has the capacity and funding to carry those duties. That's where the prototypes price stops being a useful guide. The cost question now covers the application's working life, including the people expected to keep it dependable after building. It is no longer anyone's project. I'd ask for a costed operating plan before approving expansion, put the expected users connected services and support hours into that plan, so the budget reflects how the plant will actually run the application. Start with the people who need access, including occasional users. A relief operator who opens the app only when covering another station still belongs in the licensing assessment, alongside the regular operators and reviewers who use it throughout their shifts. Have your licensing specialist examined the proposed design, not just the app name they need to check premium connectors, Dataverse use, and the relevant power automate patterns against current terms, including which activities fall within the intended application. Context. Flow licensing needs particular care when the design changes, a flow initiated through the app and a separately scheduled process may raise different licensing questions, so describe their actual triggers, users, and purpose before requesting a definitive assessment. Record the assumptions behind the quoted cost. If the estimate covers one plant and a defined user population, adding another site or extending automation to a separate business process should trigger a fresh review rather than inherit that original estimate. Shared tablets don't settle the licensing question, count the people and activities involved, then check which licensing options apply under current terms. Instead of dividing the anticipated bill by the number of devices on the charging shelf. Ask the specialist to document the accepted shared device arrangement that gives procurement something specific to price, and gives the plant a clear basis for reassessment. When staffing patterns, contractors or access requirements change during the application's working life. Then, price the equipment as an operating fleet, include replacement provision, worn accessories and the practical work of preparing another device. Because purchasing the initial tablets doesn't fund every hardware need that follows during production, storage needs a forecast tied to the retention policy. Estimate how the retained records and supporting evidence accumulate over time, then budget for the capacity and administrative work needed to keep that information available for its required period. Integration has recurring costs even when the interface already exists. Depending on the design, those costs can include hosted processing, messaging, gateway infrastructure, and specialist time. When a connected system changes its supported interface or operating arrangements. Support needs funded hours rather than an entry marked internal estimate the coverage production requires and the investigation effort the team can absorb, including the effect on its other responsibilities when several plant applications need attention together. Testing also consumes people who have other jobs. Allow time for operators and system specialists to check changes, plus access to representative equipment, rather than assuming acceptance work will fit into whatever spare time appears before a release. Training belongs in the recurring budget. Two new starters, temporary staff and people moving between stations, need a practical way to learn the task, while supervisors need time to explain changes that affect how their teams work. Change management includes the effort around those explanations, updated instructions, translated material where needed, and time for questions all require someone to prepare them even when the underlying software change takes the maker. Only an afternoon offline scope can change several lines at once, extending local access from currently assigned work to a much broader production history increases the information the device carries and the workload your team must test and maintain. Model that scope using expected growth, not today's sample. A profile that behaves acceptably at launch may become harder to support as related records accumulate, particularly if nobody has budgeted time to review which records still need local availability. Synchronization performance affects staffing as well as devices. If preparation or recovery takes longer as volume grows, the plant may need more support, effort or spare equipment to keep the intended workflow available during its working hours. I price those choices before promising broader offline access. The process owner can then judge whether the extra disconnected capability justifies its It's capacity testing and maintenance burden, rather than discover those costs after operators depend on it. Keep a recurring allowance for revisiting those estimates. User numbers retained volume and support demand can all move away from the original assumptions, so the operating budget needs a scheduled review rather than a fixed figure copied forward. Funding tells us what the plant intends to sustain. The next question is whether the workflow continues to function during production, because paying for an application doesn't establish that the work reaches its agreed destination. App opens tell you a little about whether the work finishes for the packaging workflow. I'd measure how many submitted reports reach their agreed acceptance point with the reporting period and acceptance criteria stated alongside the result. Keep the denominator explicit. Reports accepted during a shift might include yesterday's backlog, so comparing that count with today's submissions could suggest a completion rate that doesn't describe either group accurately. Follow submitted reports as a defined group. Instead, establish how many reach acceptance within the expected period, how many remain pending and how many require correction before the receiving process can accept them under its rules. Repeated entry needs evidence beyond matching descriptions. Ask operators to flag when they're recording the same incident elsewhere, then investigate those cases so legitimate, separate observations don't inflate your estimate of unnecessary duplicate work. Measure unresolved requests by age as well as count a stable total can conceal requests that never move, while newer work keeps arriving and finishing quickly enough to make the overall workload appear under control. Synchronization failures need a task level measure. Several failed attempts involving one report represent a different operating problem from several reports that never leave their devices, even if the technical error count looks identical. Correction effort deserves its own record of actual work. Track the time people spend clarifying quantities, repairing references, and investigating uncertain outcomes, including work performed outside the app that won't appear in its usage records. Connect those measures to a traceable submission. Support should be able to start with the operator's report reference and follow its associated processing through the flow run to the response returned by the destination system. Record the relationship between those references explicitly. The report identifier, flow run identifier, and destination transaction reference won't necessarily match, so the investigation depends on retained links rather than someone searching several systems by approximate time, capture meaningful events along that path. Recording when processing starts, when the destination receives a request, and when its response returns. Helps distinguish waiting inside the automation from waiting for the receiving service to answer. Preserve the response category and relevant business reason. A flow run can finish while its requested business action remains rejected, so technical completion and accepted production work need separate measures in the operational evidence. Measure the existing process before claiming an improvement. Observe comparable defect cases and record entry effort waiting and follow up work rather than timing only the part of the old process that the new app visibly replaces. Use pilot evidence to test that comparison. include the effort required to correct and finish the work, so a reduction in operator entry time doesn't hide additional work transferred to quality or the support team. Be cautious about attributing production gains to the app if material availability or staffing changes during the pilot. Improved output alone won't establish what the application contributed, even when the workflow measures also improve over that period. Record those conditions alongside the results, then distinguish the improvement you directly observed, such as less repeated entry from a broader production effect that the available evidence can't confidently attribute to this particular change. Power BI can help analyze these records once their meanings are dependable. Build measures around the accepted workflow definitions and check that combining reports with processing events doesn't count one incident several times because it generated multiple technical attempts. Microsoft Fabric may fit when analysis spans several operational sources, it can support bringing that evidence together for analysis. While the organization still needs to maintain the identifiers, event meanings and quality checks that make the combined records trustworthy. State freshness in terms the plant can interpret. An analysis refreshed earlier in the shift shouldn't present its pending request count as current and a fresh refresh time doesn't prove every source has supplied equally recent information. Keep analysis separate from confirmation of an individual transaction. Someone investigating a pending report needs its operational evidence, rather than assuming that an absent entry in a delayed analytical data set proves the destination hasn't accepted it. These measures give the pilot specific questions to answer. We can now test whether ordinary work reaches acceptance, and whether failures remain discoverable without treating a busy application or a collection of successful flow runs. As proof that production work finished. Run the pilot as a bounded production trial. Choose one defect workflow. Specify where it begins and ends, and agree which work stays outside the trial before inviting operators to depend on it. Keep the device selection representative of the intended rollout. Use the tablets, scanners and mounting arrangements planned for the work, including an ordinary shared device rather than only the newer equipment. The project team uses for demonstrations include more than one shift in the trial. Let each shift perform the task with its normal staffing and support arrangements, so success doesn't depend on specialists standing nearby. Whenever somebody picks up the tablet, set limits on the trial with the shift leads. Everyone involved should know which incidents belong in it, when to use the approved alternative, and who can pause the trial if the workflow leaves production uncertain. Replay our packaging incident from discovery through accepted posting. Give the operator a controlled case involving damaged blanks. Then ask them to identify the material and record the observation without the maker explaining each step. Introduce the connection loss at a planned point. Have the operator continue within the permitted offline scope, then ask them to explain what they believe has happened before. Restoring connectivity and allowing the report to synchronize that explanation becomes part of the evidence. If the operator believes quality already has the report while it remains on the tablet, the trial has exposed a trust problem even if synchronization later completes successfully continue through the quality decision and the resulting transaction. Follow the same incident until the responsible system accepts the posting and ask each participant to establish completion using the evidence available through their normal working route. Then deliberately challenge that route with failure drills. Coordinate these exercises with production and the receiving system owners using controlled records or an appropriate test setting, wherever the drill could otherwise create an unintended production consequence. Start with a repeated request during an uncertain response. Let the approved retry mechanism operate, then have someone outside the development team establish whether the destination contains exactly the intended transaction and whether the operator understands the result. Make a receiving system unavailable for another exercise. Observe whether people recognize the pending work, whether the designated support team discovers the interruption, and whether recovery reaches acceptance without someone informally bypassing the agreed process. Expire access during a separate controlled attempt. Ask the operator and support team to handle the interruption through their documented routes. Checking whether they can account for the unfinished report without relying on the project team include a release that fails its acceptance checks in the controlled setting. Have the release team contain the problem and account for affected work, while shift staff explain what they can still do and what must wait. Judge these drills by their operational outcomes. A useful result includes the people recognizing the situation, the intended records remaining traceable, and someone accepting responsibility for the next step without prompting from the developer. Expansion needs an explicit decision, not a launch date. Agree the gates before reviewing the results. So enthusiasm for a successful demonstration doesn't quietly replace the standards the plant originally expected the pilot to meet. Operator trust needs observable evidence at that gate. Ask participants to handle an ordinary case and an interrupted case unaided, then check whether they correctly identify what remains pending and whether they still maintain an unofficial backup because they're uncertain. Traceability and support readiness need independent checks. Give a report reference to the designated support team and have them locate its accepted outcome or identify its unresolved step and the person responsible for moving it forward. Compare the agreed measures with the pilot evidence. Keep expansion on hold where results remain outside the accepted limits, and document any unresolved condition, rather than allowing it to disappear into a general declaration of success. Finish the trial with a shift handover. Leave a controlled defect report pending. Let the reporting operator finish their shift and ask the incoming team to establish who now owns the work and what that person must do next. Don't supply the answer during that exercise. If nobody accepts the pending report without a call to the project team, the pilot hasn't yet proved that the workflow can operate beyond the people who built it. Operators need a reason to trust the record. That trust grows when their report reaches its agreed destination, or when a named person owns the remaining work. After the reporting operator's shift has ended, the pending defect still needs an owner to morrow. How are you handling that handoff between offline capture and confirmed ERP or Mez acceptance in your plant? And where does responsibility sit while confirmation remains pending?