Summary SIP Industries is a Houston-based manufacturer of engineered components. Every new part it makes goes through a six-stage New Product Development (NPD) Business Process Flow in Dynamics 365. Most of the people who approve those stages never open the CRM. They include plant engineers and QA inspectors in India, the U.S. engineering team and customer reviewers. They replied by email, and the CRM team typed each reply into the NPD record and then clicked Next Stage by hand. We replaced that manual relay with three Power Automate flows, plus a small daily reminder flow. Each approver gets an email with one button, which opens a pre-filled HTML form that needs no login. The flows save the answers to Dataverse and move the stage forward once its conditions are met. Nobody keys in approvals or moves stages by hand any more. SI SIP IndustriesEngineered components manufacturer, Houston, Texas Industry Manufacturing Region United States StackDynamics 365 SalesPower AutomateMicrosoft DataverseSharePoint Table of Contents Summary→ Business Challenges→ Solution Overview→ Technical Approach→ Business Impact→ Conclusion→ Connect With Us→ Business Challenges SIP already had a working NPD Business Process Flow on a custom New Product Development table. The stage design was sound. The time went into one recurring loop that the CRM team ran by hand for every stage of every part. New Product Development View A CRM user emailed the approver for that stage and attached or linked the latest drawing The approver replied in the thread, often with a one-line "go ahead" and an estimate buried in the text The CRM user read the reply and typed the decision, notes and dates into the NPD record The CRM user opened the Business Process Flow and clicked Next Stage The CRM user emailed the next team to tell them it was their turn That loop broke down in four specific places. Licensing the approvers was never realistic. A customer reviewer who signs off a sample twice a year does not need a Dynamics 365 seat, training and a password to remember Some stages close on more than one decision. Feasibility needs feasibility approval, engineering approval and a created engineering drawing. First Article Inspection needs both the India QA team and the U.S. engineering team. These approvals arrived in any order and someone had to keep track of which were still missing Drawing approvals stalled for weeks. Nothing reminded the reviewer, so follow-up depended on a CRM user remembering to chase The audit trail lived in personal mailboxes. Opening the NPD record told you the current stage, not who approved it or when Solution Overview We put an email-driven approval layer on top of the existing NPD process. When an NPD record reaches a stage, Dynamics 365 emails the approver for that stage. The email is written for that stage, so a Pattern request shows pattern details and an inspection request shows inspection details. It ends with one button. Engineering Approval Request Received in Outlook The button opens a web form in the approver’s browser, already filled in with whatever the NPD record holds. The form lists the product’s SharePoint documents and accepts new uploads. The approver picks a decision, adds notes and submits. Feasibility Approval Form Dynamics 365 then saves the answers into the right NPD fields. It moves the process to the next stage if that stage’s conditions are now complete, and the next approver gets their email. A rejection or a "Requires Changes" answer keeps the record in its current stage and notifies the NPD team instead. ⓘWho still uses the CRM The NPD team still works in Dynamics 365 and can set any field directly. The automation responds to changes made in the CRM in the same way as changes made through a form. Technical Approach Architecture at a Glance TriggerNPD record savedStatus or an approval field changes Flow 1Send Approval EmailTracked email with a stage-specific button Flow 2Show Approval FormReturns pre-filled HTML for the stage Flow 3Save Approval ResponseWrites answers and uploads to Dataverse and SharePoint DataverseBPF advancesNext stage starts and Flow 1 fires again These three flows run the entire approval loop, and the loop closes itself. When Flow 3 saves an answer, the NPD record changes, and that change triggers Flow 1 again. Flow 1 then either moves a stage whose conditions are now all met or sends the next approver their email. Alongside the loop, a separate reminder flow runs once a day and chases open drawing approvals. Six Stages, Eight Forms New Product Development Form Stage Approver Form Captures Stage Closes When Feasibility Feasibility team, Engineering team Feasibility approval, engineering approval, notes, estimated development timeline, estimated tooling cost Both approvals recorded and engineering drawing created Drawing Approval Drawing reviewer Drawing received, sample required, feedback, approval Reviewer approves on the form Pattern Plant and tooling team Pattern status, foundry, notes Pattern Status set to Ready For Inspection First Article Inspection India QA, U.S. engineering FAI approval and date, sample sent to U.S., shipment date, U.S. approval and comments Both India and U.S. approvals recorded Customer Approval Customer Yes, No or Requires Changes, with the approval date set automatically Customer answers Yes Production Production team Release notification Final stage NPD stages, approvers and the condition that closes each one Six stages produce eight forms because two stages have two separate approvers. Feasibility has one form for the feasibility team and one for engineering. First Article Inspection has one for India QA and one for U.S. engineering. Each form is identified by a stage key: feasibility, engineering, drawing, pattern, fai, fai_us, customer and production. Each form shows only the fields that apply to the record. The India FAI form asks whether a sample was sent to the U.S. only when the drawing reviewer marked a sample as required. It asks for the shipment date only after the sample has gone. Why the Form Lives Inside Power Automate Criteria Power Pages Canvas App Our choiceHTML form from Power Automate Approver opens it without signing in ✗ ✗ ✓ No … Continue reading How a U.S. Castings Manufacturer Saved Time by Updating Dynamics 365 Without Logging Into CRM →

Summary The sales team at commercial laundry and linen rental organization could open any record in Dynamics 365 and still could not answer how much of the open book sat in healthcare. Sector was never a field on a deal, it was four boolean flags on the product, three joins away from the quote a manager wanted to group. We replaced the standard sales dashboards with Custom Sales Dashboard that reads the Dataverse Web API directly, rolls sector up through the line items, and puts leads, opportunities, quotes and signed contracts under a single set of filters. Every tile, cell and chart segment opens the records behind it and exports to Excel with real numbers and real dates. Table of Contents Summary→ Business Challenges→ Solution Overview→ Technical Approach→ Impact→ Conclusion→ Get in touch→ Business Challenges Commercial laundry and linen rental organization runs multiple laundries, called plants in the CRM, and quotes work by the weight a customer sends each week. A deal is a weekly tonnage and a weekly dollar figure before it is anything else, which is why the standard sales charts had so little to say about it. The reporting asks were ordinary. The data model underneath them was not, and every ask broke on a different part of it. Sector is not stored on the lead, opportunity, quote or order. It is independent flags on the product record: healthcare, motel, garments, etc. A chart grouped on the quote has no column to group by A single product can carry more than one flag, so one quote can legitimately belong to two sectors. Grouping without a rule double counts the same dollars Total Amount reads 0.00 on every quote and every order in the org. All money sits in annualrevenue and weeklyrevenue, which the standard sales charts and rollups do not read Contracts are salesorder records. The out of the box contract table is empty, so anything pointed at it returns nothing at all The plant lookup laundry is populated on roughly six quotes in ten. The rest only know their laundry through the originating opportunity Orders copied from an accepted quote frequently carry no line items of their own, so a product level report built on order lines quietly loses them Managers wanted one choice of sector, sales person or plant to move leads, opportunities, quotes and contracts together. Standard dashboards filter each chart against its own entity Nobody could see the forward book: which signed contracts start in the next twenty weeks, and what weekly tonnage each start week brings ⚠The real blocker Every one of these needs a value computed from grandchild rows, from the quote down to its lines down to the product flags. The chart designer groups on fields that exist on the record being charted, and this one does not exist anywhere. Solution Overview We built one page that lives inside the CRM as a web resource. It opens like any other dashboard, signs the user in with the session they already have, and reads live records rather than a nightly copy. The page carries six tabs. Overview holds a pipeline matrix and the stage, sector, sales person and plant mix. Pipeline Activity plots leads and quotes created per week for the last fifteen weeks. Contracts Won shows the forward book by contract start week. Win and Loss compares closed won against closed lost by value and by count. Approvals and Activities measures how long contract, logistics and freight rate decisions take. Reports lists contracted and quoted stock at product line level. Three filters at the top, sector, sales person and plant, drive every chart, tile and table on every tab at once A fourth filter, customer, appears only on the Reports tab because it only narrows those two tables Clicking any chart segment, matrix cell or tile opens a drawer listing the records behind that exact number Each row in the drawer links to the real CRM form, and the whole selection exports to Excel with numbers as numbers and dates as dates ⓘWhy the drill through mattered more than the charts A sales manager who cannot see the eleven contracts behind a bar will not act on the bar. Registering the source records for every visual was the difference between a picture and a working tool. Technical Approach Where the page runs The dashboard is a single HTML web resource, customDashboard, shipped in the main solution. Running inside the model driven app means it inherits the user’s authentication and their record level security, so a sales person sees their own scope without us writing a line of security code. It resolves the org URL from parent.Xrm.Utility.getGlobalContext() and falls back to window.location.origin when it is opened outside a form, which is what makes local debugging possible. SourceDataverse Web API v9.2Live reads with the signed in user’s context Load14 parallel queriesOne Promise.all on page open IndexLookup maps and sector indexProduct flags resolved once, then cached RenderMatrix, tiles and Chart.jsRedrawn in memory on every filter change ActDrawer and XLSX exportRecords behind the number, typed for Excel Everything loads once. Accounts, factories, depots, leads, opportunities, quotes, orders, the three line item tables, products, freight rates, delivery point risk assessments and activities all come down in a single Promise.all, and every later interaction is a filter over arrays already in memory. Changing a filter costs nothing on the network. Rolling sector up from the product The rollup walks the line items of a quote, order or opportunity, reads the flags off each product, and weights each sector by line weight times quantity. The heaviest sector becomes the primary, which is what the breakdown charts group on so the totals stay additive. The full list is kept separately and is what the sector filter tests against, so a quote that touches healthcare and motel appears under both filters and is counted once in the donut. cf_customDashboard.html, sector rollupjavascript function rollupSectors(lines, productIdField) { const weight = {}; lines.forEach(l => { const sectors = PRODUCT_SECTORS[String(l[productIdField] || ”).toLowerCase()] … Continue reading How an Australia-Based Commercial Laundry Company Built a Custom Dynamics 365 Sales Dashboard Beyond Standard Reporting →

Introduction LS Central allows us to use HTML content on the POS which includes both Text and Images. Users can add extra information related to the Items here which can assist in the POS Users to make the sales much more efficiently. In this blog, I’ll be demonstrating how to configure the same. References https://help.lscentral.lsretail.com/Content/Fields/T_10001411.htm Pre-requisites Microsoft Dynamics 365 Business Central LS Central Configuration Open Business Central and search for POS Terminals. Open the POS Terminal for the current Store and set the “Item HTML” and “Item Image” property to true. Search for Retail Items and open the Item you want to add description and image for. Open the Item Card and Go to Navigate -> Master Data -> Item HTML. Here you can specify the description for the Item that you want to be displayed on the POS and click on Save. For instance: After that go to Navigate -> Master Data -> Images and click on New. Click on Import and select the Image of that Item and then Click on OK. Go to POS and search for the Item. Double Click on the description of that Item to see the Image and the HTML Content. You can even embed Videos if required! Conclusion: Thus, in this blog we saw how we can utilize HTML content on POS. As an additional side note I’d like to mention even using Javascript is possible, to a certain extent, so for those who are curious you can even create basic games for it. Thanks for reading!