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 This post started with a real request. A Netherlands-based sustainability certification company that runs its certification programme on Dynamics 365 wanted the certificates it issues to come straight out of the CRM, instead of being rebuilt by hand in a document every time. The problem itself is common. Certification bodies, testing labs and manufacturers issue certificates every day, and in most organisations that still means a Word template, a lot of copy and paste, and a PDF sent by email. The data that belongs on the certificate already lives in Dynamics 365, so why can’t the certificate come straight from the record? In this blog we build exactly that. A Generate Certificate button on a Dataverse form calls a Custom API, a small plugin hands the data to an Azure Function, and a branded, print-ready PDF comes back in about four seconds. Today the PDF is stored on the record as a base64 string, previewed and downloaded right on the form. Because the renderer only returns bytes, sending the same file to SharePoint, Azure Blob Storage or an email is a change to one step, not a rebuild. In This Blog This blog walks through a complete, working certificate generator for Dynamics 365, from the data model to the button, using a product certification scenario. The Scenario: A certification body issues product certificates and needs every one to be accurate, branded and traceable. The Approach: Keep the data in Dataverse, render the PDF in an Azure Function, and connect them with a Custom API. The Action: One click on the form produces the certificate, stores it on the record and shows a live preview. The Outcome: No manual formatting, no retyping, no per-document licence fees, and a design that can later publish to SharePoint or Blob storage. Table of Contents Summary→ In This Blog→ Business Challenges→ Solution Overview→ Technical Approach→ Impact→ Conclusion→ FAQ→ Get in Touch→ Business Challenges A certificate is a legal statement: this product, made by this company, meets this standard, from this date to that date. When it is produced by hand, the risks are small individually and expensive together. Copy and paste errors. Product names, model numbers and expiry dates are retyped from the CRM into a document. One wrong digit on an issued certificate means a reissue and an awkward conversation. Template drift. Every coordinator keeps a slightly different copy of the Word template, so logos, wording and signatories quietly diverge. No trail. Once the PDF leaves someone’s desktop there is no record of which version was produced, when, or from which data. Platform limits. Dataverse plugins run in a sandbox that cannot lay out and paginate a PDF, and a JavaScript-only solution would expose service keys to every user’s browser. Before Word template and email Values retyped from the record Layout depends on who made it File lives in someone’s Downloads folder No link back to the CRM record After One click on the record Values read directly from Dataverse One design, driven by configuration PDF stored on the record with its hash Preview and download on the same form Solution Overview The demo uses a fictional certification body, Contoso Product Assurance, which certifies products made by manufacturer accounts against its own published standards. The whole flow runs from a single button: FormGenerate CertificateCommand bar button on the Product Certificate form DataverseCustom APIBound action cf_GenerateCertificate PluginCollect the dataCertificate, product, holder and standard AzureRender the PDFFunction returns the file as base64 RecordStore and previewBase64 saved, previewed and downloadable Architecture One click on the form, one PDF back on the record. The dashed box is where SharePoint, Blob storage or email plug in later. Data modelThree custom tables (Standard, Product, Certificate) plus the standard Account table for manufacturers. Custom API and pluginOne server-side entry point. The function key never reaches the browser. Azure FunctionA .NET 10 renderer on the Consumption plan. Vector PDF, embedded fonts, QR code. Form experienceGenerate and Download buttons plus an inline PDF preview panel. A certificate generated from Dataverse data. Every value on it comes from the record; nothing is typed. Technical Approach 1. The data model Everything lives in one solution, CFCertificateGeneration, so it moves between environments as a unit. Table Purpose Key columns Certification Standard What products are assessed against Code, Version, Default Scope, Validity (Months) Certified Product What is being certified Product Number, Manufacturer (Account), Category Product Certificate The issued certificate Auto-numbered Certificate Number, Status, Issue and Expiry Date, Product, Standard, Holder, Signatory, PDF (Base64), File Name, SHA-256, Generated On The Product Certification app: every certificate with its status, validity and when it was last generated. The certificate number is a Dataverse auto-number column with the format CPA-{DATETIMEUTC:yyyy}-{SEQNUM:5}, so numbering is guaranteed unique by the platform rather than by a person. The certificate holder defaults to the product’s manufacturer and can be overridden when a brand owner holds the certificate for a product someone else makes. 2. The renderer The PDF is drawn with SkiaSharp and the QR code with QRCoder, both open source. The same drawing code targets either a PDF page or a PNG bitmap, which means the image you check during development is exactly what the customer receives. Text is real, selectable text in embedded fonts, every graphic is a vector shape rather than an image, and long product names shrink to fit instead of overflowing the frame. CertificateRenderer.csC# public RenderedCertificate RenderPdf(CertificateRequest request) { Validate(request); using var output = new MemoryStream(); using (var document = SKDocument.CreatePdf(output, metadata)) { var canvas = document.BeginPage(842f, 595f); // A4 landscape, in points Draw(canvas, request); // same code paints the PNG preview document.EndPage(); document.Close(); } return new RenderedCertificate(output.ToArray(), FileNameFor(request.CertificateNumber)); } Vector from edge to edge, so quality never breaks There is not a single raster image in the certificate. Every line of text is real text in an embedded font, and the frame, the seal, the dividers and even the QR code are drawn as vector shapes. Zoom to 800%, print it on A3 or project it on a … Continue reading How a Sustainability Certification Nonprofit Automated Certificate Generation in Dynamics 365 →

Summary A home loan bank in the Maldives came to us needing legal, customer-facing reports for loan statements and overdue notices that had to reflect exact facility figures while matching the bank’s letterhead and legal wording. Traditional RDLC-based report development would have created significant IT dependency and delay for a document like this. Instead, our team used Word-based report layouts in Microsoft Dynamics 365 Business Central, which let us design the legal notice in a familiar document tool while Business Central handled populating it with live facility and customer data. We mapped the bank’s Business Central fields into a Word template, tested it against real facility scenarios, and delivered a working legal report in approximately two days, which is a turnaround that would traditionally take weeks with RDLC. This article walks through how we approached the build, using a sanitized sample report in place of the client’s confidential documents, and explains when we’d recommend Word over RDLC for a bank’s reporting needs. Table of Contents Introduction The Problem: IT Bottlenecks and Delayed Customer Documents The Word-Based Reporting Solution 3.1 How the Word-Based Approach Works 3.2 Creating the Word Template 3.3 Mapping Business Central Fields 3.4 Testing and Delivering the Report Sample Walkthrough: The Legal Report We Built Word Report vs. RDLC Report Time and Effort Comparison Why Banking Teams Benefit from Word Reports What Types of Banking Documents Work Best? Business Benefits When RDLC Is Still the Better Choice FAQs Conclusion About the Author Introduction Legal, customer-facing documents are one of the most sensitive parts of any lending business. A home loan bank in the Maldives came to us needing exactly this kind of document: a legal report covering a loan statement and overdue notice, which had to reflect exact facility figures, carry the correct legal clauses, and match the bank’s letterhead, all while pulling live data straight out of Business Central. Producing a document like this inside Microsoft Dynamics 365 Business Central can easily turn into a multi-week project if it’s built the traditional way. RDLC-based reporting usually means a developer has to build and maintain the report layout, write or modify code, configure data sources, and run several rounds of testing before the document is ready to go out to a customer. For a fairly standard legal document, like a loan statement or overdue notice, that kind of timeline is hard to justify. So instead of taking the client down the RDLC route, we proposed another option: Word-based report layouts. Word templates let us design the layout of the legal report in a tool the bank’s own team could later maintain, while Business Central handled populating it with the correct facility and customer data. The key idea: We designed the legal report’s layout and wording in Word, and let Business Central handle pulling in the correct facility data, so the client wasn’t locked into a developer for every future change. This article walks through how we built it, using a sanitized sample report in place of the client’s confidential documents, and explains how a report that would traditionally take weeks of RDLC development was designed, mapped, and delivered in approximately two days using a Word-based approach. The Problem: IT Bottlenecks and Delayed Customer Documents When the client first came to us, their existing experience with reporting was the same one many banks run into: a dependency between operations teams and technical teams that turns a simple document request into a long wait. The kind of request that used to happen internally looked something like this: “Hey, can we get a loan statement that shows the customer’s outstanding EMI, fines, and facility balance in one clean document?” “Sure, I’ll put in a ticket with IT.” [Two weeks later…] “The statement is almost done. It should be ready in another couple of weeks.” [Four weeks later…] “It’s finally here. Wait… the layout doesn’t match our branch letterhead format.” This kind of situation can happen when a relatively standard customer document becomes dependent on development resources. Why Do These Delays Happen? RDLC report layouts can require specialized development knowledge. Developers need time to configure data sources and implement the required reporting logic. Testing and troubleshooting can add additional development cycles. Small formatting changes such as a different overdue clause or a revised disclaimer may require technical assistance. Future modifications can place the document back into the development queue. Branch or collections staff may resort to manual, Word- or Excel-based workarounds while waiting for the official document. The result is a disconnect between the people who understand exactly what a legal notice or statement needs to say and the people responsible for implementing it in the system. The question we asked the client: What if your own operations or collections team could design and maintain these legal documents, using a tool they already know instead of relying on a developer for every change? The Word-Based Reporting Solution Microsoft Word was already familiar to the bank’s operations staff, so we proposed taking advantage of that. Business Central supports using Word templates directly as report layouts, which meant we didn’t need to build the legal report’s presentation through RDLC at all. Instead of developing the entire document presentation through RDLC, we designed the layout directly in Word and mapped Business Central’s available facility and customer data to the appropriate fields within that template. The solution: We used Word for the legal report’s presentation and Business Central for the facility data behind it. This separated document design from complex layout development and gave the client’s operations team greater control over formatting, tone, and compliance wording going forward. How We Approached the Build Our overall process was straightforward: Design the legal report layout using Microsoft Word. Add the required data fields to the Word template. Map those fields to the appropriate Business Central data. Run the report and let Business Central populate the template. Review the generated document with the client and adjust the layout where needed. The important distinction is that the document’s visual … Continue reading How We Built Legal Reports in Word on Business Central for a Home Loan Bank in the Maldives →

Site-Level Master Planning Summary Multi-plant manufacturers often run Planning Optimization as one global master plan that nets supply and demand across every site and warehouse together. That’s fine right up until each plant has its own planners, its own coverage rules, and its own idea of when on-hand stock should get consumed first. Microsoft’s “Plan for a single site or warehouse in Planning Optimization” feature (Feature Management, available from version 10.0.44) fixes this at the source: a master plan can now filter on stock dimensions (site, warehouse, batch), not just items, so the plan’s entire universe of supply, demand, and coverage data can be scoped to one location. We rolled this out for a North American truck manufacturer running several plants under a single legacy global plan. Splitting planning by site let each plant’s team run and own a plan tuned to what’s actually stocked and consumed there, without touching anyone else’s numbers. On this page 01The problem with one global plan 02What the feature actually changes 03Turning it on 04Building a plan filter on stock dimensions 05Two plants, two different plans 06Running the site-specific plan 07The catch: full filter only 08FAQs 09Conclusion The problem with one global plan A single master plan covering every plant is simple to set up and easy to explain: one run, one set of planned orders, one schedule. It’s also where the friction starts once a business runs more than one plant with different products, different suppliers, and different teams responsible for each. Planners at one plant end up looking at planned orders shaped in part by another plant’s on-hand corrections and forecast edits. A coverage code change made for one site’s parts can shift output for a site that has nothing to do with it. And because it’s one run, a data issue at any single plant (a bad forecast import, a stuck transaction) can delay the plan for every other plant waiting on the same run to finish. What the feature actually changes Master plans have always supported an item filter. What’s new is a Stock Dimensions table sitting alongside the Items table inside the plan filter, meaning a plan can now be scoped by Site, Warehouse, Batch number, or any other inventory dimension, not just by which items it considers. That distinction matters: this isn’t a coverage-code setting that changes how the plan computes numbers for items it already sees. It changes what the plan sees in the first place. The filter cascades to every planning input, including inventory transactions, forecasts, and item coverage settings like safety stock. Two plans with the same items can end up looking at entirely different supply and demand once their stock-dimension filters diverge. Turning it on The feature ships behind Feature Management, disabled by default: 1Open the Feature Management workspace and find Plan for a single site or warehouse in Planning Optimization. 2Enable it. No separate deployment step is needed; the new filter option appears immediately under Master Planning > Setup > Plans > Master Plans. Building a plan filter on stock dimensions With the feature enabled, scoping a plan to one plant is a setup task, not a code change: 1Open or create a master plan under Master Planning > Setup > Plans > Master Plans. 2Open Plan Filter. The Stock Dimensions table now appears alongside the Items table, and any inventory dimension is selectable as a filter field. 3Add the dimension that defines this plant’s scope (typically Site and Warehouse) and set the values that belong to it. Two plants, two different plans The client’s plants didn’t just need separate scopes; they needed separate policies. One plant runs standard assembly parts with no lot tracking; another runs batch-tracked, shelf-life-sensitive components that need on-hand stock consumed before anything else. The stock-dimension filter made both plans possible from the same master plan setup, configured independently: Plant A: Chassis Assembly Filter: Site = 1, Warehouse = WH-CHASSIS Includes on-hand stock and stock transactions No batch dimension; parts aren’t lot-tracked here Standard pegging behavior Plant B: Engine Components Filter: Site = 2, Warehouse = WH-ENGINE, plus Batch number Override Pegging Sequence enabled: on-hand consumed before other supply Shelf dates respected for batch-tracked, perishable-sensitive components Completely independent run schedule from Plant A Neither configuration affects the other. Plant B’s shelf-life logic never touches Plant A’s parts, and Plant A’s simpler setup isn’t forced to carry batch-level complexity it doesn’t need. “A single global plan optimizes for the business on paper. Separate site-level plans optimize for the planners who actually have to run them.” Running the site-specific plan From Master Planning > Run > Master Planning (or the Master Planning workspace), select the plan for the plant you want to run. The system generates planned orders only within that plan’s stock-dimension scope, and nothing from other sites enters the calculation. The standard item filter is still available at run time to narrow further, or it can be left blank to run every item within the plan’s scope. The catch: full filter only This is the detail that caught our planning team off guard the first time: stock-dimension scoping only works through the master plan’s own Plan Filter, not through the ad hoc runtime dialog filter. Open that runtime dialog and only the Items table is available; Site, Warehouse, and Batch simply aren’t selectable there. Practical implication: planners can’t improvise a one-off site-scoped run from the run dialog. Every site or warehouse that needs its own independent plan needs its own master plan record, configured ahead of time, not a flexible plan filtered differently run to run. FAQs 1Does this replace coverage groups or item coverage settings? No. Coverage codes still govern how the plan calculates replenishment for the items it sees. This feature governs what the plan sees in the first place: the stock-dimension filter applies before coverage logic runs. 2Can supply and demand for one item get double-counted across two site plans? Not if the filters are built to be mutually exclusive: different Site/Warehouse combinations with no … Continue reading How a Leading North American Commercial Vehicle Manufacturer Scoped Master Planning to a Single Site or Warehouse in Dynamics 365 Finance & Supply Chain Management →

Summary In Business Central, users may need to view relevant purchase invoice details directly from General Ledger Entries for better transaction visibility and traceability. This enhancement was implemented based on requirements identified across multiple Business Central implementations, including projects for a leading UAE-based consortium and a financial institution in the Maldives. The solution enables purchase invoice details to be automatically captured against relevant General Ledger Entries for new transactions, while also providing an option to update previously posted entries. This helps finance users quickly identify the related invoice information without having to navigate through multiple pages or documents. Related Case Studies: Emirates Consortium – Customer Success HDFC PLC – D365 Business Central Integrated with Loan Management Table of Contents Introduction Understanding the Business Requirement The Challenge with Standard G/L Entry Descriptions Displaying vs. Storing the Description Designing the Solution Updating Historical G/L Entries Maintaining the Description for New Entries Implementation Approach Business Impact Frequently Asked Questions Conclusion Introduction In day-to-day financial operations, users often need to trace General Ledger Entries back to the original purchase transactions for verification, reconciliation, and reporting purposes. However, the standard General Ledger view may not always provide enough contextual information to quickly identify the details of the related purchase invoice. Based on requirements identified across multiple Business Central implementations, including projects for a leading UAE-based consortium and a financial institution operating in the Maldives, an enhancement was introduced to make relevant purchase invoice details available directly within General Ledger Entries. The enhancement improves transaction visibility by capturing the relevant purchase invoice description against the General Ledger Entry. For newly posted transactions, the information can be populated automatically, while previously posted entries can be updated through a dedicated action. This approach reduces the need for users to navigate between General Ledger Entries and posted purchase invoices, making financial review and transaction tracing more convenient and efficient. Understanding the Business Requirement From a Finance user’s perspective, the requirement was straightforward: When a user reviews a G/L Entry, the Description should provide meaningful information about the transaction. The requirement needed to work for both existing historical entries and transactions posted after the customization was introduced. 1. Historical G/L Entries Business Central may already contain a significant number of posted G/L Entries. These historical records also needed to have the enhanced description populated. Updating these entries individually would not be practical. Therefore, the solution needed to provide a controlled way to update existing G/L Entries in bulk. 2. New G/L Entries For future transactions, the description should be populated automatically during the posting process so that users do not have to manually update the G/L Entry after posting. This resulted in two key requirements: Provide a mechanism to populate descriptions for historical G/L Entries. Automatically maintain the description for newly created G/L Entries. The Challenge with Standard G/L Entry Descriptions The first question during the design was whether the required description could simply be calculated when the G/L Entry page was opened. At the page level, a value can be calculated dynamically based on related information. This approach can be useful when the requirement is simply to display additional information to the user. However, there is an important distinction between displaying a calculated value and storing that value in the underlying G/L Entry record. A page-level calculated value does not automatically become part of the underlying G/L Entry data. Therefore, although a user may see the expected description on the page, the value may not be available in the same way for other processes that directly consume the G/L Entry data. Key Design Consideration The requirement was not only to display a meaningful description. The description needed to be persisted against the G/L Entry record. Displaying vs. Storing the Description This distinction became an important part of the solution design. 1. Page-Level Calculation A page-level calculation is useful when the requirement is simply: “Show this information to the user.” The value can be generated when the page is opened without modifying the underlying G/L Entry record. 2. Persisted G/L Entry Description For this requirement, the description needed to become part of the actual G/L Entry data. The solution therefore stores the generated description directly against the G/L Entry. G/L Entry → Determine Transaction Information → Generate Description → Store in G/L Entry This approach ensures that the description remains available after the page is closed and can be consumed by other Business Central processes that use the G/L Entry record. Designing the Solution The solution was designed around two scenarios: historical G/L Entries and newly created G/L Entries. 1. Historical G/L Entries A dedicated action is provided to populate the enhanced description for existing G/L Entries. This allows Finance users or authorized administrators to update historical records without having to process each entry individually. 2. Newly Created G/L Entries For newly posted transactions, the description is maintained as part of the G/L Entry creation process. This means that the enhancement does not depend on users remembering to manually update the description after every posting. Two-Part Approach Existing Entries: One-time controlled update. New Entries: Automatic description population during the posting process. Updating Historical G/L Entries Since the system may already contain historical G/L Entries, simply implementing the logic for future postings would leave existing records without the enhanced description. To address this, we introduced a one-time action that allows the required description to be generated and stored for historical entries. The process can be represented as: Existing G/L Entries → Run Update Action → Determine Required Information → Generate Description → Update G/L Entry This approach provides a practical way to bring historical records into the same structure used for newly posted transactions. Maintaining the Description for New Entries Updating historical records solves only one part of the requirement. The same description logic also needs to be applied to future G/L Entries. Therefore, the solution ensures that the description is generated and stored when the relevant G/L Entry is created. This avoids a situation where historical records have the … Continue reading Enhancing General Ledger Visibility with Purchase Invoice Details in Dynamics 365 Business Central for a Maldives Financial Institution and an Abu Dhabi-Based Diversified Holding Company →

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 →

Summary Return Purchase Orders affect operational health and are often overlooked in implementation planning. This guide covers the return workflow in Dynamics 365 F&O: creating return orders, executing warehouse movements, managing supplier shipments, and reconciling credits to accounts payable. We address configuration practices, warehouse operations, challenges (including trade agreement alignment), reporting frameworks, and integration patterns for multi-system environments. Table of Contents 1. The Problem: Why Return Purchase Orders Matter 2. The Core Flow: Return Purchase Order in D365 F&O 3. Warehouse Return Movement 4. Linking Movements to Returns 5. Configuration Deep Dive 6. Trade Agreement Alignment After Returns 7. Warehouse Practices 8. Configuration Checklist 9. Issues & Resolutions 10. Integration Considerations 11. Reporting & Monitoring 12. FAQs 1. The Problem: Why Return Purchase Orders Matter In any supply chain, orders don’t always go as planned. Quality issues, over-shipments, damage, and spec mismatches happen. When they do, the warehouse receives material that doesn’t meet requirements—and the system needs to reflect that. A Return Purchase Order is not just a procurement transaction. It’s an operation that touches procurement, inventory management, warehouse operations, and finance. Miss a step, and you create: Inventory mismatch — on-hand quantities that don’t match physical stock Supplier master data drift — invoices tied to prices that no longer apply after returns Warehouse disruption — excess stock, blocked pallets, confusion on what’s usable Finance rework — accruals and liabilities out of sync This guide walks through how D365 F&O handles Return Purchase Orders, with focus on the warehouse return movement process that keeps physical and system inventory in sync. Procurement Warehouse Finance Original PO Return Order (linked to PO) Create Return order # referenced Transfer Journal Active Floor → Return Staging Ship Ship to Supplier RMA / credit note Credit Reconciled against Return OrderThe Return Purchase Order flow crosses three systems: a return order in Procurement drives a Transfer Journal in the Warehouse, which drives a credit reconciliation in Finance — connected end to end by the return order number. 2. The Core Flow: Return Purchase Order in D365 F&O Step 1: Create a Purchase Order Return When material needs to be returned to the supplier: Navigate: Accounts Payable → Purchase Orders → All Purchase Orders Select the original PO Action: Click Return Order (in the Ribbon, or Create menu) System creates a return order linked to the original PO, with: Supplier reference intact Quantities that can be adjusted (typically the original received quantity is pre-populated) Line item details copied from the original PO Status = Open Configuration: Return orders inherit the original PO’s delivery address and supplier terms, but warehouses can override the receiving location if the return flows through a different staging area. Accounts payable  ›  Purchase orders  ›  All purchase orders  ›  PO-000482  ›  Return order PostConfirmCancelPrint Return order numberRO-000091 StatusOpen Vendor accountV-10234 — Acme Components Inc. Original purchase orderPO-000482 WarehouseWH-MAIN Return-to locationRETURN_QA Item number Product name Qty to return Unit price Line amount IT-4021 Steel Bracket 40mm 25 $50.00 $1,250.00 IT-4088 Hex Bolt Set 10 $12.50 $125.00 Illustrative mockup of a Return Order form — not an actual product screenshot. The return order carries the original PO reference, vendor, and return-to location into the warehouse process. Step 2: Warehouse Return Movement Once the return order exists, the warehouse must physically move material out of active inventory. In D365, this happens via Transfer Journal or Movement Journal, depending on your configuration. 3. Warehouse Return Movement Options Active Floor Transfer Journal Return Staging QA Hold Returnable Not returnable Ship to Supplier Scrap / Write-offOnce material reaches Return Staging, the path splits: returnable stock ships back to the supplier under the return order; non-returnable stock is scrapped through an Inventory Adjustment journal. Option A: Transfer Journal (Used in Most Implementations) Used when material physically moves from one warehouse/location to another (e.g., floor → return staging area). Navigate: Inventory Management → Journals → Transfer Journal Create new journal entry Add lines: From warehouse: where the inventory currently sits To warehouse: return staging/quarantine area Item number, quantity, UOM Assign to Return Purchase Order (optional reference field) Post System adjusts on-hand in “From” warehouse, increases in “To” warehouse Inventory management  ›  Journal entries  ›  Transfer journal  ›  RETURN-TRANSFER-0091 PostValidateLinesInquiries Journal nameRETURN-TRANSFER StatusDraft ReferenceRO-000091 Posting date09/16/2026 Item number From warehouse / location To warehouse / location Quantity IT-4021 WH-MAIN / ACTIVE_FLOOR WH-MAIN / RETURN_QA 25 IT-4088 WH-MAIN / ACTIVE_FLOOR WH-MAIN / RETURN_QA 10 Illustrative mockup of a Transfer Journal — not an actual product screenshot. The Reference field carries the return order number so the warehouse movement stays traceable to Finance. Workflow:Active Floor → Return Staging → Ship to Supplier(Transfer Journal 1) → (Transfer Journal 2 or direct shipment) Option B: Inventory Adjustment Journal Used if you’re removing defective/unsaleable inventory entirely (scrap, damage). Navigate: Inventory Management → Journals → Inventory Adjustment Create new journal Add lines: Item, warehouse, quantity Mark as “Loss” or “Damage” Post On-hand reduced; writeoff recorded When to use: Only when the material cannot be returned to supplier (scrap/damage). Do NOT use for supplier returns—you lose the linkage to the Return Purchase Order. 4. The Critical Step: Linking Movements to Returns This is where many implementations stumble. Problem: You create a return order and move inventory, but the two are never connected. Result: Finance doesn’t know which returns have been physically staged Accounts payable credits the invoice without visibility into what’s actually coming back Warehouse can’t track which pallets belong to which return Without a Link With a Link Return Order Warehouse Movement Finance / AP Return Order Warehouse Movement Finance / AP Return Order # Return Order #Without a shared reference, the return order, the warehouse movement, and the finance record never connect. Carrying the return order number through the transfer journal and into the credit memo links all three. Solution: Before posting the movement journal, reference the Return Purchase Order number in a comment or custom field Or: Use a dedicated warehouse location code (e.g., RETURN_TO_[SUPPLIER_CODE]) that signals items are earmarked for return Approach: Set up … Continue reading How a Leading North American Commercial Vehicle Manufacturer Managed Return Purchase Orders and Warehouse Return Movements in Dynamics 365 Finance & Operations →

Watch first Your browser does not support embedded video. Download the video instead. Twenty seconds: what the agent does, and why per-user CRM security is the part that is actually hard. 01Summary A Houston-based cybersecurity firm wanted their sales team to ask plain-language questions about CRM data, “how many active leads do we have”, “summarise this account’s open opportunities”, without opening Dynamics 365 and building a view for every question. We built it as an Azure AI Foundry agent connected to Microsoft Dataverse over the Model Context Protocol (MCP). No custom data layer, no synchronised copy of CRM, no bespoke API surface. Dataverse itself is the MCP server, and Foundry’s Agent Service calls it as a tool. The agent runs on GPT-4.1 and took an afternoon to wire up. The two things that actually cost time were an OAuth redirect URL that Foundry generates after you click Connect, and an architecture decision we got wrong the first time: the tenant your agent lives in decides whether per-user CRM security is achievable at all. 02In This Blog A practitioner walkthrough of connecting Foundry to Dynamics 365 over MCP, written around the two failures that cost us the most time rather than the happy path alone. The Scenario: A sales team that wanted answers from CRM without building a view for every question. The Approach: Use Dataverse as a first-party MCP server rather than building an API layer and hand-written function schemas. The Action: Environment enablement, an Entra app registration, the MCP tool with OAuth identity passthrough, and the redirect URL nobody warns you about. The Outcome: Per-user security enforced by Dataverse itself, with no parallel permission model to maintain. The connection is an afternoon. The question of whose identity the agent is acting as decides whether any of it survives contact with production. Table of Contents 01Summary→ 02In This Blog→ 03Why MCP Changes the Shape of This Problem→ 04Enable the MCP Server and Allow Your Client→ 05Register the Entra App→ 06Add the MCP Tool to the Agent→ 07Close the Redirect URL Loop→ 08Consent, and the Consent Loop→ 09Calling the Agent From Your Own Application→ 10The Tenancy Trap→ 11Licensing→ 12Impact→ 13Conclusion→ 14FAQ→ 15Get in Touch→ 03Why MCP Changes the Shape of This Problem Before MCP, connecting an LLM to Dynamics 365 meant building glue: an API layer, a set of hand-written function definitions describing each operation, schema documentation maintained by hand, and a deployment to own forever. Every new table meant another function. The Model Context Protocol replaces that with a contract. The server advertises its tools, the model discovers them at runtime, and the plumbing is the same whichever client connects. Microsoft ships Dataverse as a first-party MCP server, so the glue layer is simply gone. Dataverse MCP endpointurl https://{organisation}.crm{n}.dynamics.com/api/mcp A preview endpoint exists at /api/mcp_preview with additional tools, gated behind a separate environment setting. Check your region number Environment URLs are not always .crm. Ours has been .crm4 on other engagements, and pointing at the wrong host produces an authentication failure that looks like a permissions problem. Confirm it in Power Apps under Settings, Session details. The tool surface Tool What it does search Searches table schemas and business skills by keyword search_data Searches structured and unstructured data describe Returns details for tables, records, schemas, skills and apps read_query Runs supported Dataverse SQL SELECT queries create_record Inserts a row, returns the Gcfb-mcp7fd update_record Updates an existing row delete_record Deletes a row, only after explicit user approval create_table, update_table, delete_table Schema operations upsert_skill, delete_skill Manages Dataverse skills and playbooks init_file_upload, commit_file_upload, file_download SAS-based file handling The tool names changed, and older tutorials are wrong describe_table, list_tables and fetch were removed and folded into describe. The tool previously called search, which searched data, is now search_data, and search now searches metadata. If you maintain an allow list or deny list by tool name in your client, this rename silently changes what your agent can do. Review it. 04Step 1: Enable the MCP Server and Allow Your Client This is admin work in the Power Platform admin center, not maker work, and it is where most failed attempts stall. Open the environment settingsPower Platform admin center, then Manage, then Environments. Open the target environment and select Settings on the command bar. Turn on the MCP serverExpand Product, select Features, find Dataverse Model Context Protocol, and enable Allow MCP clients to interact with Dataverse MCP server. Open the allowed client listSelect Advanced Settings. This is where non-Microsoft and custom clients are registered individually. Add your client and enable itCreate an Allowed MCP Client record carrying the Application Id of the app registration you create in Step 2, then set Is Enabled to Yes. Copilot Studio is enabled by default. Nothing else is. Your Foundry agent is not Copilot Studio, so it needs an explicit entry. This is the single most common cause of “the connection succeeded but the agent never calls the tool”. Field Value Name A readable label, for example Foundry Dataverse Agent Unique Name A unique identifier for the record Application Id The client (app) ID of the Entra app registration from Step 2 Is Enabled Yes Figure 1: The Allowed MCP Client record. Is Enabled defaults to No. Is Enabled defaults to No Saving the record is not the same as enabling it. A disabled record behaves identically to no record at all, and produces no error anywhere. Set it to Yes before you save. This is a chicken-and-egg with Step 2: you need the Application Id before you can fill this in. Create the app registration first, then come back. Two constraints worth knowing before you plan the rollout: Managing the MCP server through Advanced connector policies requires the environment to be a Managed Environment. The allow list applies only to the /api/mcp agent entrypoint. MCP-named custom APIs are ordinary Dataverse APIs and are not restricted by this setting. If you want the preview tools, enable Allow MCP clients to interact with Dataverse MCP server (Preview version) as a … Continue reading How We Connected an Azure AI Foundry Agent to Dynamics 365 Using the Dataverse MCP Server for a Texas Industrial Cybersecurity Company →

Summary This article covers the implementation of barcode-based location movement scanning in Dynamics 365 Finance & Operations (WMS) for a North American manufacturing operation. The physical warehouse was built into D365 using an Aisle–Rack–Shelf–Bin location model created through the Location setup wizard, and Work templates, Location directives and Mobile device menu items were configured so that every material movement becomes directed, scanner-guided work. Multi-stage routing with enforced stop-work breaks ensures that complex movements across stations are captured step by step, replacing paper-based and manual location tracking with real-time scanning on the Warehouse Management mobile app. Finally, inventory adjustment journals close the loop so that work-order completion reconciles on-hand inventory accurately. Table of Contents Introduction The Business Problem The Solution Building the Warehouse Location Model (Aisle–Rack–Shelf–Bin) Creating Locations with the Location Setup Wizard Enabling the Worker on the Warehouse Mobile App Work Templates Location Directives Mobile Device Menu Items The Multiple Scanning Movement Process Inventory Adjustment Journals for Work-Order Closure Implementation Considerations & Limitations Business Impact FAQs Conclusion 1. Introduction In Microsoft Dynamics 365 Finance & Operations, the warehouse is only as accurate as the data captured on the floor. Every receipt, put-away and internal move has to be recorded against a precise physical location, otherwise on-hand inventory, replenishment and downstream planning all drift out of alignment. For high-volume manufacturing and distribution operations, keying that information manually is slow, error-prone and impossible to audit after the fact. Location movement scanning solves this by making the warehouse location itself the anchor of every transaction. Instead of typing where something is, an operator scans it. Dynamics 365 F&O Warehouse Management (WMS) turns those scans into directed work — the mobile device tells the worker exactly where to go, what to pick and where to put it, and the system records each step in real time. This article walks through how location movement scanning was designed and delivered for a North American commercial vehicle manufacturing operation as part of a Warehouse Management, Inventory and Scanning rollout. It covers how the physical warehouse was modelled in D365, how the Aisle–Rack–Shelf–Bin location structure was created, and how Work templates, Location directives and Mobile device menu items work together to convert a floor movement into a traceable, scanner-guided sequence — all closing out cleanly against inventory. Scan on the mobile device Directed work system-guided steps Accurate inventory real-time, to the binFigure 1. Location scanning turns a floor movement into directed, traceable work with real-time inventory. 2. The Business Problem The operation runs a large, multi-zone warehouse footprint where materials move continuously between receiving, pick stations, sub-assembly areas and staging. Before the D365 F&O rollout, location tracking depended heavily on manual entry and local knowledge. Workers knew where things were, but the system frequently did not. As volume and layout complexity grew, several operational problems surfaced: On-hand inventory did not reliably reflect the physical location of stock. Internal movements between aisles, racks and stations were captured inconsistently, or after the fact. There was no directed, enforced sequence for multi-step movements, so steps were skipped or done out of order. Work could not be traced — it was difficult to prove who moved what, from where, to where, and when. Manual keying of long item and location codes introduced errors that rippled into planning and replenishment. Reconciling inventory at the end of a work order required time-consuming manual investigation. The business needed the physical warehouse represented accurately inside D365, and every movement on the floor captured through scanning — directed by the system, enforced in the right order, and reconciled against inventory without manual guesswork. The Objective: Model the warehouse down to the bin, and make every material movement a scanner-directed, traceable transaction so on-hand inventory, work status and location data stay accurate in real time. 3. The Solution Dynamics 365 F&O Warehouse Management provides the full building blocks for scanner-directed movement: a structured location hierarchy, Work templates that define the sequence of steps, Location directives that decide where each step happens, and Mobile device menu items that expose the process on the handheld scanner. The solution was assembled in layers — first the physical location model, then the worker enablement, then the three configuration objects (templates, directives, menu items) that turn a movement into directed work, and finally the inventory reconciliation that closes it out. Work templatesWHAT stepsPick · Custom · Put sequenceLocation directivesWHERE it happensresolves the exact binMobile menu itemsHOW on the scannerstart / resume work Directed, scanner-guided work every floor movement — enforced & traceableFigure 2. Work templates, Location directives and Mobile menu items combine into a single directed-work engine. 3.1 Building the Warehouse Location Model (Aisle–Rack–Shelf–Bin) The foundation of location scanning is a location structure that mirrors the physical warehouse. In this rollout the model followed an Aisle–Rack–Shelf–Bin hierarchy, using a location profile (RSBA) applied consistently across warehouse zones such as floor locations, tugger lanes and rack storage. Each physical position becomes an addressable location in D365 that a barcode can represent. Getting this hierarchy right is what allows a single scan to resolve to an exact bin. Location hierarchy Site └─ Warehouse └─ Aisle └─ Rack └─ Shelf └─ Bin ← scannable location SiteWarehouseAisleRackShelfBin — scannable locationFigure 3. The Aisle–Rack–Shelf–Bin location hierarchy modelled in D365, resolving to a scannable bin. 3.2 Creating Locations with the Location Setup Wizard Locations were generated using the Location setup wizard rather than created one by one, which keeps naming consistent and saves considerable effort across a large footprint. Navigation Warehouse management > Setup > Warehouse > Locations > Location setup wizard Steps 1. Open the Location setup wizard 2. Set up all relevant details (profile = RSBA, aisle/rack ranges) 3. Click Create 4. Repeat per bin identifier: Enter “A” → Create Enter “B” → Create Enter “C” → Create Because the bins were A, B and C, the create step was repeated for each. To verify, open the Location field, filter by “C”, and confirm every location generated for the “C” rack is present. The same wizard-driven … Continue reading Location Movement Scanning in Dynamics 365 Finance & Operations: Turning Warehouse Floor Movements into Traceable, Scanner-Directed Work →

Summary For technology services companies selling AI, cybersecurity, and Azure solutions, the hardest part of selling is rarely finding a company — it’s finding the right decision-maker, the right relationship path, and the right moment to engage. We recently implemented LinkedIn Sales Navigator inside Microsoft Dynamics 365 Sales for a Texas-based technology services company specializing in AI, cybersecurity, Azure, and cloud services. The goal wasn’t to drop a LinkedIn widget into a form — it was to build a connected prospecting experience where LinkedIn relationship intelligence and Dynamics 365 sales execution work together without forcing sellers to switch between systems. The result: sellers can research prospects, understand account relationships, identify mutual connections, and capture sales activity — all from within the CRM they already use every day. LinkedIn became the intelligence layer; Dynamics 365 remained the operational system of record. This article covers the business requirement, the matching strategy, the CRM synchronization design, and the key lessons learned from turning a LinkedIn integration into an actual sales process change. Table of Contents Introduction The Business Requirement Why LinkedIn Sales Navigator and Dynamics 365? What We Set Out to Achieve Solution Overview Setting Up LinkedIn Sales Navigator Connecting Sales Navigator with Dynamics 365 Sales Embedding Sales Navigator into CRM Forms Designing the Matching Strategy Bringing LinkedIn Intelligence into the Sales Process Icebreakers and Relationship Intelligence Lead Introduction and Related Leads Account Intelligence and Organizational Relationships CRM Synchronization and Activity Writeback Data Validation: Keeping CRM Current Controlling What Gets Written Back to CRM Synchronizing Open Opportunity Information Testing and Validation Business Impact The Strategic Value Beyond Integration Key Implementation Lessons Conclusion Frequently Asked Questions Final Takeaway This Blog Explains Why fragmented prospecting between LinkedIn and Dynamics 365 was costing sellers time and context. What licensing and administrative foundation CRM integration with Sales Navigator requires. Why matching LinkedIn profiles to CRM records is a business problem, not just a technical one. How CRM synchronization and activity writeback were scoped to avoid a noisy, unrestricted sync. How Sales Navigator can surface signals that CRM contact data has gone stale. The measurable improvements to seller workflow, CRM data quality, and account planning. The lessons we’d apply again on the next CRM-to-LinkedIn implementation. Case Study Read more about our Journey with this Customer over here: View Case Study Introduction For technology services organizations, selling is rarely about finding a company and sending an email. The real challenge is identifying the right organization, the right decision-makers, the right relationship path, and the right moment to engage. This becomes particularly important for companies operating across Artificial Intelligence, Cybersecurity, Azure, Cloud, and digital transformation, where sales cycles involve multiple stakeholders, technical influencers, business leaders, and evolving buying committees. We recently implemented LinkedIn Sales Navigator with Microsoft Dynamics 365 Sales for a Texas-based technology services company specializing in AI, cybersecurity, Azure, and related cloud services. The objective was not simply to place a LinkedIn widget inside Dynamics 365 — it was much broader: Create a connected prospecting experience where LinkedIn relationship intelligence and Dynamics 365 sales execution could work together without forcing sellers to continuously switch between systems. The implementation brought LinkedIn Sales Navigator capabilities into the organization’s existing Dynamics 365 Sales environment, enabling sellers to research prospects, identify relevant connections, understand account relationships, create and update CRM records, and capture relevant sales activity within the CRM ecosystem. This Dynamics 365 Sales LinkedIn integration as a way to bring real-time intelligence about prospects and organizations into the sales process, including profile information, mutual connections, key decision-makers, and other sales insights. For this organization, the value came from turning that capability into a business process rather than simply a software integration. The Business Requirement The client already had Dynamics 365 Project Operations & Sales as its CRM platform and LinkedIn as an important channel for professional prospecting and relationship building. However, the sales process naturally crossed between the two platforms. A typical seller workflow could involve: Finding a target company. Searching LinkedIn for decision-makers. Researching their background. Looking for mutual connections. Checking whether the person already existed in Dynamics 365. Reviewing the account’s existing opportunities. Deciding how to approach the prospect. Creating or updating the CRM record. Recording the interaction. Returning to Dynamics 365 to continue managing the opportunity. Each individual step is manageable. The problem emerges when this happens repeatedly across dozens or hundreds of prospects. The organization needed to reduce this fragmentation. The business requirement centered around five objectives: 1. Improve prospect discovery Help sellers identify relevant people and organizations more efficiently. 2. Improve relationship intelligence Allow sellers to understand mutual connections, organizational relationships, and relevant prospect information. 3. Reduce application switching Bring useful LinkedIn intelligence directly into the Dynamics 365 sales experience. 4. Improve CRM data quality Create mechanisms for identifying outdated information and reducing duplicate or disconnected prospect records. 5. Preserve CRM as the operational system of record LinkedIn should enhance the sales process, not create a parallel sales database. That last point became one of the most important principles of the implementation. Why LinkedIn Sales Navigator and Dynamics 365? LinkedIn Sales Navigator is fundamentally a prospecting and relationship intelligence platform. Dynamics 365 Sales, on the other hand, provides the CRM and sales execution layer. The strategic opportunity was to combine the two. LinkedIn provides access to professional and organizational intelligence, while Dynamics 365 provides the business context around: Accounts Contacts Leads Opportunities Activities Sales pipeline Ownership Customer history When these systems are connected correctly, the seller does not need to think in terms of two disconnected applications. Instead, the experience becomes: Discover → Understand → Engage → Capture → Progress LinkedIn’s Sales Navigator highlights CRM Sync capabilities such as auto-save, activity writeback, CRM badges, ROI reporting, and search filtering. CRM integration is available with Sales Navigator Advanced Plus. D365 CRM allows to surface LinkedIn information directly within Dynamics 365 Sales through Sales Navigator controls and embedded experiences. What We Set Out to Achieve Our objective during the implementation was to go beyond the technical connection. … Continue reading From Prospecting to Pipeline Intelligence: How We Embedded LinkedIn Sales Navigator into Dynamics 365 Sales for a Texas-Based, Cybersecurity & Azure Services Company →