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 →

☼ Light ☶ Sepia ☽ Dark 01Summary Account data in CRM is rarely in one place, with revenue, pipeline, quotes, and years of meeting notes spread across separate records. We built a one-click Account Intelligence Report that runs inside Dynamics 365 and assembles the complete account picture on screen in seconds. With a second click, an AI analyst reviews every appointment note to produce a plain-language engagement history, current status, open commitments on both sides, and talking points for the next meeting. The complete report, combining facts and AI insights, can then be exported as a branded, editable Microsoft Word document with a single click. Everything runs within the signed-in user’s existing Dynamics session, with no new servers or third-party libraries, while inheriting the user’s existing data permissions by design. Table of Contents 01Summary→ 02The 40-Minute Problem→ 03Solution Overview→ 04Technical Approach→ 05Impact→ 06Conclusion→ 07Let’s Talk→ 02The 40-Minute Problem Picture an account manager thirty minutes before a quarterly business review with a customer they have worked with for three years. The relationship is rich. The context, though, is buried. The revenue figure sits on the Account. The live pipeline is spread across a handful of opportunity records. There are a dozen quotes from the last two quarters, most of them not tracked and easy to forget. Then there are the meeting notes. Dozens of appointments, each with its own thread of what was said, promised, and agreed. None of that is missing. It is all in the CRM. The trouble is that it is everywhere at once. To reconstruct the story of an account, someone has to open twenty records, read between them, and hold the whole picture in their head. So they do not bother. They skim the last two meetings, walk in half prepared, and the deeper context stays invisible until it becomes a problem. This is not a data problem in the sense of not capturing enough. It is a synthesis problem. The organisation already holds the intelligence. It simply has no fast, trustworthy way to assemble it into something a human can act on before a meeting begins. ⓘThe real bottleneck The hardest work in account management is rarely finding the information. It is pulling it together. Connecting revenue, pipeline, and history into one coherent, current view, at the exact moment you need it, is where most of the effort actually goes. 03Solution Overview We set out to solve that synthesis problem with the smallest possible footprint, for a U.S.-based manufacturing facility running Dynamics 365 Sales. The result is a single command on the Account form called the Account Intelligence Report. From the account you are already looking at, one click opens a clean, paper-style report inside the application. It is not another tab to manage or another system to log into. It is part of the CRM you already use. The report does three things, in order: It gathers. In seconds it pulls the account’s revenue, its sales-revenue targets, the most relevant quotes, every open opportunity, and all related appointments together with their notes. It reads. A second click sends those meeting notes to an AI model that writes up the account’s engagement history and distils it into clear, decision-ready insights. It delivers. One more click produces a professional, branded Word document, a finished brief you can email, print, or bring into the meeting. The whole experience is built to feel instant. You stay in the flow of your work, and the report comes to you. What the Report Actually Contains The report is organised the way an account manager actually thinks about an account, not the way a database is organised. At the top is a compact dashboard. Revenue, quote totals, open opportunities, and appointment counts sit at a glance. Below that is the structured document itself. Revenue and pipeline at a glance The opening section brings together the numbers that frame the relationship: the customer’s revenue, the potential opportunity, budget and revenue year-to-date, and the estimated revenue outlook. This single block replaces what would otherwise mean cross-referencing the Account record with a separate sales-revenue table. Quotes and open opportunities Next is a focused view of quotes from the last six months, including those not tracked quotes that quietly accumulate and are easy to lose, alongside every open opportunity in the same window, with its stage, originating lead, product segment, and bid date. Totals calculate automatically, so pipeline value is always visible without a manual add-up. Every related appointment, with its notes This is where the report earns its keep. It lists all related appointments and, crucially, lets you expand any meeting to read exactly what was discussed. Attendees are pulled out, and the full substance of each meeting is available inline. For a customer with a long history, this becomes a navigable timeline of the entire relationship, every visit, call, and commitment, in one place. 💡Why appointments are the hard part Meeting history is usually collected through two different paths in CRM. Sometimes a customer is recorded as a participant, sometimes as the subject of the meeting. The report queries both, then merges and de-duplicates the results, so nothing is missed and nothing is doubled. 04Technical Approach The AI Analyst: Years of Notes in One Read Gathering the notes is only half the battle. Someone still has to read them. The "Get AI Insights" action does exactly that. It takes the full set of appointment notes for the account and asks an AI model, Azure OpenAI, to do what a thorough colleague would do before a meeting: read everything, then tell you what matters. The output is deliberately structured, so it slots straight into the report rather than producing a vague paragraph. It returns six things: Engagement history — a single flowing narrative of the relationship from the earliest meeting to the most recent, with dates, attendees, and the key decisions along the way. Current status — a direct read on where things stand and the overall momentum, in two to four points. … Continue reading Dynamics 365 Sales AI: Turn CRM Data into Dynamic Word Reports for Executive Insights →

01Summary A manufacturer of custom steel windows and doors was running its entire sales pipeline through a default BPF that ended at the Opportunity stage. Once a deal was won, production tracking moved to spreadsheets and email threads. Sales could not tell a client where their order stood. Operations had no consolidated view of which orders were in engineering review, which were in fabrication, and which were waiting on finishing. CloudFronts designed and implemented a multi-entity Business Process Flow in D365 Sales that spans Lead, Opportunity, and a custom Order Fulfillment entity. The BPF now tracks every order through its production stages, from engineering sign-off through fabrication, finishing, quality inspection, and dispatch. Sales sees order status without calling the shop floor. Operations reports on production bottlenecks across the full pipeline. Table of Contents 01Summary→ 02Business Challenges→ 03Solution Overview→ 04Technical Approach→ 05Business Impact→ 06Conclusion→ 07Connect With Us→ 02About the Customer A manufacturer of custom steel windows and doors uses Dynamics 365 Sales to manage its customer relationships and order pipeline. The business builds bespoke, high-specification products where every order is unique, every unit requires individual engineering, and every delivery carries a direct reputational commitment to the client. 02Business Challenges Every product this manufacturer builds is bespoke. Every steel window and door is individually engineered, fabricated, and finished to specification. Every delivery carries a direct reputational commitment to the end client, whether that client is a homeowner, an architect, or a commercial developer. The sales cycle does not end when the deal is won. It ends when the product is delivered, installed, and accepted. The D365 Sales environment had been live for over a year when CloudFronts began the engagement. The standard Lead-to-Opportunity BPF was in place. The problems started the moment a deal moved to Won. Production tracking lived outside the CRM. Once an opportunity was marked as Won, the order moved to a shared spreadsheet. The operations team tracked engineering review, fabrication, finishing, and dispatch dates in separate columns. Version control was manual. Updates were delayed. Sales had no visibility into order status. When a client called to ask where their order was, the sales rep had to phone or email the shop floor. The answer took hours, sometimes a day. For a business built on bespoke, high-specification products, that delay eroded the client experience. No single view from inquiry to delivery. Management could report on pipeline (leads and opportunities) or on production (the spreadsheet), but not on the full journey from first inquiry to delivered product. There was no way to measure the total cycle time from lead capture to dispatch, or to identify where orders stalled. The lead form had accumulated 40+ custom fields. Contact data, project specifications, engineering notes, and production preferences were all on the Lead entity. Sellers filling in a new inquiry from a trade show had to scroll past glazing specification fields that only mattered later. The form was slow to load and difficult to use on mobile. No distinction between project types in the process flow. A residential architect requesting a quote for three casement windows and a commercial developer scoping a 200-unit curtain wall project followed the same BPF stages. The qualification criteria, production complexity, and delivery timelines are fundamentally different, but the system treated them identically. 03Solution Overview CloudFronts designed a multi-entity Business Process Flow that extends the sales process beyond the Opportunity into production. The BPF spans three entities: Lead, Opportunity, and a custom Order Fulfillment entity. Instead of ending at Won, the process flow continues through the production stages that define this manufacturer’s delivery commitment: engineering review, fabrication, finishing, quality inspection, and dispatch. The Lead entity was trimmed to fewer than 15 fields. Contact details, referral source, project type (residential or commercial), and initial product interest (windows, doors, curtain walls, or mixed) are the only data captured at the lead stage. Engineering specifications, production requirements, and order details move to the entities where they belong: the Opportunity and Order Fulfillment records. The Order Fulfillment entity tracks the production lifecycle of each won deal. Each fulfillment record is linked to an Opportunity and carries its own set of production stages, dates, owners, and status fields. Sales reps see a live production status on the opportunity record without accessing the shop floor system. Operations managers see a consolidated production pipeline across all active orders, with the ability to filter by stage, project type, and expected dispatch date. ⓘWhy extend the BPF instead of building a separate production tracker? A separate production module would have created two disconnected systems: one for sales, one for operations. By extending the BPF into Order Fulfillment, the entire lifecycle from first inquiry to delivery lives in a single process flow. The sales team does not need to switch systems. Reporting joins lead source, deal value, and production cycle time in one data model. And the BPF enforces stage gates that prevent an order from advancing to fabrication before engineering sign-off is complete. 04Technical Approach Entity Model The framework uses three primary entities in the BPF and two supporting reference tables. Entity Type Purpose Key Fields Lead Standard First contact: who the lead is and where they came from Contact name, company/architect firm, referral source, project type (Residential/Commercial), initial product interest (Windows/Doors/Curtain Walls/Mixed) Opportunity Standard Deal record: commercial qualification and proposal Estimated project value, product mix, unit count, expected order date, project timeline, sales stage Order Fulfillment Custom Production lifecycle: tracks each won order through manufacturing to delivery Engineering review status, fabrication start/end dates, finishing status, quality inspection outcome, dispatch date, delivery confirmation, Opportunity lookup Entity model for the multi-entity BPF framework The Order Fulfillment entity carries a lookup to the Opportunity. When an opportunity moves to Won, the BPF transitions to a new Order Fulfillment record. This record becomes the single source of truth for production status. The Opportunity record retains the commercial data (deal value, product mix, client details), while the Order Fulfillment record tracks manufacturing progress. 💡Keep each entity focused on one job … Continue reading How a U.S.-Based Steel Windows and Doors Manufacturer Built a Multi-Entity Business Process Flow in Dynamics 365 Sales →

Introduction LS Central has its own unique way of preventing Items from being sold which is different from the standard “Blocked” option field we get on the Item Card. It also comes with detailed and refined permissions which can fit most business needs. All of this is done using another related table known as “Item Status.” Pre-requisites: Business Central OnCloud/OnPrem LS Central v16 References: Item Status (lsretail.com) How to Block Items From Sale at the POS (navisiontech.com) Configuration Open the Item Card for the Item you want to block.  Open the “Item Status” for that Item.  Click on the “Status Code” and Click on “Select from full list.”  Create a new record with code “BLOCKED” and enable all the fields. Here, you can see all the detailed controls available.  Conclusion: Thus, we saw how we can Block Items on POS in LS Central and other finer controls available at our disposal in LS Central.

Introduction: In this blog, we’ll be looking at how to reduce manual work in creating Sales Line in Business Central. For this, we’ll be using the Out of the Box feature of “Recurring Sales Lines” References: Standard Recurring Sales and Purchase Lines – Business Central | Microsoft Docs Configuration: Search for Recurring Sales Lines in Business Central global search and then click on New. Enter a Code for Identification, a short description and the Currency Code, if applicable. In the Lines, enter the Sales Line which are to be re-created. You can also define a Quantity if you want, it can be easily over-written if necessary. Go to the Customer Card for whom the Recurring Sales Line we created is going to be applicable. Then Go to Related > Sales > Recurring Sales Lines. Set the Code of the Recurring Sales Line, we just created and set the Valid From and Valid to Dates. The Insert Rec. Lines have the following options: Manual – System allows you to add the lines as and when required. Using the “Get Recurring Sales Lines” action. Automatic – System adds the recurring lines automatically whenever the Document is created. Always Ask – System shows a notification above which allows you to fetch the Recurring Lines in one click. Conclusion: Thus, we saw how to configure Recurring Sales Lines in Business Central which is a very useful tool in reducing manual work.