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 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 →

Summary In rapidly evolving sales organizations, business requirements rarely remain static. New products, services, sales categories, commercial models, and operational scenarios can continuously introduce the need for additional values in Dynamics 365. For one of our clients, this resulted in a recurring dependency on the technical team. Whenever the business needed to add or modify values in a Dynamics 365 Choice column, they had to approach the implementation team for a seemingly small configuration change. At first glance, replacing the Choice column with a Lookup table appeared to be a natural solution. However, that approach would introduce a much larger change: migrating existing records, replacing references throughout the application, modifying system processes, reviewing integrations, and potentially impacting logic that already depended on the existing Choice values. Instead of redesigning the data model to solve a configuration problem, I approached the requirement from a solution-architecture perspective. I built a self-service Dataverse Choice Manager that allows authorized users to select a Dataverse table and Choice column, add or update options, publish the metadata, and automatically create an audit record and notify system administrators. The solution uses supported Dataverse Web API and Metadata APIs to perform controlled schema-level operations while introducing governance, auditability, and guardrails around those changes. The result is a model where the business can adapt its Choice values without continuously depending on developers, while the technical team retains control over security, governance, auditing, and platform integrity. Case Study Read more about our Journey with this Customer over here: View Case Study Table of Contents Introduction Business Requirement The Architectural Decision How I Solved It Implementation Procedure End-to-End Working Custom Auditing and Governance Working Within Dataverse Platform Boundaries Benefits of the Solution Limitations and Guardrails Conclusion Introduction Dynamics 365 implementations often evolve alongside the businesses they support. A sales organization may initially define a finite set of values for a Choice column. Over time, however, new products are introduced, sales processes change, new commercial categories emerge, and terminology evolves. The technical change may appear trivial: “I just need to add one more option to this Choice field.” But when the same request occurs repeatedly, a different problem emerges. The business becomes dependent on the technical team for configuration changes that are fundamentally part of day-to-day business evolution. For one of our clients, this pattern was becoming increasingly common. The organization is highly sales-focused and operates in an environment where business requirements continue to evolve. The question therefore became: Can I give the business controlled self-service access to Choice values without redesigning the existing Dataverse data model? Rather than immediately changing the schema, I looked at the problem from a solution-design perspective. The answer was to build a controlled metadata management layer over Dataverse. Business Requirement The client’s requirement was straightforward: Select a Dynamics 365 table. Select a Choice column. Add a new option when the business needs one. Update an existing option label when terminology changes. The challenge was not simply performing these operations. The challenge was performing them safely. A typical Dynamics 365 user does not need unrestricted access to the Dataverse schema. Giving users broad customization privileges would create an entirely different governance problem. I therefore needed to balance two competing objectives: Business agility The sales team should not need to raise a development request every time a new Choice value is required. Technical governance The organization still needs to know: Who made the change? What was changed? When was it changed? Which table was affected? Which Choice column was affected? What was the previous value? What is the new value? Was the change successfully published? This led us to a more important architectural principle: Self-service does not have to mean unrestricted access. The solution should expose only the operations that the business needs while keeping the underlying metadata APIs behind a controlled interface. The Architectural Decision Option 1: Replace the Choice with a Lookup One possible solution was to replace the existing Choice column with a Lookup pointing to a new Dataverse table. Conceptually, this would provide an excellent long-term model for highly dynamic business values. For example: Sales Record | +– Category Lookup | +– Category A +– Category B +– Category C +– Category D The business could then create new category records without changing metadata. However, the problem was the existing implementation. The Choice column was already being used across the solution. Replacing it would potentially require: Identifying all existing records containing the Choice value. Creating corresponding records in the new Lookup table. Migrating existing data. Replacing the existing field references. Updating JavaScript. Reviewing plugins. Reviewing Power Automate flows. Reviewing business rules. Reviewing integrations. Updating reports and Power BI dependencies. Testing existing processes. Deploying the changes across environments. In other words, a small configuration problem could turn into a substantial data-model transformation. The Architectural Conclusion The problem was not necessarily that the Choice column was the wrong data type. The problem was that the organization needed a controlled way to manage its values. Therefore, rather than redesigning the data model, I preserved the existing architecture and built a self-service management capability around it. How I Solved It I designed a web-resource-based application inside Dynamics 365: Dataverse Choice Manager Dataverse Picklist Manager. The application provides a simple interface through which an authorized user can: Select a Dataverse table. Retrieve the available Choice columns. Select a Choice column. Retrieve its existing options. Add a new option. Update an existing option. Publish the affected table. Generate an audit record. Notify the system administrator. From the user’s perspective, this becomes a simple business operation. From the platform perspective, however, the application is interacting directly with Dataverse metadata. The high-level architecture is: Dynamics 365 User | v Dataverse Choice Manager | +——————–+ | | v v Dataverse Web API Metadata Actions | | | InsertOptionValue | UpdateOptionValue | DeleteOptionValue | PublishXml | v Dataverse Metadata | v Choice Column Updated | +———————-+ | | v v Custom Audit Log System Administrator Email This is where the solution becomes more … Continue reading How a Texas-Based AI and Cybersecurity Services Company Streamlined Dataverse Choice Management in Dynamics 365 →

☼ 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 →

Turning Lead Chaos into Clarity: How a Massachusetts-Based Manufacturing Business Transformed Its Sales Reporting Summary Sales teams generate a steady stream of leads across sources like trade shows and referrals, yet most organizations can’t answer a simple question in real time: “How is our pipeline actually trending this month?” We built a single-page Sales Dashboard using Dynamics 365 Customer Service lead data and Power BI, giving revenue teams a live, filterable view of lead volume, process stage, qualification, and source mix, all driven by two global slicers: Account and Date Range. The result: manual weekly lead tracking was replaced with a live view that surfaces channel performance and process bottlenecks the moment they appear. Table of Contents 01 Summary 02 About the Customer 03 The Challenge 04 The Solution 05 Dashboard Overview 06 Lead & Stage Trends 07 Source & Geography 08 Business Impact 09 FAQs 10 Conclusion About the Customer Customer Spotlight A US-Based Manufacturing Business Rebuilding a Century-Old Category Headquartered in Massachusetts, our customer is a US-based manufacturer that set out to fix a problem no one had touched in over a century: cooking appliances still running on decades-old heating technology. After five years developing a proprietary heating alloy and real-time smart algorithms, the team launched the world’s first touchscreen toaster, which has since become a #1-selling smart toaster with national media recognition. As the company scaled, it needed a single, always-current view of sales pipeline health to match its fast-growing customer base. The Challenge Dynamics 365 Customer Service captures every lead reliably. The gap wasn’t data capture. It was turning that raw lead data into a view sales leadership could actually act on. Sales managers frequently found themselves asking: 1Is lead volume growing or flattening month over month? 2Where are leads getting stuck in the sales process? 3How many leads are actually converting to Qualified? 4Which lead source is driving the most volume? 5Can we filter all of this down to a single account instantly? Answering these meant exporting Dataverse views into spreadsheets and manually re-pivoting, a process that was slow, error-prone, and quickly out of date. The Solution To eliminate manual reporting, we designed a centralized Sales Dashboard in Power BI using Dynamics 365 Customer Service Leads as the data source. The report is built as a single interactive canvas covering: Lead Volume Trends Month-by-month tracking of lead creation to spot pipeline generation swings early. Business Process Stage Real-time view of how many leads sit at each stage of the sales process flow. Dynamics 365 Customer Service Integration Primary data source connecting lead records, source, county, and qualification status. Power BI Analytics Layer Global Account and Date slicers, source-mix pie charts, and geographic breakdowns. Dashboard Overview The dashboard gives sales leadership an instant read on pipeline health. It consolidates the key lead metrics into one interactive page: Count of Leads Leads by Month Business Process Stage Qualified Leads Qualified by Month Lead Source Mix Leads by County Account Filter Date Range Filter The dashboard includes interactive filters for Account and Date Range at the top of the page, enabling instant re-analysis across any account or time window without rebuilding a single visual. Lead & Stage Trends Rather than reviewing lead counts only at month-end, management can continuously monitor: Monthly lead creation volume vs. prior months How many leads currently sit in each business process stage Qualified lead volume by month, compared against total leads created These trends quickly surface slowing lead generation, stalled leads sitting too long in the pipeline, or a widening gap between leads created and leads qualified, turning lead tracking into an operational management tool rather than a monthly snapshot. Lead Source & Geographic Breakdown Understanding where leads come from matters as much as how many arrive. The report breaks leads down by Lead Source and County, helping marketing and sales identify: Which channel, trade show or referral, is driving the most volume Whether marketing spend is aligned with actual lead-generating channels Gaps in geographic data capture, such as an unpopulated County field Regional concentration of leads once location data is fully captured Filtering by Account and Date Using the page-level Account and Date slicers, users can instantly narrow the entire dashboard to answer strategic questions such as: How is a specific account’s lead activity trending? How did lead volume compare across a specific quarter? Where should the next trade-show investment go? Business Impact Before After Lead volume tracked manually in spreadsheets Live month-by-month lead trend in Power BI No visibility into where a lead sits in the sales process Business Process Stage visual shows real-time stage distribution Lead source ROI discussed anecdotally Lead Source pie chart quantifies channel contribution instantly Filtering by account meant exporting and re-pivoting data One dropdown filters the entire dashboard to a single account Qualified lead conversion checked only at month-end Continuous lead-to-qualified tracking across the year Frequently Asked Questions 1Does Dynamics 365 Customer Service provide pipeline reporting out of the box? Dynamics 365 Customer Service captures the underlying lead and process-flow data, but organizations typically need a customized Power BI report to combine lead volume, stage, source, and geography into one actionable view. 2Why show Business Process Stage alongside lead volume? Volume alone doesn’t tell you if leads are moving through the pipeline. Pairing stage distribution with monthly volume shows both how many leads are coming in and where they’re getting stuck. 3Who benefits most from this type of report? Sales leadership, marketing teams, and account managers all benefit. Leadership gets portfolio-level pipeline visibility, while account managers can filter straight down to a single account’s lead activity. 4Can this be extended to Opportunities? Yes. The same Account and Date slicer pattern can be reused on an Opportunity-based page to track pipeline value and win rate alongside lead volume. Conclusion Pipeline health is measured by more than how many leads come in. It’s defined by how well they move, where they come from, and whether the data behind them is trustworthy. By connecting Dynamics 365 Customer Service … Continue reading Turning Lead Chaos into Clarity: How a Massachusetts-Based Manufacturing Business Transformed Its Sales Reporting →

Insights & Field Notes Summary Account data in CRM is rarely in one place. Revenue, pipeline, quotes, and years of meeting notes live across many separate records. We built a one-click Account Intelligence Report that runs inside Dynamics 365 and assembles the full account picture on screen in seconds. A second click runs an AI analyst over every appointment note, producing a plain-language engagement history, current status, open commitments on both sides, and talking points for the next meeting. The complete report, facts plus AI insights, exports as a branded, editable Microsoft Word document with a single click. It runs entirely within the signed-in user’s own Dynamics session. No new servers, no third-party libraries, and it inherits the user’s existing data permissions by design. Table of Contents The 40-Minute Problem One Button, Total Account Intelligence What the Report Actually Contains The AI Analyst: Years of Notes in One Read From Screen to Boardroom: One-Click Word Export Under the Hood: How It Works (and Why It’s Safe) Business Impact FAQs 01The 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. 02One Button, Total Account Intelligence 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. 03What 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. 04The 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 … Continue reading From CRM Silos to a Board-Ready Brief: An AI-Powered Account Intelligence Report Inside Dynamics 365 Sales →

Summary Automated end-to-end contract generation, digital signing, and document filing for an Australia-based commercial linen and garments company using Dynamics 365 Sales, Microsoft Power Automate, and Adobe Acrobat Sign. Eliminated manual contract preparation by generating personalized Word contracts directly from accepted Dynamics 365 Quotes using a reusable Word template. Leveraged Adobe Acrobat Sign text tags embedded within the Word template to automatically create signature, date, and fillable fields without manual field placement or custom development. Automated agreement creation, customer notifications, and real-time signing status tracking through Adobe Acrobat Sign, providing complete visibility throughout the contract lifecycle. Implemented a dedicated child Power Automate flow that automatically identified completed agreements from Adobe Sign emails and archived signed contracts into the correct SharePoint document library. Reduced contract turnaround from a manual, multi-step process to a one-click, fully automated workflow while ensuring audit-ready signed documents and eliminating manual document handling. Table of Contents Introduction Business Challenge Procedure End-to-End Flow Why This Approach Works Conclusion Introduction For any business that runs on contracts — service agreements, quotes-turned-orders, vendor sign-offs — the gap between "quote accepted" and "contract signed" is often where deals slow down. Manual document preparation, back-and-forth emails, chasing signatures, and manually filing signed copies all eat into time that should be spent serving the customer. For an Australia based Linen and Garments, a commercial textile services company, CloudFronts built an end-to-end automation that takes a sales quote all the way through to a fully signed, filed contract — with zero manual document handling in between. The solution combines a Word contract template, Microsoft Power Automate, and Adobe Acrobat Sign, orchestrated across two connected flows: a parent flow that creates and sends the contract, and a child flow that listens for the signed response and files it automatically. This post walks through how that solution works, including the one detail that makes the whole thing possible without any custom code: Adobe Sign text tags embedded directly inside the Word template. The Business Challenge Once a quote is accepted, the team needed the resulting contract to: Be generated automatically from the quote and its line items — no manual copy-pasting of customer details into a Word document. Be sent for signature immediately, with the right fields ready for the customer to fill in and sign — bank details, account information, and a signature block, all in the right place. Notify both the customer and the internal Adobe Sign account holder the moment it’s out for signing. Automatically file the final, fully signed PDF back into the correct SharePoint location tied to that quote — without anyone needing to remember to save it. Doing this by hand across multiple people and mailboxes was slow and error-prone. The goal was to make the entire journey — quote to signed, filed contract — happen in minutes, with no manual document work at any step. Procedure Step 1: Auto-Generating the Contract from the Quote The process starts with a single action: Create Contract. This triggers the parent Power Automate flow, which: Composes the Quote ID from the selected record. Retrieves the document location tied to that quote (the Word contract template). Pulls the Quote, the associated Customer, and the Contact record for the signer. Uses these to populate a Word template — the standard “Populate a Word Template” merge step — filling in customer name, contract terms, line items, and contact details automatically. This is the same idea used in most contract-automation flows: merge structured CRM/quote data into a pre-built Word template, so the resulting document is fully personalized without a single manual edit. Step 2: Making the Contract Signable — Text Tags in the Template This is the step that makes the entire signing experience work, and it's worth explaining properly, because it's easy to get wrong. A merged Word document, by itself, is just static text. For Adobe Acrobat Sign to know where a customer needs to sign, initial, or fill something in, the template needs special markers called text tags — plain text strings embedded directly into the Word template before it's ever merged. When the finished document is sent to Adobe Sign, Adobe automatically scans it, finds these tags, and converts them into live, interactive fields for the signer. For the contract, the template includes tags like: {{Customer_Sign_es_:signer1:signature}} {{Date_Of_Signature_es_:signer1:date}} {{Financial_Institution_es_:signer1}} {{BSB_Number_es_:signer1}} {{Account_Name_es_:signer1}} {{Account_Number_es_:signer1}} Each tag follows Adobe's syntax: a field name, the _es_ identifier, the signer role (signer1), and an optional field type (signature, date, or left blank for a plain fillable text box). Because these tags are just text, they can sit anywhere in the Word template exactly where the business wants the field to appear — no separate field-placement tool required. Getting this right matters more than it looks. A few lessons learned building this out: The entire tag must stay on a single line and in a common font — if it wraps across a line break during merge or PDF conversion, Adobe won’t recognize it, and the raw tag text stays visible instead of becoming a field. Field type directives are limited to what Adobe actually supports (signature, date, initials, etc.) — leaving the type off entirely creates a plain fillable text field, which is what was used for the banking detail fields here. Converting the merged Word document to PDF before sending it to Adobe Sign tends to produce more consistent tag detection than sending the raw .docx. Because the tags are static text baked into the template, no extra configuration is needed in Power Automate to "activate" detection — it happens automatically the moment the document is sent to Adobe Sign for signature. Step 3: Sending the Contract for Signature Once the Word template is fully populated, the flow hands it off to Adobe Acrobat Sign using the Create an agreement from a file content and send for signature action — passing the merged file straight through, along with the signer's name, email, and role. At this point, two things happen simultaneously: a) The customer's Contact person receives … Continue reading From Quote to Signed Contract in Minutes: Automating Adobe Acrobat Sign Integration for an Australia based Linen and Garments company →

From Quote to Signed Contract in Minutes | Cloudfronts DocuSign Blog Summary Automated end-to-end contract generation and digital signing for an Australia-based commercial linen and garment services company using Dynamics 365 Sales, Power Automate, and DocuSign. Eliminated manual contract preparation and PDF email workflows, replacing them with a one-click process triggered directly from the Dynamics 365 Quote record. Integrated DocuSign envelope creation, recipient assignment, and signature tab placement — all orchestrated through Power Automate cloud flows. Enabled real-time contract status tracking and automatic archival of signed PDF contracts back into SharePoint, linked directly to the originating Quote. Reduced contract turnaround time from days to hours, allowing the sales team to focus on customer relationships rather than administrative paperwork. Delivered a seamless customer experience — recipients receive a professionally formatted DocuSign email and can sign digitally from any device. Table of Contents 01 Summary 02 Introduction 03 The Business Problem 04 The Solution 05 Implementation 06 Business Impact 07 FAQs 08 Conclusion Introduction In industries where service agreements govern weekly delivery schedules, pricing structures, and compliance obligations, the speed and accuracy of contract execution can directly impact revenue and customer satisfaction. For commercial textile and linen services businesses in Australia, every signed contract represents a new route, a new customer, and a new revenue stream. Yet for many organisations, the final leg of the sales journey — converting an approved quote into a signed, legally binding contract — remains a surprisingly manual, error-prone process: exporting Word documents, emailing PDFs, chasing signatures, and manually filing returned documents. This blog documents how we at Cloudfronts transformed that process for a leading Australian commercial linen and garment services provider — deploying a fully automated DocuSign integration within Microsoft Dynamics 365 and Power Automate to take contracts from generation to signature without any manual intervention. The Business Problem Our client operates across multiple depots in Australia, servicing hotels, aged care facilities, hospitality venues, and healthcare providers with regular linen and garment delivery contracts. Their sales team works within Dynamics 365 Sales Hub, managing quotes that detail complex pricing, delivery schedules, weight-based charges, and product schedules. Before the integration, the contract signing process looked like this: A sales representative would generate a contract Word document from a template. The document was manually reviewed and converted to PDF. The PDF was emailed to the customer’s contact for signature. The customer would print, sign, scan, and return the document. The signed document would be manually uploaded to SharePoint and linked to the quote. This process introduced several critical pain points: Delays of 3–7 business days waiting for customer signatures. Inconsistent document versions being sent to customers. No visibility into whether a contract had been opened, reviewed, or signed. Risk of lost or misplaced signed documents. Significant administrative burden on the sales team. The business needed a solution that was seamless for both their internal team and their customers — something that could be triggered with a single action and would handle everything from document preparation to legally valid digital signature collection and storage. The Solution We designed and implemented a fully automated contract signing workflow that integrates Dynamics 365 Sales, Microsoft Power Automate, SharePoint, and DocuSign. The solution covers the entire lifecycle of a contract — from generation to signing to archival. Key Components Dynamics 365 Sales HubCentral system for quote and customer management. Power AutomateOrchestration layer connecting Dynamics 365, SharePoint, and DocuSign. SharePointDocument storage for generated and signed contracts. DocuSignDigital signature platform for legally binding contract execution. How It Works — At a Glance The solution is driven by two connected Power Automate flows: Send Contract Flow — Triggered manually from the Dynamics 365 Quote record. Retrieves the contract document from SharePoint, creates a DocuSign envelope, adds the contract document and recipient, places signature/name/date tabs, and sends the envelope. Receive Signed Contract Flow — Triggered automatically when the DocuSign envelope is completed. Retrieves the signed PDF from DocuSign and saves it to the same SharePoint folder, linking it back to the quote for a complete audit trail. Implementation 1 Step 1 Generate the Contract from Dynamics 365 The process begins in the Dynamics 365 Sales Hub on an approved Quote record. The sales representative clicks the Create Contract button in the command bar. This action triggers a workflow that generates a Service Contract Word document using the quote data and saves it to a dedicated Contracts folder in SharePoint, organised under the Quote number. Once generated, a confirmation dialog appears prompting the user to Open Contract for review before sending. The contract document is auto-named with the Quote ID and a timestamp, ensuring version control and traceability. 2 Step 2 Send the Contract for Signing After reviewing the document, the representative clicks Send Contract from the same Quote record. This triggers the main Power Automate flow — To send Contract Document to Customer for DocuSign. The flow executes the following steps: Compose Quote ID — Extracts and formats the Quote identifier. Get document location related to quote — Uses a FetchXML query against the SharePoint Document Location entity in Dataverse to locate the correct SharePoint folder linked to the Quote. Get Quote, Get Customer, Get Contact — Retrieves the customer’s full name and email address from Dynamics 365 for use as the DocuSign recipient. Initialise variables — Sets up Envelope ID, Recipient ID, and Parent Site location for downstream use. Iterate and locate the contract file — Loops through the SharePoint document library, resolves parent locations, retrieves file content, properties, and metadata. Create DocuSign Envelope — Creates an envelope with the subject line ‘DocuSign: Review & Sign the Contract Document’ and a personalised email body addressed to the customer contact. Add Document to Envelope — Attaches the contract Word document (encoded as Base64) to the envelope as a DOCX file. Add Recipient — Adds the customer contact as a signer with their full name and email from Dynamics 365. Add Signature Tabs — Places signature & other fields expaected to be filled by the recipient on … Continue reading From Quote to Signed Contract in Minutes: Automating DocuSign Integration for an Australia-Based Commercial Laundry Services Company →