M365.FM - Modern work, security, and productivity with Microsoft 365

Mirko Peters - Founder of m365.fm, m365.show and m365con.net
  • ٥٫٠ (٣)
  • أخبار التكنولوجيا
  • يتم التحديث يوميًا

Welcome to the M365.FM — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365.FM brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. M365.FM is part of the M365-Show Network. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

  1. قبل ساعة واحدة

    Dynamics 365 Procurement and Sourcing - Simply Explained

    What happens when someone at work needs a new laptop, raw materials for production, safety equipment, consulting services, or even a cleaning contract? In many organizations, purchasing still involves emails, spreadsheets, approval messages, vendor quotes, delivery notes, and invoices spread across different systems. Dynamics 365 Procurement and Sourcing connects these activities into one controlled source-to-pay process. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Supply Chain Management connects purchase requisitions, sourcing, vendors, RFQs, purchase orders, receiving, invoice matching, approvals, Accounts Payable, and vendor payments. WHAT IS DYNAMICS 365 PROCUREMENT AND SOURCING? Procurement and sourcing are closely related, but they describe different parts of the purchasing process. Sourcing focuses on finding and selecting the right vendor. The organization considers products, prices, delivery dates, terms, discounts, and the vendor's ability to meet its requirements. Procurement manages what happens when the organization actually buys something: the request, approval, purchase order, receipt, invoice, and eventually payment. Together, these activities create the source-to-pay process. SOURCE-TO-PAY EXPLAINED Source-to-pay describes the complete journey from identifying a business requirement to paying the supplier. The organization identifies what it needs, finds or selects an appropriate vendor, creates an order, receives the goods or services, processes the vendor invoice, and eventually pays the supplier. The individual steps aren't particularly unusual. The value comes from keeping them connected. Instead of approvals disappearing into email and invoices arriving without context, Dynamics 365 maintains the purchasing trail from the original request through payment. DIRECT VS INDIRECT PROCUREMENT Businesses typically purchase two broad categories of goods and services. Direct procurement covers goods or services directly connected to what the company produces or sells. A furniture manufacturer purchasing wood, screws, and fabric is buying direct materials. Indirect procurement covers products and services required to operate the business but which don't become part of the finished product. Examples include laptops, office furniture, training, repairs, cleaning, software, and legal services. Dynamics 365 can support both types while maintaining controlled purchasing processes. PURCHASE REQUISITIONS A purchase requisition is an internal request to buy something. An employee can specify what is required, the quantity, and potentially where the purchase should be delivered. Importantly, the requisition doesn't yet create a commitment with a vendor. That gives the organization an opportunity to review the requirement, check budgets, apply purchasing policies, and obtain the appropriate approvals before money is committed. PROCUREMENT CATALOGS Common purchases can begin through procurement catalogs. Think of the catalog as the organization's approved internal shopping shelf. Instead of somebody entering a vague request for "safety gloves," employees can select an approved product with an established description, supplier option, and price. Catalogs simplify purchasing for employees while helping the organization guide demand toward products and suppliers it already understands. PROCUREMENT CATEGORIES Not every purchase belongs in a product catalog. Organizations also purchase consulting, repairs, training, legal services, and other requirements that might not have a traditional item number. Procurement categories allow these purchases to be classified according to what the organization is buying. Examples could include safety supplies, computer equipment, professional services, building repairs, or training. This allows purchasing controls and spend analysis to work even when the purchase isn't a physical inventory item. APPROVAL WORKFLOWS A purchase shouldn't automatically proceed simply because somebody requested it. Dynamics 365 can use approval workflows, spending limits, purchasing policies, and budget controls to determine who needs to review a request. A small purchase might require one manager's approval. A larger expenditure could additionally require a budget owner or purchasing manager. The approval path can depend on factors such as amount, department, category, and company policy. Dynamics 365 records those approvals as part of the purchasing history. REQUEST FOR QUOTATION When the organization hasn't already selected a supplier, purchasing can create a Request for Quotation, commonly called an RFQ. Several vendors can receive the same requirements and provide their prices and commercial terms. One vendor might offer the lowest price but require three weeks for delivery. Another might cost slightly more but deliver next week. Dynamics 365 keeps those responses connected with the sourcing process so buyers can compare options before making a decision. VENDOR MANAGEMENT Vendor records contain information required for the organization's purchasing relationship with suppliers. Vendor catalogs can describe products available from particular suppliers, while approved vendor lists can identify which suppliers are permitted for specific products. This helps organizations control where employees and buyers purchase goods. Instead of choosing a supplier simply because somebody found one online, the purchasing process can guide users toward vendors the organization has already approved. PURCHASE AGREEMENTS A purchase agreement records longer-term commercial arrangements between the organization and a vendor. For example, the business might agree to purchase a particular quantity or spend a certain amount over an established period in return for agreed commercial terms. When purchases occur under that agreement, buyers don't need to renegotiate the complete arrangement every time. This is particularly useful for frequently purchased goods and strategic vendor relationships. TRADE AND REBATE AGREEMENTS Trade agreements can record vendor prices or discounts that apply during particular periods. If a supplier agrees to provide safety gloves at a discounted price for six months, Dynamics 365 can maintain that pricing arrangement. Rebate agreements address another scenario: the supplier returns money when agreed purchasing quantities or spending thresholds are reached. Together, these capabilities help organizations maintain negotiated commercial conditions within the purchasing process instead of relying on individual buyers to remember them. THE PURCHASE ORDER Once the organization knows what it needs and who will supply it, the purchasing decision becomes a Purchase Order, or PO. The purchase order formally describes what the organization intends to buy. It identifies the vendor, products or services, quantities, prices, delivery requirements, and payment terms. The PO becomes the central commercial record that purchasing, warehouse employees, finance teams, and the supplier can work against. HOW PURCHASE ORDERS ARE CREATED  Purchase orders can originate from several sources. An approved purchase requisition can become a PO. A buyer can release purchases against an existing purchase agreement. Planned demand can create planned purchase orders that later become real orders. Buyers can also manually create purchase orders when they already know exactly what needs to be purchased and which supplier should provide it. Different purchasing scenarios can therefore enter the process differently while ultimately creating the same controlled purchase record. PURCHASE ORDER APPROVAL AND CONFIRMATION The organization can require internal approval before a purchase order becomes an external commitment. This separates two important decisions. First, the organization approves spending its own money. Then the purchase order can be confirmed with the vendor, establishing the agreed products, quantities, prices, delivery dates, and terms. This creates a clearer purchasing process than sending an order externally before the appropriate internal approval has occurred. DELIVERY SCHEDULES Not every purchase order arrives in one delivery. A supplier might deliver part of an order immediately and the remainder the following week. Delivery schedules allow one purchase order to contain planned deliveries across multiple dates. The organization maintains one connected purchasing record while representing what is actually expected to happen operationally. DIRECT DELIVERY Some purchased goods never need to enter the organization's own warehouse. With direct delivery, a supplier ships products directly to the organization's customer. Dynamics 365 can connect the customer sales order with the corresponding vendor purchase order. This eliminates an unnecessary warehouse stop while maintaining the relationship between the customer demand and the supplier fulfilling that demand. SUPPLEMENTARY ITEMS AND CHARGES Purchase orders can contain more than the primary item being purchased. Dynamics 365 can suggest supplementary products that may be required, optional, or included with another item. Charges such as freight and handling can also be associated with the purchase order or individual lines. This matters because the advertised product price doesn't necessarily represent the complete purchasing cost. Keeping additional charges connected to the order provides a clearer view of what the purchase actually costs. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Dynamics 365 Procurement and Sourcing - Simply Explained

  2. قبل ساعة واحدة

    Dynamics 365 Accounts Receivable - Simply Explained

    You made the sale and sent the invoice—but when does the money actually reach your account, and what happens when it doesn't? Dynamics 365 Accounts Receivable connects customer accounts, invoices, payment terms, incoming payments, settlement, credit management, collections, disputes, and overdue balances inside Dynamics 365 Finance. In this episode of M365 FM, Mirko Peters follows one customer balance from the original sale through invoicing and payment—and shows what happens when payment arrives late. WHAT IS DYNAMICS 365 ACCOUNTS RECEIVABLE?  Accounts Receivable tracks money customers owe the business and the payments received against those debts. Think of it as a financial filing cabinet. Every customer has a folder containing invoices, payments, due dates, payment terms, credit information, and follow-up activities. A spreadsheet can list outstanding invoices. Dynamics 365 Finance goes further by connecting those invoices with sales transactions, customer agreements, bank payments, credit decisions, and collection activities. The result is a connected view of the financial relationship with each customer. THE CUSTOMER ACCOUNT Every Accounts Receivable process begins with the customer account. The customer account contains more than contact information. It defines many of the financial rules governing how the organization does business with that customer. That can include the invoice address, payment terms, payment method, credit limit, customer group, and other financial settings. For example, products might be delivered to a customer's factory while invoices are sent to its finance office. Dynamics 365 can maintain those differences as part of the customer relationship. PAYMENT TERMS AND DUE DATES Payment terms answer a straightforward question: How long does the customer have to pay? One customer might pay immediately, another within 30 days, and a larger customer might negotiate 60-day payment terms. Once those rules exist on the customer account, Dynamics 365 can use them when calculating invoice due dates. Employees don't need to search through email conversations every time an invoice is created to determine what was agreed with the customer. CUSTOMER CREDIT LIMITS A credit limit defines how much the organization is willing to let a customer owe at one time. A strong customer relationship doesn't automatically mean unlimited financial exposure. If a customer already has a substantial outstanding balance and places another large order, Dynamics 365 can help finance and sales determine whether the new transaction requires additional attention. Credit limits therefore establish agreed financial boundaries before unpaid balances become larger problems. CUSTOMER GROUPS AND POSTING PROFILES Customer groups allow organizations to organize customers with similar characteristics. Retail customers might belong to one group while wholesale customers belong to another. Posting profiles handle an accounting requirement behind the scenes. They determine which financial accounts should record customer debt when transactions are posted. Employees outside finance might rarely interact with these configurations, but they help ensure customer transactions reach the correct places within the organization's financial records. FROM SALES ORDER TO CUSTOMER INVOICE An order and an invoice aren't the same thing. A sales order records what the customer wants to purchase. An invoice establishes what the customer needs to pay. When the invoice is posted, Dynamics 365 creates an open balance against the customer account. Accounts Receivable can then track that amount until payment closes it or somebody needs to take action. INVOICING FROM SALES ORDERS Many customer invoices originate directly from sales orders. Because the sales order already contains information about the customer, products, quantities, prices, and other agreements, finance doesn't need to recreate those details inside a separate billing system. Depending on the organization's process, invoicing might happen when products ship or when another agreed billing milestone occurs. The important point is that the invoice remains connected to the underlying business transaction. PACKING SLIP INVOICING Sometimes an organization wants to invoice based on what actually shipped rather than everything originally ordered. Imagine a customer orders ten units but only eight are currently available. If eight units ship, invoicing based on the confirmed delivery information allows the organization to bill for those eight rather than charging the customer for products that haven't yet been delivered. This creates a closer connection between warehouse execution and financial billing.  FREE TEXT INVOICES Not every invoice begins with a sales order. An organization might need to invoice a customer for training, a service charge, a project-related fee, or another one-off amount. Dynamics 365 Finance supports free text invoices for these situations. Despite the name, these are still formal invoices. The difference is that they aren't linked to a sales order. Once posted, the amount becomes part of the customer's outstanding balance just like other customer invoices. RECURRING AND SUBSCRIPTION BILLING Recurring services introduce another Accounts Receivable requirement. If a customer pays a monthly maintenance fee, manually recreating the same invoice every month wastes time and increases the possibility of errors. Billing schedules can support recurring charges according to the agreed arrangement. Instead of rebuilding every invoice manually, the organization establishes the billing schedule and uses that structure as billing periods arrive. WHAT POSTING AN INVOICE MEANS Posting is an important financial moment. Before posting, the invoice hasn't yet become the same kind of finalized financial transaction. Once posted, Dynamics 365 records the amount against the customer's account as money owed and sends the transaction into the organization's financial records. Accounts Receivable can now see the outstanding balance, due date, and customer responsible for paying it. RECEIVING CUSTOMER PAYMENTS Money arriving in the company's bank account doesn't automatically complete the Accounts Receivable process. Finance still needs to answer two questions: Who sent the money, and which invoice—or invoices—does that payment belong to? Without connecting the payment to the correct customer debt, the bank could show that cash arrived while Dynamics 365 still reports the customer's invoice as unpaid. The financial records therefore need to meet. CUSTOMER PAYMENT JOURNALS A customer payment journal provides a controlled place for finance teams to enter and review customer payments. Information can include the customer, payment amount, payment method, receiving bank account, and references associated with the transaction. Customers might pay through bank transfers, cards, checks, cash, or other supported payment mechanisms. The payment journal helps finance record those transactions before they become part of the posted financial records. SETTLEMENT EXPLAINED Settlement sounds technical, but the basic concept is simple: Settlement matches a payment with the invoice it pays. If a customer pays exactly the amount owed on an invoice, finance can match the payment against that open invoice. Once processed, the invoice no longer remains outstanding and the customer's open balance decreases accordingly. Without correct settlement, an organization can receive the money while still incorrectly showing that the customer owes it. PARTIAL PAYMENTS Customers don't always pay an invoice in full. If a customer pays only part of the outstanding amount, Dynamics 365 can settle the amount received while keeping the remaining balance open. Finance can therefore see precisely how much has been paid and how much remains outstanding. This is significantly clearer than marking an invoice as completed and attempting to track the remaining amount through notes or external spreadsheets. PAYMENT RECONCILIATION Organizations receiving large numbers of bank payments need a more efficient way to match incoming transactions with customer invoices. Dynamics 365 can use payment reconciliation processes to help match bank information against open customer transactions. References, amounts, customer information, and matching rules can help identify likely matches. Finance still reviews the results. Automation reduces manual searching, but the team remains responsible for ensuring that payments settle the correct invoices. CENTRALIZED PAYMENTS Organizations operating several legal entities can face additional payment complexity. A central finance organization might receive payments on behalf of several companies within the wider group. Dynamics 365 supports centralized payment scenarios where a payment can be recorded in one legal entity while settling customer debt associated with another. This allows the accounting records to reflect how the organization actually manages its centralized finance operations. CREDIT MANAGEMENT Receiving payment closes an existing debt. Credit management asks whether the organization should allow the customer to create more debt. Dynamics 365 can consider the customer's credit limit, outstanding invoices, overdue amounts, and the value of a new sales order. A customer might technically remain below its credit limit but have significantly overdue invoices. Another customer might pay reliably but place an unusually large new order. Credit management provides structured rules for identifying transactions requiring review. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Dynamics 365 Accounts Receivable - Simply Explained

  3. قبل ساعتين

    Dynamics 365 Warehouse Management - Simply Explained

    Dynamics 365 Warehouse Management turns inventory records into guided physical work on the warehouse floor. Knowing that 200 units exist is only the beginning. Warehouse teams need to know exactly where those units are stored, whether they are available, which customer orders they belong to, and what workers should do with them next. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Warehouse Management connects receiving, put-away, storage, replenishment, picking, packing, shipping, cycle counting, returns, quality management, barcode scanning, and warehouse automation with the wider Dynamics 365 Supply Chain Management platform. WHAT IS DYNAMICS 365 WAREHOUSE MANAGEMENT? Dynamics 365 Warehouse Management focuses on the physical work taking place inside a warehouse. It guides employees through receiving deliveries, moving products into storage, replenishing picking locations, picking customer orders, packing shipments, and preparing goods for dispatch. Each completed warehouse action can update the same connected business system used by purchasing, sales, production, inventory, quality, transportation, and finance. Instead of relying on paper lists or recording movements later, warehouse employees can confirm activities while they happen using mobile devices and barcode scans. INVENTORY MANAGEMENT VS WAREHOUSE MANAGEMENT Inventory Management and Warehouse Management solve related but different problems. Inventory Management answers questions such as: How much inventory does the company have? What is it worth? Is it available? Warehouse Management focuses on questions such as: Where exactly is that inventory, and what should a warehouse worker do with it next? Knowing that 200 boxes exist in Warehouse A isn't enough for efficient warehouse operations. Employees need to know that 80 are in one rack, 60 are in bulk storage, 20 are near packing, and another quantity is already reserved. Inventory Management provides the stock record. Warehouse Management converts that information into physical work. SITES, WAREHOUSES AND LOCATIONS Dynamics 365 needs a digital representation of the physical warehouse environment. A site can represent a broader business location such as a factory campus or distribution center. A site can contain one or more warehouses. Inside those warehouses are individual locations representing receiving docks, racks, shelves, bins, packing stations, staging areas, and quarantine areas. This hierarchy gives inventory a precise digital location rather than simply recording that the product exists somewhere inside a building. BATCH AND SERIAL NUMBER TRACKING Warehouse Management can maintain additional information about individual products. Batch numbers identify groups of products from the same production run or delivery. This becomes particularly important for food, pharmaceuticals, chemicals, and other products requiring traceability. Serial numbers identify individual units. Machines, laptops, and high-value components can therefore maintain their individual identities as they move through the warehouse and eventually reach customers. This creates a traceable history that can become valuable for returns, quality problems, servicing, and recalls. LICENSE PLATES EXPLAINED A warehouse license plate isn't a vehicle registration. In Dynamics 365, a license plate provides a unique identifier for a pallet, carton, tote, or another container. Think of it like a luggage tag. Scanning the identifier tells Dynamics which container the worker is handling and what that container contains. Instead of scanning every individual box on a pallet repeatedly, employees can work with the license plate representing the complete pallet when the underlying inventory record is accurate. RECEIVING INBOUND GOODS Warehouse activity frequently begins with a purchase order. The purchase order tells the organization which products it expects from a supplier, the expected quantities, and usually the expected arrival time. When the truck reaches the warehouse, employees can scan the products or pallets and compare the physical delivery with the expected purchase order. If 100 cases were expected but only 98 arrived, the discrepancy can become visible immediately instead of waiting for somebody to manually enter paperwork later. QUARANTINE AND QUALITY CONTROL Not everything entering a warehouse should immediately become available. Products might require inspection, testing, or approval before they can be used or shipped. Dynamics 365 can direct those goods toward quarantine locations. The inventory physically exists inside the warehouse, but employees cannot treat it like ordinary available stock. Once the appropriate quality process has been completed, the products can either be approved for normal use or rejected and handled appropriately. PUT-AWAY After receiving, products need somewhere to go. This process is called put-away. Instead of asking workers to decide where a pallet should fit, Dynamics 365 can direct them toward an appropriate storage location. The decision can consider the product, warehouse zone, physical size, storage requirements, available space, and intended use of the location. The worker receives a straightforward instruction while the underlying warehouse configuration handles the decision logic. LOCATION DIRECTIVES Location directives are the rules Dynamics 365 uses to determine where inventory should go or where inventory should be picked from. Heavy inventory might need a ground-level rack. Fast-moving products might belong close to packing areas. Temperature-sensitive products may only be stored in approved locations. Location directives translate these warehouse policies into executable instructions. Instead of expecting every employee to memorize every storage rule, Dynamics can determine an appropriate location and present that destination through the worker's device.  WORK TEMPLATES Work templates determine the steps employees need to perform. For inbound inventory, a work template might contain two straightforward steps: pick the inventory from the receiving location and put it into its designated storage location. For outbound operations, templates can define picking, movement to packing, and staging. These repeatable workflows help create consistent warehouse processes across employees and shifts. MOBILE DEVICES AND BARCODE SCANNING Warehouse employees can receive instructions directly on mobile devices. The device can ask the worker to scan a location, scan a product, confirm a quantity, and proceed to the next step. These scans create immediate validation. If somebody scans the wrong product while picking a customer order, the system can identify the problem before the incorrect item reaches the customer's package. The scan also updates the warehouse record while the physical activity occurs rather than requiring information to be entered later.             REPLENISHMENT Many warehouses separate bulk inventory from smaller locations used for daily order picking. When a picking location begins running low, employees need to move additional inventory from bulk storage before somebody encounters an empty shelf while fulfilling an order. Dynamics 365 can create replenishment work directing employees to move inventory into the appropriate picking location. This turns replenishment into planned warehouse activity rather than an emergency search for missing products. OUTBOUND WAREHOUSE MANAGEMENT Outbound warehouse activity begins when customer demand needs to become a physical shipment. A sales order identifies what the customer ordered and how much they require. Inventory can be reserved for that order so the same limited stock isn't accidentally promised to somebody else. Warehouse Management then converts the requirement into physical activities such as picking the products, moving them to packing, preparing containers, staging the shipment, and eventually moving the goods toward the loading dock. WAVES EXPLAINED Large warehouses don't necessarily process every customer order independently. Dynamics 365 can use waves to group outbound work. Orders might be grouped because they leave on the same truck, share a delivery date, belong to a similar warehouse zone, or follow another operational rule. Grouping work can reduce unnecessary movement and help warehouses process large quantities of orders more efficiently. PICKING CUSTOMER ORDERS Once warehouse work is released, employees receive picking instructions. The mobile device can direct someone toward the appropriate location, ask them to scan the location, verify the product, and confirm the quantity. This creates several validation points before the product leaves its storage location. Instead of relying on a paper list and discovering errors at the end of the process, Dynamics can identify some mistakes while the worker is still standing at the shelf. CLUSTER PICKING Cluster picking allows one employee to pick products for several customer orders during a single journey through the warehouse. The worker might use a cart containing multiple totes, with each tote associated with a different order. When an item is picked, the mobile device tells the employee which tote should receive it. This can reduce unnecessary walking while keeping products belonging to different customer orders separated.  Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Dynamics 365 Warehouse Management - Simply Explained

  4. قبل ٤ ساعات

    Dynamics 365 Transportation Management - Simply Explained

    Dynamics 365 Transportation Management connects the movement of physical goods with sales orders, purchase orders, warehouse operations, carriers, routes, rates, loads, and freight costs. Instead of managing transportation through separate spreadsheets, emails, carrier rate sheets, and phone calls, organizations can create a connected transportation plan directly inside Dynamics 365 Supply Chain Management. In this episode of M365 FM, Mirko Peters explains how Transportation Management works from the moment goods need to move through load planning, carrier selection, warehouse execution, delivery, and freight reconciliation. WHAT IS DYNAMICS 365 TRANSPORTATION MANAGEMENT? Dynamics 365 Transportation Management is the transportation planning capability inside Dynamics 365 Supply Chain Management. It connects warehouses, vendors, customers, carriers, orders, shipments, and freight costs. Think of it as the transportation desk inside the organization. Sales creates customer demand, purchasing manages incoming goods, warehouse teams prepare inventory, and Transportation Management determines how those goods should move between locations. The objective is to create one connected transportation process instead of maintaining separate lists and manual handoffs between departments. WHY TRANSPORTATION MANAGEMENT MATTERS A sales order doesn't physically move inventory. Goods still need a truck, trailer, container, or another form of transportation. Someone needs to determine where those goods originate, where they need to arrive, how much space they require, when they need to leave, and what transportation should cost. The challenge becomes significantly larger when a business manages hundreds of orders, several warehouses, multiple carriers, incoming supplier deliveries, customer shipments, and transfers between its own locations. Transportation Management provides a shared system for coordinating these movements. INBOUND TRANSPORTATION Inbound transportation covers goods moving into the organization. A purchase order might contain products expected from a supplier. Depending on the agreement, either the supplier or the purchasing organization may arrange transportation. When the organization manages that transportation, Dynamics 365 can connect the expected goods with a planned inbound load. Warehouse teams therefore gain visibility into what should arrive before the truck reaches the loading dock. OUTBOUND TRANSPORTATION Outbound transportation covers goods leaving the organization. A customer places a sales order, the warehouse prepares the products, and a carrier transports them to their destination. Transportation Management connects that sales demand with the shipment, load, carrier, route, service, and expected transportation cost. This allows warehouse and transportation teams to work around the same movement rather than independently planning different parts of the shipment. TRANSPORTATION FOR TRANSFER ORDERS Goods don't always move between a company and a customer or supplier. Organizations frequently transfer inventory between their own warehouses or sites. Dynamics 365 Transportation Management can include transfer orders within outbound transportation planning. From the loading dock's perspective, inventory still needs vehicle capacity, loading, transportation, and receiving regardless of whether the destination is a customer or another company warehouse. WHAT IS A LOAD? A load is the digital record representing a planned movement of goods. You can think of it as one truck, trailer, container, or collection of shipments traveling together. Several customer shipments might share one truck, while one particularly large customer order could require an entire trailer. The important idea is that Dynamics 365 doesn't require businesses to treat every individual order as a completely separate transportation job. Compatible shipments can be grouped into a shared transportation plan. CONSOLIDATING SHIPMENTS Imagine six customer orders are leaving the same warehouse for approximately the same destination on Friday. Booking six separate partially filled trucks would waste capacity and potentially increase transportation costs. Instead, compatible shipments can be grouped into one load. Compatibility can depend on factors such as departure location, shipping time, vehicle capacity, weight, volume, destination, and organizational transportation rules. This gives transportation planners an opportunity to use available vehicle capacity more efficiently. LOAD TEMPLATES Physical vehicles have limits. A truck can only carry a certain amount of weight and volume. Containers and trailers also have physical restrictions. Dynamics 365 uses load templates to represent reusable limits for different types of vehicles or containers. Organizations could create templates for small delivery trucks, large trailers, or shipping containers. These templates can include limits such as maximum weight, volume, and height. This helps planners determine whether a proposed load realistically fits the transportation capacity available. VOLUME-BASED LOAD BUILDING Dynamics 365 also supports volume-based load building. Despite the technical name, the concept is straightforward: Dynamics uses information from the load template to help determine whether goods fit within the configured transportation limits. The planner can still override values when real-world circumstances require an exception. The system therefore provides a standard planning framework without pretending transportation always follows perfectly predictable conditions. CARRIERS EXPLAINED The carrier is responsible for physically moving the goods. That could be an external transportation company collecting freight from the warehouse, or it could represent the organization's own fleet. Even businesses operating their own trucks still require transportation planning. They need to determine which goods travel together, where the vehicle travels, and potentially how transportation costs should be allocated. Dynamics 365 Transportation Management can support both scenarios. ROUTES AND SERVICES A route describes how goods travel between their starting point and destination. Different services might provide different combinations of speed, availability, and cost. A standard road freight service might be less expensive but take longer, while an expedited option might cost considerably more while helping the organization meet an urgent customer commitment. Transportation planning therefore isn't simply about finding a vehicle. It is about selecting a transportation option that balances delivery requirements with cost. TRANSPORTATION RATES Rates represent the expected transportation charges associated with carrier services and routes. Organizations can maintain rate tables containing agreed carrier prices and transportation rules. Instead of searching through old emails or spreadsheets every time transportation needs to be booked, planners can use structured rate information already maintained inside Dynamics 365. When carrier contracts and prices change, those rate records can be updated accordingly. THE RATE ROUTE WORKBENCH The Rate Route Workbench gives transportation planners a place to compare route and rate options for a shipment. One option might be faster while another costs less. Dynamics 365 provides the available transportation information, but the business still determines which trade-off makes sense. An urgent customer order might justify an expensive expedited service. Another customer might accept a longer delivery time in exchange for lower transportation costs. DYNAMICS 365 IS NOT A LIVE CARRIER MARKETPLACE An important distinction is that the built-in Transportation Management module doesn't automatically behave like a live marketplace comparing real-time prices across every available carrier. Its built-in planning processes use the carrier, route, and rate information maintained by the organization. Companies requiring live multi-carrier rate shopping, extensive booking integrations, or deeper shipment tracking can connect specialized third-party transportation management solutions. Dynamics 365 remains the internal transportation planning layer while external platforms can extend the carrier-facing capabilities. FROM SALES ORDER TO CUSTOMER DELIVERY For outbound transportation, the process begins with customer demand. The sales order defines what the customer purchased, where the products need to go, and when delivery is expected. Those products become part of a shipment, and shipments can be assigned to a planned load. Warehouse employees then pick, pack, stage, and load the products. Because the warehouse work connects with the transportation plan, employees can see which goods belong together and which carrier is expected to collect them. CONNECTING TRANSPORTATION AND WAREHOUSE MANAGEMENT Transportation planning and warehouse execution are closely connected. Transportation Management determines how goods should travel. Warehouse operations physically prepare those goods for movement. Instead of warehouse employees preparing pallets without knowing which transportation plan they belong to, shipments can remain connected to their loads. This reduces the need to reconcile separate transportation spreadsheets, warehouse lists, emails, and paper documents at the loading dock. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Dynamics 365 Transportation Management - Simply Explained

  5. قبل ٨ ساعات

    Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP]

    Microsoft 365 Copilot is moving far beyond prompt engineering. As organizations adopt AI more seriously, the challenge becomes connecting Copilot and AI agents to business applications, Microsoft Graph, organizational knowledge, APIs, workflows, and enterprise data while maintaining security and governance. In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP and AI Tech Lead Yves Habersaat about Microsoft 365 Copilot extensibility, Copilot Studio, Microsoft Foundry, Model Context Protocol (MCP), RAG, multi-agent architectures, enterprise search, permissions, governance, AI readiness, and what it takes to build production-grade AI solutions. FROM PROMPT ENGINEERING TO AI ARCHITECTURE Prompt engineering can help employees get more value from generative AI, but enterprise AI requires much more than better prompts. Organizations need people who understand the underlying technologies, customer requirements, architecture, security, business applications, data, and implementation decisions. Yves argues that human architects and engineers remain important because AI can generate technical material and provide guidance, but organizations still need people capable of validating whether a solution actually addresses the business requirement. WHERE COPILOT EXTENSIBILITY BEGINS Microsoft 365 Copilot has evolved considerably since its earliest versions. Many capabilities that previously required extensions are now available directly within the platform. Extensibility becomes particularly relevant when organizations need greater control. This could mean customizing orchestration, creating specialized agent experiences, integrating an agent into a website rather than only Microsoft 365 Copilot Chat, or building capabilities that aren't available through the standard experience. The more specialized the requirement becomes, the more important extensibility and custom development become. WHY ONE GIANT COPILOT ISN'T THE ANSWER Instead of building one enormous Copilot containing every instruction, tool, knowledge source, and responsibility, Yves recommends thinking in terms of multi-agent architectures. Individual agents can have clearly defined scopes and responsibilities. An IT support architecture, for example, could contain a front-facing agent responsible for understanding the user's request and routing it to specialized agents for Microsoft 365, Salesforce, or other platforms. Each specialized agent can then maintain its own instructions, knowledge, and tools. THE ANATOMY OF AN ENTERPRISE AI AGENT A typical enterprise agent starts with a clearly defined objective. The agent then requires instructions defining its responsibilities and boundaries, knowledge sources containing relevant organizational information, tools allowing it to perform actions, and an orchestration layer deciding how requests should be processed. In a multi-agent architecture, a front agent can delegate tasks to specialized agents. Those agents can then access internal knowledge sources, external systems, APIs, and MCP servers depending on the task they need to perform. COPILOT STUDIO VS CUSTOM DEVELOPMENT Copilot Studio provides a low-code approach to building agents. Organizations can define instructions, connect tools, integrate knowledge sources, and use MCP servers without building every component themselves. Custom development provides significantly greater control but also introduces more architectural responsibility. Developers may need to manage authentication, security, hosting, orchestration, external services, and integration patterns themselves. The decision therefore isn't simply low-code versus code. It depends on how much control the solution actually requires. WHEN COPILOT STUDIO REACHES ITS LIMITS One of the major questions is whether the organization needs to customize orchestration. If standard orchestration satisfies the requirement, Copilot Studio can provide a fast route to building an agent. If developers need deeper control over how plans are created, tasks are prioritized, workflows are executed, or models are selected, custom development becomes more relevant. Custom solutions can also integrate models hosted outside Microsoft's ecosystem, giving organizations additional flexibility over their AI infrastructure. MICROSOFT FOUNDRY AND THE CHANGING AI STACK Microsoft Foundry has evolved from its earlier role around model deployment into a broader AI development platform. Yves describes a platform increasingly supporting agent creation, governance, model management, MCP integration, and other capabilities. This creates some overlap with Copilot Studio, while custom development continues to provide greater flexibility around models, orchestration, hosting, and architecture. The Microsoft AI development landscape is therefore evolving rapidly, making architectural decisions increasingly dependent on the specific use case. WHAT IS MODEL CONTEXT PROTOCOL? Model Context Protocol, or MCP, addresses one of the major challenges in agent development: providing a standardized way for AI systems to discover and interact with external tools and services. Historically, developers integrated individual APIs using different authentication mechanisms, protocols, documentation, and implementation approaches. MCP provides a more standardized interface through which agents can understand which tools are available and how those tools can help accomplish a task. Yves describes it as an increasingly important part of modern AI architecture. MCP VS TRADITIONAL API INTEGRATION MCP doesn't eliminate APIs. Instead, an MCP server can sit in front of existing APIs, databases, and internal services and expose those capabilities in a way AI systems can understand. A company might already have APIs for finance, HR, CRM, or operational systems. An MCP server can expose appropriate tools around those services while the existing APIs continue performing the underlying operations. This makes MCP an AI-oriented integration layer rather than a replacement for the systems underneath it. HOW AGENTS CHOOSE TOOLS An enterprise agent might eventually have access to dozens or hundreds of tools. The agent's orchestration layer, working with the language model, can inspect the available capabilities and determine which tools are relevant to the user's request. It can then create a plan containing the actions required to complete the task and potentially invoke several tools in sequence. This ability to discover and select tools dynamically is one reason MCP has become important in agentic architectures. MICROSOFT GRAPH REMAINS CENTRAL MCP doesn't make Microsoft Graph irrelevant. Yves explains that Microsoft 365 MCP capabilities can rely on Microsoft Graph behind the scenes. An agent interacts with the MCP capability while Graph provides access to Microsoft 365 information and services underneath it. Graph also remains important to Microsoft 365 Copilot because organizational context across Microsoft 365 can be accessed through Microsoft's underlying graph and search capabilities. The integration layer is evolving, but Graph remains a major foundation of the Microsoft 365 ecosystem. SECURING ORGANIZATIONAL KNOWLEDGE Microsoft 365 contains enormous amounts of organizational context: documents, meetings, emails, people, Teams conversations, OneDrive files, and SharePoint content. Connecting AI to that information without proper governance creates obvious risks. Yves recommends beginning by understanding the organization's data. Companies need to know where confidential information exists, who should have access, and what information requires additional protection. Microsoft Purview capabilities such as sensitivity labels and Data Loss Prevention can then become part of the governance architecture. DATA QUALITY IS AN AI PROBLEM AI governance isn't only about preventing unauthorized access. Poorly organized SharePoint sites, duplicated files, outdated documents, inconsistent Teams environments, and unclear information ownership can reduce the quality of AI responses. Connecting an agent to organizational knowledge doesn't automatically make that knowledge useful. Organizations therefore need to consider data cleanup, information architecture, permissions, classification, and governance as part of AI readiness. DELEGATED VS APPLICATION PERMISSIONS Permissions become especially important when agents can take actions. Yves recommends delegated user permissions as the general starting point. This means an agent operates according to the permissions of the person using it. If the user doesn't have access to particular information or functionality, the agent shouldn't automatically gain that access on their behalf. Where application permissions are genuinely necessary, Yves suggests isolating them behind a controlled service or MCP layer rather than exposing broad application permissions directly to the user-facing agent. RAG IN ENTERPRISE AI ARCHITECTURE Retrieval-Augmented Generation, or RAG, allows AI systems to retrieve relevant organizational information before generating an answer. Instead of expecting the language model itself to contain current company-specific information, the system retrieves appropriate content from organizational knowledge sources. That information can come from documents, knowledge bases, Microsoft 365 content, or other enterprise systems. For many users, this happens invisibly because platforms such as Copilot Studio abstract the underlying retrieval architecture. ㅤ RELATED M365.FM RESOURCES Agentic RAG and Microsoft Copilot: https://www.m365.fm/agentic-rag/ MCP architecture for Microsoft AI agents: https://www.m365.fm/the-architects-guide-to-mcp-building-the-connectivity Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP]

  6. قبل يوم واحد

    GitHub Copilot, Clean Context, Automated Testing & AI Coding Agents with Lars Gyrup Brink Nielsen [MVP]

    Related M365.FM resources: For more on AI coding agents and clean repository context, see https://www.m365.fm/blog/copilot-not-responding-troubleshooting-guide-for-microsoft-users/ and https://www.m365.fm/the-monorepo-myth-why-your-architecture-is-fragmented/. For Microsoft AI agent architecture and Copilot extensibility, see https://www.m365.fm/understanding-microsoft-copilot-enterprise-architecture/ and https://www.m365.fm/copilot-studio-vs-azure-ai-foundry-pick-your-poison/. AI-assisted development is moving beyond autocomplete and chat. Modern AI coding agents can inspect repositories, modify files, run tests, analyze failures, create pull requests, and execute increasingly complex development tasks. In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP Lars Gyrup Brink Nielsen about GitHub Copilot, AI coding agents, developer experience, automated testing, TypeScript, JavaScript, Nx, monorepos, Polygraph, GitHub Actions, Playwright, and the architectural foundations required to make agentic software engineering work at enterprise scale. FROM AI ASSISTANCE TO AI CODING AGENTS For the last few years, AI development tools have primarily helped developers generate code, autocomplete functions, answer technical questions, and accelerate individual programming tasks. Agentic engineering changes that model. AI coding agents can potentially inspect an existing repository, understand an issue, modify multiple files, run automated tests, analyze failures, make corrections, and prepare a pull request. That changes the central question from "Can AI generate code?" to "Can AI safely perform engineering work inside a real software architecture?" MEET LARS GYRUP BRINK NIELSEN Lars Gyrup Brink Nielsen is a Microsoft MVP in Developer Technologies, author, international speaker, tech writer, open-source maintainer, community organizer, and former GitHub Star. His experience spans frontend development, cloud-native systems, developer experience, automated testing, continuous delivery, deployment, and open-source software. He has also worked with GitHub Copilot since its early days and has spent more than a year experimenting with AI coding agents in open-source development. WHY DEVELOPER EXPERIENCE MATTERS Developer experience is fundamentally about removing friction from software development. That includes choosing and integrating development frameworks, testing tools, build systems, CI pipelines, documentation, reusable packages, development environments, architectural standards, and automation. Lars contrasts modern developer tooling with earlier workflows involving FTP deployments, directly editing production systems, shared ZIP files, and environments without proper source control. Modern developer experience replaces these fragile processes with repeatable, automated, and verifiable workflows. ARCHITECTURE SHOULD BE ENFORCED Documentation alone isn't enough for large software architectures. Lars explains how tooling such as Nx can attach metadata to projects and enforce architectural boundaries. Organizations can define which types of projects may depend on other projects and use linting rules to automatically detect violations. Generators can also scaffold components, services, projects, tests, and configurations according to organizational standards. This becomes particularly important with AI coding agents. Instead of expecting an agent to remember every architectural rule, organizations can make those rules automatically enforceable. MONOREPOS EXPLAINED A monorepo stores multiple projects or systems inside a shared source-control repository. Microservices and micro-frontends don't necessarily require separate repositories. They can exist within one monorepo while still being independently built and deployed. The advantage is that dependencies between projects become easier to understand and changes spanning multiple systems can be tested together. However, Lars also explains that moving hundreds or thousands of developers from established repositories into one monorepo can be extremely difficult organizationally. MONOREPO VS MULTIPLE REPOSITORIES Separate repositories don't eliminate dependencies between teams. They simply manage those dependencies differently. When two teams maintain dependent systems in different repositories, changes can require coordination, separate environments, cross-repository testing, and synchronized deployments. A monorepo can make those dependencies more visible because the relevant source code exists within the same repository. The larger challenge is often organizational rather than technical: teams still need to communicate, coordinate ownership, and manage dependencies regardless of repository strategy. WHAT IS NX? Nx is a development toolchain that helps teams manage complex codebases, project dependencies, tasks, testing, builds, linting, generators, and development workflows. Lars explains how Nx has evolved beyond its earlier JavaScript-focused roots. It can integrate development tools, automate migrations, understand project relationships, orchestrate tasks, and support multiple technologies. It can also determine which projects are actually affected by a change rather than unnecessarily rebuilding or retesting an entire large codebase. CACHING CAN DRAMATICALLY ACCELERATE DEVELOPMENT Large codebases can contain hundreds of projects and enormous test suites. Repeatedly running every build, test, linting operation, and compilation task wastes significant developer and CI time. Nx can cache task results. If the relevant source files and dependencies haven't changed, developers can reuse previous results instead of executing the same work again. Remote caching can also allow teams and CI systems to share those results. For AI agents, faster verification becomes especially valuable because an agent may repeatedly modify, test, inspect, and correct code during a single task.  POLYGRAPH AND MULTI-REPOSITORY AI AGENTS Not every enterprise can move hundreds of existing repositories into a monorepo. Lars discusses Polygraph as a newer approach for helping AI coding agents operate across multiple related repositories. Instead of an AI coding session being isolated to one repository, Polygraph can provide a harness around multiple repositories and their dependencies. This can allow an agent to work across frontend, backend, microservice, and other repositories during the same development task and potentially prepare coordinated pull requests across those systems. GITHUB ACTIONS AND CONTINUOUS INTEGRATION Automation is a major part of the development environment discussed throughout the episode. GitHub Actions can provide the CI foundation for building, testing, validating, and deploying changes. Nx can work alongside CI workflows and delegate tasks through its own cloud capabilities. During the rapid-fire round, Lars gives GitHub Actions a particularly strong endorsement, calling it the best CI system. PLAYWRIGHT FOR AUTOMATED TESTING Automated verification becomes more important as AI writes a larger percentage of software. When asked to choose between Playwright and Cypress during the rapid-fire round, Lars chooses Playwright. The broader point is significant for agentic development: organizations need reliable automated feedback loops. If an agent changes code, it needs tools capable of determining whether those changes still satisfy the expected behavior.ㅤ GITHUB COPILOT AND THE AGENTIC SHIFT Lars was an early GitHub Copilot user through his involvement with the GitHub Stars program and provided feedback during Copilot's earlier development. His development workflow has now moved significantly beyond traditional Copilot autocomplete. He explains that he rarely writes code manually anymore and instead instructs coding agents to perform much of the implementation work. The challenge increasingly becomes reviewing and ensuring the quality of the code produced by those agents. CONTEXT IS THE NEW ENGINEERING PROBLEM An AI model may understand TypeScript, JavaScript, Angular, React, .NET, testing frameworks, and popular development tools from its training. What it doesn't automatically understand is your organization. Every large software environment contains internal naming conventions, architectural decisions, team standards, project-specific rules, historical constraints, and unique development practices. Those rules need to become accessible to AI agents through mechanisms such as agent instructions, skills, automated checks, architectural boundaries, and repository-specific context. CLEAN CONTEXT FOR AI CODING AGENTS Giving an AI agent more information isn't automatically better. Large repositories can contain enormous amounts of source code, documentation, configuration, legacy decisions, and irrelevant files. The challenge is providing the agent with the information required for its current task without overwhelming its working context. Development tooling, dependency graphs, repository structures, project metadata, agent instructions, and automated validation can help narrow that context. The objective is to give agents enough information to make architecturally correct decisions rather than merely locally correct code changes. CODIFY YOUR TEAM STANDARDS FOR AI Organizations don't necessarily need to fine-tune an AI model on their complete private codebase. Lars points instead toward codifying team-specific knowledge into agent skills and instruction files such as AGENTS.md. These instructions can explain how a particular team performs common tasks, which conventions should be followed, and how the codebase should be approached. This transforms knowledge that previously existed mainly inside experienced d Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    GitHub Copilot, Clean Context, Automated Testing & AI Coding Agents with Lars Gyrup Brink Nielsen [MVP]

  7. قبل يوم واحد

    Dynamics 365 Asset Management - Simply Explained

    Related M365.FM resources: To explore connected Dynamics 365 capabilities, see https://www.m365.fm/dynamics-365-supply-chain-management-simply-explained/, https://www.m365.fm/dynamics-365-inventory-management-simply-explained/, and https://www.m365.fm/dynamics-365-finance-simply-explained/. A conveyor stops in the middle of a shift, a forklift won't start, or a pump suddenly begins leaking. Before anyone can repair the equipment, the business needs answers: Who is responsible? When was it last serviced? Which parts are required? What happened during the previous repair? Dynamics 365 Asset Management provides one central place for this information. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Asset Management helps organizations track physical equipment, preventive maintenance, work orders, spare parts, costs, service history, functional locations, condition-based maintenance, and connected maintenance processes. WHAT IS DYNAMICS 365 ASSET MANAGEMENT? Dynamics 365 Asset Management is part of Dynamics 365 Supply Chain Management and focuses on the physical equipment businesses rely on every day. That could include production machines, conveyor belts, motors, pumps, forklifts, trucks, generators, heating and cooling systems, and other equipment requiring regular inspection, servicing, or repair. Instead of maintenance information being distributed across spreadsheets, folders, emails, invoices, and individual employees' knowledge, Asset Management creates a shared record around the equipment and its maintenance history.  WHY PHYSICAL ASSETS BECOME A BUSINESS PROBLEM A machine doesn't only affect the maintenance department. When equipment fails, operations can lose production capacity, maintenance teams need to diagnose the fault, purchasing may need to urgently source replacement parts, and finance eventually receives the resulting costs. Emergency maintenance can become particularly expensive because organizations may need expedited shipping, urgent purchasing, overtime, or temporary workarounds. Dynamics 365 Asset Management connects these different parts of the maintenance story so teams can understand what happened and why money was spent. ㅤ THE ASSET RECORD Every piece of equipment can have its own digital asset record. The record can contain information such as the asset name, product or model number, serial number, description, technical details, and warranty information. This becomes particularly useful when several machines look almost identical but use different components, have different warranty periods, or require different maintenance procedures. Instead of relying on somebody remembering which machine is which, the asset record provides a consistent reference point. FUNCTIONAL LOCATIONS EXPLAINED Dynamics 365 Asset Management uses functional locations to describe where equipment performs its job. A functional location can represent a site, building, warehouse, workshop, production line, or another operational location. These locations can also form hierarchies. For example, an organization might have a plant containing a packing area, which contains a conveyor line, which contains individual motors, sensors, and rollers. When a motor fails, technicians therefore don't simply see a serial number. They can understand exactly where that motor operates and which wider process could be affected.  PARENT AND CHILD ASSET STRUCTURES Complex equipment frequently consists of smaller components that need their own maintenance history. Dynamics 365 can represent parent-and-child relationships between equipment and components. A conveyor can contain a motor, while the motor itself might contain another component requiring individual maintenance attention. This structure helps maintenance teams understand how individual assets relate to larger equipment and operational systems. ㅤ TRACKING EQUIPMENT AS IT MOVES Physical equipment doesn't necessarily remain in the same location forever. Forklifts can move between warehouses. Pumps can move from storage into buildings. Machines can be reassigned between production lines. Asset Management can track these movements through functional locations. This also matters financially because maintenance costs can follow the equipment to the location currently using it. Managers can therefore understand which plant, department, or operational area is responsible for the costs associated with an asset. BUILDING A COMPLETE SERVICE HISTORY The real value of an asset record grows over time. Inspections, repairs, replaced parts, technician notes, labor time, faults, downtime, and other maintenance information can become part of the equipment's history. A technician investigating a recurring problem can review previous repairs instead of starting from zero. The history might reveal that the same motor has been repaired several times, that a particular component repeatedly fails, or that an earlier technician identified something that needs additional monitoring. ASSET MANAGEMENT VS IT ASSET MANAGEMENT Dynamics 365 Asset Management focuses on physical operational equipment requiring maintenance, inspections, servicing, and repair. It isn't primarily designed for tracking office laptops, smartphones, or software licenses. Production machinery, vehicles, pumps, motors, building equipment, and similar physical assets create a different maintenance requirement because downtime, replacement parts, labor, inspections, and equipment condition all need to be managed over time. REACTIVE VS PREVENTIVE MAINTENANCE Reactive maintenance begins after something fails. The equipment stops, operations are affected, and the maintenance team needs to restore service as quickly as possible. Preventive maintenance attempts to perform appropriate maintenance before a small problem becomes an unexpected failure. Dynamics 365 Asset Management helps organizations plan recurring inspections, cleaning, lubrication, safety checks, testing, and replacement of components that wear out over time. MAINTENANCE PLANS Maintenance plans help organizations turn preventive maintenance into repeatable work. A forklift might require regular inspections of its brakes, tires, fluid levels, lights, and battery condition. A production line might require weekly sensor cleaning, monthly belt inspections, and component replacement after a particular amount of use. These tasks aren't dramatic individually, but performing them consistently can reduce the likelihood of equipment failing during critical operations. MAINTENANCE BASED ON EQUIPMENT USAGE Calendar schedules aren't always enough. Two identical machines might have very different workloads. One could operate for a single shift every day while another operates continuously. Technical readings such as running hours, distance traveled, temperature, pressure, or other measurements can provide additional information about when maintenance should occur. This allows organizations to combine scheduled maintenance with the actual usage and condition of equipment. MAINTENANCE ROUNDS Maintenance rounds provide technicians with planned routes or groups of inspections across multiple assets. Instead of treating every inspection as a separate activity, a technician can inspect related equipment during one routine visit. For example, someone could walk through a packing area checking several conveyor motors, listening for unusual sounds, inspecting fittings, and recording relevant technical readings. This creates a more consistent inspection process even when different technicians perform the work.  CONDITION-BASED MAINTENANCE Condition-based maintenance uses equipment measurements to identify when something may require attention. Imagine vibration readings from a conveyor motor gradually increasing over several weeks. The motor still operates, but the changing measurement indicates that something may be developing. When a reading crosses a threshold established by the organization, the maintenance team can investigate before the equipment necessarily fails. The objective isn't to perfectly predict every breakdown. It is to provide earlier warning and give maintenance teams more time to respond. FROM MAINTENANCE NEED TO WORK ORDER When maintenance becomes actual work, Dynamics 365 uses a work order. The work order acts as the job ticket connecting the problem, required activities, responsible workers, schedule, parts, safety instructions, labor, costs, and final outcome. Work orders can originate from scheduled maintenance, inspections, equipment breakdowns, or follow-up work identified by technicians. Regardless of the source, the work order turns a maintenance requirement into something that can be assigned, scheduled, tracked, completed, and reviewed. PLANNING THE MAINTENANCE JOB A work order can describe the job and the tasks required to complete it. For a conveyor motor showing unusual vibration, technicians might need to isolate the equipment, inspect the mounting, check bearings, complete the repair, test the machine, and return it to service. Checklists can help technicians perform required activities in the correct sequence. Safety instructions can also be associated with the work so requirements such as power isolation, protective equipment, or stopping moving equipment are visible during the job. SPARE PARTS AND INVENTORY Maintenance work frequently depends on replacement parts. A work order can identify required items such as bearings, filters, bolts, grease, or replacement motors. Because Asset Management connects with Dynamics 365 Supply Chain Management, teams can determine whether the required part is already available in inventory. If stock can't cover the requirement, purchasing can ord Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

  8. قبل يوم واحد

    Dynamics 365 Dataverse Integration - Simply Explained

    Dynamics 365 Dataverse Integration is easier to understand once you stop thinking about Dynamics 365 and Dataverse as two completely separate systems that constantly need to synchronize customer data. For Dynamics 365 applications such as Sales and Customer Service, Dataverse provides the shared data foundation underneath the applications. Accounts, contacts, leads, opportunities, cases, activities, relationships, permissions, and business rules can all live within this structured environment. In this episode of M365 FM, Mirko Peters explains what Dataverse actually is, how Dynamics 365 uses it, and how the same business data can power Power Apps, Power Automate, Power BI, and other connected processes. WHAT IS MICROSOFT DATAVERSE?  Microsoft Dataverse is Microsoft's cloud data platform for structured business information. Instead of keeping customer and operational data across disconnected spreadsheets, lists, emails, and applications, Dataverse provides a common place where approved business applications can work with structured information. Think of Dynamics 365 as an office building. Sales, Customer Service, and other applications are the rooms where employees work. Dataverse is the filing system, structure, and rules behind those rooms. The objective is to reduce unnecessary copies of the same business information and provide applications with a shared foundation. ONE CUSTOMER INSTEAD OF MULTIPLE COPIES Consider a company where Sales stores customer information in one system, Support maintains another customer list, Finance keeps another version, and additional information lives inside shared mailboxes and spreadsheets. When the customer's address or contact information changes, those copies quickly become inconsistent. With Dataverse, approved applications can work with the same customer information. A customer used by Dynamics 365 Sales can also provide context when that customer contacts Dynamics 365 Customer Service. Instead of asking which customer list is correct, teams can work around a shared reference point. DATAVERSE TABLES EXPLAINED Dataverse organizes business information into tables. An Account table can contain companies. Contacts can contain individual people. Leads represent potential customers, Cases can represent customer support requests, and Activities can represent calls, emails, appointments, and tasks. Microsoft provides standard tables for common business concepts, while organizations can create custom tables when they need to represent information specific to their business. A training company, for example, could create tables for courses and certificates, while a property company might create tables for buildings and inspections. ROWS AND COLUMNS Each table contains rows representing individual pieces of business information. One Contact row might represent a particular person. Columns then describe the information associated with that person, such as first name, last name, email address, phone number, job title, company, owner, and status. This structured approach gives information a predictable shape. Applications know what each value represents, reports can analyze it consistently, and automation can react when specific information changes. STANDARD VS CUSTOM TABLES Organizations should generally start with standard Dataverse tables when those structures already represent the business concept they need. Creating several custom tables that all represent slightly different versions of "customer" can recreate the same data fragmentation Dataverse is intended to reduce. Custom tables become valuable when the organization genuinely has business information that doesn't fit existing standard structures. The objective is a data model people can understand and reuse across applications. RELATIONSHIPS CONNECT BUSINESS INFORMATION Tables become significantly more useful when they are connected through relationships. A Contact can belong to an Account. A Case can connect to the customer who created the support request. An Opportunity can connect to calls, emails, appointments, and tasks associated with the sales process. Instead of repeatedly copying company information into every related record, relationships maintain connections between the information. If a company's address changes, the Account can be updated while related Contacts continue pointing toward the same company. TABLES, COLUMNS AND ROWS VS OLDER TERMINOLOGY Older Dynamics 365 and Dataverse documentation may use different terminology. What Microsoft now calls a table was previously commonly called an entity. A column was called a field, and a row was commonly called a record. Understanding both sets of terminology can make older documentation and training material easier to follow. ㅤ SECURITY STARTS WITH IDENTITY Shared information doesn't mean everybody should have access to everything. Microsoft Entra ID provides the identity used to determine who is working with Dataverse. Dataverse can then apply additional security controls governing what that person is permitted to do with business information. Think of Entra ID as the reception desk verifying who entered the building, while Dataverse security determines which rooms, filing cabinets, and information that person can access after entering. ㅤ SECURITY ROLES Security roles provide permissions associated with different jobs and responsibilities. Sales representatives might receive permissions for Accounts, Contacts, Leads, and Opportunities. Customer service agents might work with Cases without receiving the same permissions over sales opportunities. Permissions can govern operations such as reading, creating, updating, and deleting information. Because these controls exist around the underlying data, security doesn't need to depend exclusively on hiding buttons inside individual applications. ㅤ ROW AND COLUMN LEVEL SECURITY Access can become more granular than simply allowing or denying access to an entire table. Row-level security can determine which individual rows a person can access. A salesperson might only work with customers they own, while a sales manager can access customers belonging to the wider team. Column-level security can protect particularly sensitive information within an otherwise accessible row. This provides organizations with more control over who can access particular business information. ㅤ Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

    Dynamics 365 Dataverse Integration - Simply Explained
مشاهدة الكل (٩٥٩)

التقييمات والمراجعات

٥
من ٥
‫٣ من التقييمات‬

حول

Welcome to the M365.FM — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365.FM brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. M365.FM is part of the M365-Show Network. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

المعلومات

  • صناع العمل
    Mirko Peters - Founder of m365.fm, m365.show and m365con.net
  • سنوات النشاط
    ٢٠٢٥ - ٢٠٢٦
  • الحلقات
    ٩٥٩
  • التقييم
    ملائم
  • حقوق النشر
    © Copyright Mirko Peters / m365.fm - Part of the m365.show Network - News, tips, and best practices for Microsoft 365 admins
  • موقع البرنامج على الويب
    M365.FM - Modern work, security, and productivity with Microsoft 365

قد يعجبك أيضًا