One Data Platform, Future-Ready for AI – Power BI Report Migration to Azure Databricks Summary Every organization wants to be AI-ready. Very few are data-ready. Business data typically lives across ERP, CRM, HR, and finance systems, each handled differently and reported separately. The result is familiar to most leadership teams: reports that do not agree, logic rebuilt in every dashboard, and AI initiatives that stall because the data underneath them cannot be trusted. This article makes the case for one data platform – a single, governed foundation where all business data is brought together, processed consistently, and made ready for both reporting and AI. We share how we built this at CloudFronts on Azure and Databricks, unifying five business systems and migrating 40+ Power BI reports with zero downtime, and why that foundation is what makes AI use cases practical rather than aspirational. Table of Contents 1 The Hidden Cost of Scattered Data 2 What One Data Platform Really Means 3 Why It Matters to the Business 4 Solution Architecture Overview 5 Migration Without Disruption 6 From Reporting Platform to AI Foundation 7 AI Use Cases It Unlocks 8 Scattered vs Unified 9 Questions Every Leader Should Ask 10 Where to Start 11 FAQs 12 Conclusion The Hidden Cost of Scattered Data Most growing organizations do not set out to fragment their data. It happens one decision at a time. A new ERP for finance. A CRM for sales. An HR system for people. An accounting tool for a specific entity. Each one solves a real problem – and each one becomes another separate source of data. This project started with our own reporting. Like many growing services organizations, CloudFronts runs its business across several systems: Business Central and Finance & Operations for ERP, Dynamics 365 CRM for clients and engagements, Zoho People for HR, and Zoho Books for accounting. Leadership, finance, HR, and delivery teams rely on more than 40 Power BI reports built on these systems, from management dashboards and HR reports to the Steering Committee report we use to track quarterly meetings with client accounts. Over time, each system had been connected in its own way. Some data moved through Azure Data Factory, some through SQL Database, and some through Azure Functions. Reports connected directly to their sources, with business logic built inside each one, and they sat across separate workspaces for HR, management, and other teams. The idea behind the project was simple: instead of continuing to add pipelines and reports system by system, bring all business data into one trusted platform on Azure Databricks, migrate every existing report onto it without disrupting the people who use them, and build a foundation that is ready for AI in the process. None of the old setup looked broken on any given day. But the costs were real, and they compounded as the business grew. Numbers That Do Not Agree When the same metric is calculated in several reports, small differences appear. Leadership meetings start with reconciling numbers instead of acting on them. Effort That Keeps Growing Every new report means another connection, another copy of the logic, and another refresh to maintain. The effort grows with every report added. Governance That Is Hard to Enforce When reports sit in different workspaces with different owners, controlling who sees what becomes a manual, error-prone exercise. Data That Is Not Ready for What Is Next AI and advanced analytics need clean, connected data. Scattered data means every AI idea starts with a data consolidation project first. “The data was never the problem. The problem was that it lived in five places, and every system handled it differently.” What One Data Platform Really Means One data platform is not just a new database or a bigger data warehouse. It is a change in how the organization treats its data – from something each system and report manages on its own, to a shared business asset managed once, for everyone. Functionally, it comes down to four commitments: 1One place for all business data – Every source system feeds a single platform, so finance, sales, HR, and operations data sit side by side and can be connected. 2One way of processing it – Every source goes through the same standardized stages, so data is cleaned and shaped consistently no matter where it came from. 3One definition of every business rule – Business logic – how revenue is grouped, how a meeting is classified, how an employee is counted – is defined once and reused everywhere. 4One layer of governance – Access is controlled centrally by role, so the right people see the right data without each report owner managing permissions separately. Why It Matters to the Business For leadership, the value of one data platform shows up in outcomes rather than architecture. A Single Source of Truth Every report reads from the same curated data, so the numbers agree across finance, operations, and management reporting. Faster Answers, Less Rework New reports and new data sources are added through configuration, not rebuilt from scratch. Teams spend time on insight instead of plumbing. Stronger Governance by Design Centralized, role-based access means security is enforced by the platform, not by individual report owners. Lower Long-Term Complexity One pipeline and one framework replace a patchwork of tools, reducing maintenance and dependency on specific individuals. Scales With the Business Adding a new system or entity follows the same pattern, so growth does not multiply reporting complexity. A Foundation for AI Clean, connected, governed data is exactly what AI, machine learning, and process mining need to deliver reliable results. Solution Architecture Overview We built our one data platform on Azure and Databricks. Here is how it fits together, from five source systems to a single, governed Power BI workspace. How the Architecture Works Step 1: Connect the Source SystemsBusiness Central, Finance & Operations, Dynamics 365 CRM, Zoho People, and Zoho Books are registered once in a central ingestion list that tells the platform what data to bring in. … Continue reading From Multiple Data Sources to Azure Databricks: A Zero-Downtime Power BI Migration for Future AI Readiness →

Summary Most organizations implement AI in a set sequence – connect systems, clean the data, then govern and track adoption. That is the right path, but we could help ourselves by implementing AI that eases the “Clean Data” process itself. This post flips the script: instead of using AI only for insights, use it to flag what is missing, overdue or stale in your Opportunities. An example from the Sales Opportunities review portal we run at CloudFronts shows how a Pipeline Risk area instils the habit of keeping Dataverse / D365 Sales data correct, so the AI that follows is closer to accurate. Related reading: Using Dataverse MCP with Claude to Unlock Business Insights for Senior Leaders and our AI Managed Services Agreement. Table of Contents 01Summary 02Where We Are on the AI Journey 03AI For Clean Data 04Example 05Conclusion Where We Are on the AI Journey We are somewhere on the journey in implementing AI at our organization. And in this process, we often are looking to implement AI in the organization in the below sequence – Connect systems via robust integrations. Clean the data for Analytics and AI. Implement AI governance and track adoption. While this is the right path to implement AI, we stick to the plan in implementing AI. And this isn’t incorrect. However, we could help ourselves by implementing AI that promotes easing the “Clean Data” process. AI For Clean Data So, let’s flip the script for a bit – “Clean Data for AI” can start with “AI for Clean Data”. Let me explain with a use case – You are a Sales Lead at a professional services firm. You are supposed to make sure Opportunities are correctly tracked with the right probabilities, follow ups and have clean prospect data in them. Now, implement an AI that flags the data discrepancies instead of typically using AI for “AI Insights”. Let AI tell you – “Something is missing” “Something is overdue” “You have not communicated yet” “There’s no address or website for the Opportunities” “Revenue numbers or follow up dates are missing” Now most times, it might not be relevant to put this info – there can always be 5% exception in the data. However, this promotes cleaning the data that matters for the actual AI to implement by instilling good habits. Example Now, I’m running this portal for the Sales Opportunities review of the Management. I’m supposed to keep the Opportunities always updated for the management to have a true view of the pipeline and probabilities. The Sales Opportunities review portal – pipeline by quarter and Hot Opportunities, with the Pipeline Risks area running down the left. Due to busy schedule, things can fall through and the data continues to become stale and outdated. It might not show what Opportunities really are Hot or it might show some other Opportunities as Hot because I didn’t update the notes when probability dropped. So to tackle this problem, on the main pane itself – I’ve added a Pipeline Risk area. This will look at the existing data and flag me anything which should be incorrect. The Pipeline Risk area flags what looks incorrect – overdue deals, stalled engagement, accounts with no recent activity notes. Now whether it is true or not is up to me – but this puts me in a habit to make sure I always update my Dataverse / D365 Sales Opportunities correctly, so the AI Summary for Hot Opportunities improves and shows relevant data at all times. Now if you extrapolate these to bigger actions across all AI implementations of flagging incorrect data to the end user – it promotes good habits that make the intended AI to be closer to accuracy in its own non-deterministic nature. This is what is implemented at CloudFronts for our Sales efforts and similar versions are implemented for our customers using Dynamics 365 CRM/Sales for their implementations. Conclusion This might be a small trigger for a human change, but it has its compounding effects in implementing AI at your organization that directly co-relate to a production use case being a success or a failure. Human-in-the-loop is very much a reality and a necessity that we think it is. Further, the higher order of AI implementations like automated decision making can follow. Want AI That Keeps Your CRM Data Honest? If you’re exploring how to put AI on top of Dynamics 365 or Dataverse, we’d be glad to talk through where it makes sense to start. Keeping this running beyond the first use case is what our AI Managed Services Agreement is built for. Contact Us AI Managed Services Agreement Priyesh Wagh Microsoft AI ERP MVP, Practice Manager · cloudfronts.com Priyesh Wagh is a Practice Manager at CloudFronts and Microsoft AI ERP MVP. Priyesh works with his team in delivering Dynamics 365 business applications implementation to CloudFronts global customers, mainly in the US and Europe. Connect with Priyesh on LinkedIn.

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 →

The Warning Signs Were Always There – Project Risk Engine Summary On most delivery projects, the warning signs appear well before the escalation. They sit in email threads, support case notes, overdue invoice reminders, and resource utilization reports – scattered across systems that nobody has the time to cross-reference every week. By the time a project gets formally marked at risk, it is usually already a difficult conversation. This post shares what we built at CloudFronts to solve that problem from the inside. The Project Risk Engine uses a multi-model AI approach running on Azure Databricks to read unstructured project communication, score project health, and flag projects in RED – all surfaced to project managers inside Microsoft Teams through Databricks Genie, in plain English. We built it for our own PMO first. This article walks through why we built it, how it works, and what it changed. Table of Contents 01 Where This Started 02 Where Project Health Actually Lives 03 What the Risk Engine Does 04 How It Works – Four Layers 05 How a Project Gets Flagged RED 06 Genie in Teams 07 What Changed for the Team 08 Who It Helps 09 How to Implement This 10 Challenges We Faced 11 FAQs 12 Conclusion Where This Started This did not start as a product idea. It started as a recurring frustration inside our own team – the group at CloudFronts responsible for delivery and billing excellence. Three things kept happening. Early warning signs were buried in long email chains, so risks only surfaced after they had grown. Project managers had no quick way to assess project health, which meant the team reviewed each project by hand every week just to work out where things stood. And because we run many projects simultaneously, it was easy for a real problem to slip through unnoticed. Here is a real example. One of our clients had a support agreement coming up for renewal. It is the kind of thing everyone assumes someone else is tracking – but it was not flagged until almost the last day. If that client had decided not to renew, leadership would have had no early warning at all. The information was there. It just was not in front of anyone in time. In another case, a project had two phases and the client had not yet confirmed the scope for the second. That was a clear risk to the final payment. Most of us were aware of it in some abstract way – but the project was not formally flagged until the invoice was already due. A few weeks earlier would have made a real difference. “The warning signs were already there. They were just scattered, and easy to miss until it was too late.” Where Project Health Actually Lives A project’s health is not in one place. It is spread across four areas – and any one of them, left unmonitored, can become a risk that affects cash flow, client relationships, or delivery quality. Booking Contract renewals, new work coming in, and MSA status. A contract quietly approaching expiry is a risk most teams only notice when it is almost too late. Billing & Delivery Project status, open risks, support tickets, internal notes, and the client emails tied to them. This is where the unstructured signals sit. Collection What has been invoiced, what is outstanding, and what is running overdue. Delayed invoicing and unpaid milestones are early indicators of a project in trouble. Resource & Utilization Who is working on what, how busy they are, and where allocation gaps are forming. Low utilization on a contracted engagement is a billing risk waiting to happen. Any one of these on its own does not tell you much. You only see the full picture when you put all four together – and that is exactly what the engine does. What the Project Risk Engine Does 1Unifies the data – Delivery, support, billing, and resourcing data from Dynamics 365 CRM and Outlook is pulled into one governed dataset on Azure Databricks, structured through a Medallion Architecture (Bronze → Silver → Gold). 2Reads the unstructured signals – AI reviews client emails, internal notes, and case history to surface hidden threats: delays, blockers, escalation patterns, and unanswered client requests that never make it into a status field. 3Scores and flags – Every project receives a health score from zero to ten, along with a risk summary, identified threats, and next recommended actions. Projects meeting RED criteria are automatically flagged. 4Makes it conversational – Project managers can ask questions about any project in plain English, directly inside Microsoft Teams through Databricks Genie. No dashboards to open, no reports to pull. How It Works – A Multi-Model, Four-Layer Approach The risk analysis is not a single AI call. It is a deliberate, layered process – lightweight checks first, heavy AI only where it is needed. This keeps it fast and cost-efficient while ensuring accuracy on the things that matter. Layer1 Rule-Based Pre-Filter No AI involved. Simple rules filter out inactive email threads not part of any recent communication, eliminating noise before any model is engaged. Layer2 Lightweight AI Triage A smaller model sorts remaining threads into four categories: active, completed, informational, or waiting. Only active and waiting threads move forward. Layer3 Deep Risk Analysis A larger model – Claude Sonnet 4.5 – runs deep analysis on threads that survived the first two layers. It is used here because this stage requires stronger reasoning: detecting underlying threats, assessing likelihood, and estimating impact. Layer4 Executive Summary Everything is rolled up into a project health score (0–10), top threats, and recommended next actions – a clear, evidence-backed picture of where each project stands. Solution Architecture Here is how the full architecture fits together – from data sources through to the project manager asking a question in Teams. Data flows from Dynamics 365 CRM and Outlook → Azure Logic Apps → ADLS Gen2 Medallion layers → Azure Databricks → Genie AI → Microsoft Teams … Continue reading How CloudFronts Built a Project Risk Assessment Engine with Databricks Genie →

Summary We built a Databricks Genie agent for our own PMO at CloudFronts, running on Dynamics 365 data held in a Databricks lakehouse. Project managers ask a question in plain English and get an answer back across resource utilization, time tracking, billing and milestones, tickets and cases, and project status. This blog covers what the agent does, what email sentiment analysis shows that the numbers do not, and how it works inside Microsoft Teams. Table of Contents Introduction The Challenge The Solution See It in Action Business Impact Frequently Asked Questions Conclusion Introduction This started inside our own PMO — the Billing and Delivery Excellence function at CloudFronts. We learned about a project risk when someone escalated it. The warning signs came earlier than that, in email threads and internal notes, but reading every thread across every project each week was not work anyone could take on. The rest of the picture was split across systems. Billing held the invoice that had passed its due date, delivery held the milestone that had moved, support held the ticket that had been open for weeks. No one screen put those next to each other, so the PMO opened each project every week and compiled the status by hand. So we built the agent for ourselves first: a Databricks Genie agent running on Dynamics 365 data held in a Databricks lakehouse, which project managers query in plain English. The Challenge Dynamics 365 Project Operations holds everything a project manager needs — resource assignments, logged hours, billing milestones, project budgets, and delivery timelines. The data is there. The challenge is that getting specific answers from it still requires navigating multiple modules, running reports manually, and in many cases, exporting to spreadsheets to piece things together. This created a set of questions that were surprisingly hard to answer: Identifying which resources are overutilized or sitting idle requires pulling allocation data and comparing it manually against actual hours logged Understanding whether a project is at risk means cross-referencing milestone progress, budget consumption, and team capacity — a process that can take hours Billing questions — what has been invoiced, what is pending, what is approaching a milestone — require moving between finance and project views that are not always aligned Status updates for leadership need to be manually compiled, often pulling from data that was accurate yesterday but may have shifted today The result is that project managers operate on a lag — making decisions based on reports that reflect the past, not the present, and spending time producing those reports instead of acting on them. The Solution — A Genie Agent Built on Databricks and D365 Project Operations We built a Genie agent on Azure Databricks, connected to Dynamics 365 Project Operations. Project managers can now ask questions in plain English and get answers drawn directly from their project data — without building a single report. The agent is designed around the areas that matter most to project managers on a daily basis: a. Resource UtilizationThe agent can answer questions about who is overallocated, which resources have capacity available, and how utilization is trending across the team or a specific project. What previously required pulling allocation reports and comparing them against timesheets can now be answered in a single question. b. Time TrackingProject managers can ask which team members have not logged hours for the week, where hours are being spent versus what was planned, and whether a specific project is tracking within its estimated effort. The agent surfaces this from logged timesheet data in D365. c. Billing and MilestonesThe agent connects billing milestone data with project progress, allowing project managers to ask what is due for invoicing, which milestones are approaching, and whether any billing triggers are at risk of being delayed. This brings finance and delivery into the same conversation. d. Tickets and CasesThe agent surfaces open tickets and cases linked to a project — how many are open, which are overdue, how they are distributed across team members, and whether any are blocking delivery. Project managers can ask for a snapshot of issue health across one or multiple projects without navigating case queues manually. e. Email Sentiment AnalysisOne of the more telling signals of how a project is going is often hiding in the inbox. The agent analyses email communication patterns and sentiment across project stakeholders — flagging when tone is shifting, when a client’s responses are becoming shorter or more urgent, or when concerns are being raised repeatedly. This gives project managers an early, qualitative read on relationship health before it shows up in a formal escalation. f. Project StatusInstead of assembling a status report, a project manager can ask for a summary of where a project stands — budget consumed, milestones completed, risks flagged, and remaining timeline. The agent compiles this from D365 data and presents it in plain language, ready to share or act on. The conversation does not stop at one question. A project manager can ask a follow-up — drill into a specific resource, filter by project phase, or compare two projects side by side — and the agent follows the thread, refining its response at each step. Available directly in Microsoft TeamsThe Genie agent is also available as a Databricks App inside Microsoft Teams — meaning project managers do not need to switch tools to get answers. They can ask questions about their projects, resources, and billing directly from the Teams interface they already work in every day. See It in Action Weekly Work Summary — Time Tracking in ActionA project manager asks Genie for a summary of work completed last week. The agent returns a full breakdown — total hours logged, billable vs non-billable split, project-wise distribution, and key observations — in seconds. Case Detail View — Tickets and Cases in ActionA project manager asks for details on a specific case. The agent surfaces the full case record — status, owner, priority, activity timeline, and a follow-up alert — without the manager needing to … Continue reading From Project Reporting to Project Intelligence: How AI is Transforming Project Management →

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

Summary We built an AI-powered meeting briefing solution on top of Dynamics 365 CRM that assembles a complete, structured briefing – customer details, meeting history, email insights, professional profile, and open action items – with a single button click, delivered in under 30 seconds. Powered by Azure Functions and Azure OpenAI GPT-4.1, the solution sits inside the existing CRM workflow with zero change to the tools the team already uses. Built for private equity and asset management firms where missing context isn’t just inefficient – it’s a credibility cost. Table of Contents 01Summary 02Customer 03Challenge 04Solution 05Architecture 06Briefing 07Intelligence 08Enterprise 09Benefits 10Why PE About the Customer Customer Overview Our customer is a US based private equity investment firm focused on partnering with and growing businesses over the long term. With a portfolio of investments and a strong emphasis on operational excellence and value creation, the firm required an AI-powered solution to streamline client preparation, consolidate information from multiple sources, and enable investment professionals to make more informed decisions before meetings. The Challenge Data Exists. Context Doesn’t. Modern CRM platforms are excellent at storing information. On their own, they’re not built to assemble it into something a person can use in the next fifteen minutes. It’s 8:45 AM. Fifteen minutes before an important client call, a relationship manager has four tabs open – CRM, Outlook, LinkedIn, and a folder of old meeting notes – trying to reconstruct the relationship before the call starts. Nothing here is missing. It’s just scattered. And the fifteen minutes meant for preparing get spent finding what to prepare instead. As firms manage more relationships – more portfolio companies, more LPs, more prospects – this problem doesn’t stay the same size. It grows with every account added to the book. A typical prep routine still looks like this: 01Reviewing CRM records for account history 02Reading through recent email threads 03Searching old meeting notes for what was actually discussed 04Looking up a contact’s current role and background 05Trying to remember what was promised – and what’s still open Each source holds something useful on its own. None of them, alone, tells the whole story – and stitching them together by hand is what actually eats the morning. The result is inconsistent prep, lost productivity, and context that depends entirely on who happens to be covering the account that day. Today 01Manually researching each contact across CRM, LinkedIn, and email 02Meeting notes scattered across CRM records, shared drives, and inboxes 03Generic AI summaries that miss relationship context 04Key background often missed before the meeting even starts With AI-Powered Briefings 01A structured briefing generated in the team’s own template, on demand 02Contact details, professional background, and CRM data pulled automatically 03Past meetings and email threads summarized with real context 04The team arrives prepared in seconds, not hours Turning CRM Data Into Meeting Intelligence One Click. A Complete Briefing. We built an AI-powered meeting briefing solution that sits directly on top of Dynamics 365 CRM — adding a single button to the record teams already work from, with no change to the existing workflow underneath it. 01 Click The relationship manager clicks “AI Meeting Insights” on the contact or prospect record – the trigger for everything that follows. 02 Gather Azure Functions orchestrates the retrieval: CRM history, grouped email threads, past meeting notes, and the contact’s public professional profile. 03 Analyze Azure OpenAI GPT-4.1 reads everything chronologically, identifying what was discussed, what’s outstanding, and the tone of recent exchanges. 04 Deliver A formatted briefing, built in the team’s existing template, lands in minutes — a progress indicator keeps the user informed while it runs. In practice, the full sequence — from button click to finished document – runs in under 30 seconds. Solution Architecture How It Works — End to End From a single button click in Dynamics 365 to a formatted briefing delivered in under 30 seconds. Inside the Document What’s Actually in the Briefing Instead of a generic summary, the output is built around the fields teams actually need before walking into a conversation. 01 Customer & Contact Details Pulled directly from the CRM record — no re-typing, no re-checking. 02 Previous Meeting Summary Condensed from historical notes into a concise interactions record. 03 Recent Email Insights Key topics and sentiment from the latest correspondence. 04 Business Overview A short, current description of the company and its context. 05 Meeting Attendees Who’s expected in the room, drawn from calendar and CRM data. 06 Professional Profile Reference Publicly available background on the contact, added automatically. The Intelligence Behind the Briefing Structured, Not Just Summarized What makes this different isn’t simply the use of Generative AI — it’s the structure behind it. Rather than summarizing documents in isolation, the model reads a customer’s engagement history chronologically: completed and upcoming meetings, attendees, recent conversations, sentiment, and open action items, resolved into one coherent picture. Every section of the briefing is mapped back to a defined source. Customer details come from CRM. Meeting summaries come from meeting records. Communication insights come from email. Profile information is referenced separately and flagged as such. That traceability is what keeps the output contextual and consistent, rather than a plausible-sounding but generic AI summary. It’s also reviewed, not just trusted. Fields the model is less confident about are flagged for a human to check, and the team approves AI-generated sections before a briefing goes out. The goal isn’t to remove judgment from the process — it’s to remove the search that used to come before it. Built for the Enterprise Enterprise-Ready by Design This runs inside the systems and controls teams already trust — not alongside them. 01 Role-Based Access Visibility follows existing Dynamics 365 security roles — no new permission model to manage. 02 Data Protection Data is encrypted in transit, credentials sit in a secure Azure vault, and only the fields needed reach the model. 03 Graceful Failure Handling A failed run is flagged clearly, prior briefing data stays intact, and the user can … Continue reading How AI-Powered Meeting Briefings Are Transforming Client Preparation for a Boston based Private Equity Firm →

With the advent and advancement of AI and vibe-coding taking center stage, a wonderful possibility has opened up. This isn’t something new – it was always possible in theory, but it was a long shot to actually achieve. “Headless” is a common term used to describe this idea: While this opens up realistic possibilities and promising gains, it must be taken with a grain of salt and done the right way – weighing the outcomes against the risks. Not knowing the right approach gives way to disruption, putting reliability at risk. What Goes Into Building a Headless Business Application Interface Here’s how we approach designing workflows for the headless approach: Our Preferred Approach for Microsoft Business Applications At this point, Microsoft hasn’t announced a headless offering, so we built our own. Here’s what we chose, and why: If the “Headless” Approach Is So Easy, Should Everyone Do It? Here are a few things to consider: To conclude, a headless approach to business applications has opened up a ton of possibilities. But it has to be implemented with caution and the right advisory support -not as a DIY shortcut just because the UI/UX can be described to AI and built quickly. Done the right way, a headless approach preserves the integrity of your core systems, delivers genuine value for your use cases, and becomes an intentional addition to your existing stack – not just another UI you now have to maintain. Build a UI that works the way your team does – without putting your core systems at risk. Connect with us at transform@cloudfronts.com to get started.

Summary We implemented an automated cost control process for our internal AI Sales Insights solution running in Azure. Azure Budget Alerts were connected with Automation Runbooks to automatically stop resources once spending crossed a defined threshold. The setup reduced manual monitoring and helped us maintain tighter control over Azure consumption. The solution used native Azure services with Managed Identity authentication for secure automation. The same approach can be extended to Azure Virtual Machines, App Services, Databases, and other Azure resources. Azure Budget Alerts integrated with Automation Runbooks for automated cost control Table of Contents 1. Why We Needed This 2. Solution Overview 3. Azure Services Used 4. Step 1: Create the Azure Budget 5. Step 2: Create an Action Group 6. Step 3: Create the Automation Runbook 7. Step 4: Enable Managed Identity 8. Step 5: Assign Required Permissions 9. Step 6: Test the Complete Flow 10. Business Impact 11. Frequently Asked Questions 12. Conclusion Why We Needed This Our AI Sales Insights solution uses Azure services such as Function Apps and AI processing components to generate and process sales insights. Since the environment runs on a Pay As You Go subscription, costs can increase unexpectedly if resources continue running after active usage hours or during extended testing cycles. Initially, we were monitoring costs manually through Azure Cost Management dashboards and email alerts. However, this approach had a few limitations: Alerts were sometimes noticed too late Resources continued running even after thresholds were reached Development environments stayed active longer than needed Manual intervention was required every time We wanted a simple solution where Azure could automatically take action when spending crossed a defined limit. Solution Overview We implemented the following workflow: Azure Budget continuously monitors subscription spending A Budget Alert gets triggered when the threshold is reached The alert calls an Azure Action Group The Action Group triggers an Automation Runbook The Runbook authenticates using Managed Identity The Runbook automatically stops the Azure resource This gave us a lightweight and reliable automation setup for controlling costs. Azure Services Used Service Purpose Azure Cost Management Monitor Azure spending Azure Budget Alerts Detect threshold breaches Azure Action Groups Trigger automation Azure Automation Execute PowerShell Runbooks Managed Identity Secure authentication Step 1: Create the Azure Budget We started by creating a budget inside Azure Cost Management. Azure Budget configuration for automated cost monitoring Budget Configuration Setting Value Budget Amount ₹800 INR Reset Frequency Monthly Forecast Alert 90% Actual Cost Alert 100% One important thing we learned during implementation is that Azure budget calculations are not always real time. If automation starts only at 100%, additional usage may already occur before the alert executes. Because of this, setting automation thresholds slightly earlier, usually around 85% to 90%, is safer for production environments. Step 2: Create an Action Group Next, we created an Azure Action Group. The Action Group acts as the bridge between the Budget Alert and the Automation Runbook. Set Action Type as Automation Runbook Select the Automation Account Link the target Runbook Once configured, Azure automatically executes the Runbook whenever the budget alert is triggered. Step 3: Create the Automation Runbook Inside Azure Automation, we created a PowerShell Runbook using Runtime Version 5.1. The Runbook dynamically accepts Azure resource values instead of hardcoded names, making it reusable across multiple environments. Dynamic PowerShell Script # Variables $ResourceGroupName = “{Your Azure Resource Group Name}” $FunctionAppName = “{Your Azure Function App Name}” # Authenticate using System Managed Identity try { Connect-AzAccount -Identity Write-Output “Successfully authenticated with Managed Identity” } catch { Write-Error “Failed to authenticate: $_” exit 1 } # Stop Azure Function App try { Stop-AzFunctionApp ` -Name $FunctionAppName ` -ResourceGroupName $ResourceGroupName ` -Force Write-Output “Function App stopped successfully” } catch { Write-Error “Failed to stop Function App: $_” exit 1 } Step 4: Enable Managed Identity To avoid storing credentials inside the script, we enabled System Assigned Managed Identity for the Automation Account. This allowed the Runbook to authenticate securely against Azure without usernames, passwords, or secrets. This approach is cleaner, more secure, and easier to maintain. Step 5: Assign Required Permissions After enabling Managed Identity, we assigned RBAC permissions to the Automation Account on the target resource. The following roles were used: Contributor Website Contributor Function App Contributor Without proper permissions, the Runbook may authenticate successfully but still fail while stopping resources. Step 6: Test the Complete Flow Before connecting everything to the Budget Alert, we tested the Runbook manually. Verify Managed Identity authentication Confirm the Azure resource stops correctly Validate RBAC permissions Test Action Group execution Once everything worked successfully, the Runbook was connected to the Budget Alert. Business Impact Area Before After Cost Monitoring Manual Automated Resource Shutdown Manual Automatic Response Handling Manual Action Required Automatic Resource Shutdown Cost Governance Reactive Proactive This setup helped us reduce unnecessary runtime costs and eliminated the need for continuous manual monitoring of our AI Sales Insights environment. Conclusion This implementation helped us build a simple and practical cost governance process for our internal AI Sales Insights solution. Instead of relying only on dashboards and email notifications, Azure now takes automated action whenever spending crosses the configured threshold. As AI workloads continue growing, automating cloud cost control will become increasingly important for maintaining predictable and manageable Azure spending. We hope you found this blog useful. If you would like to discuss similar Azure automation and cost optimization solutions, feel free to connect with us at transform@cloudfronts.com .

Marketing teams have always produced a steady stream of content, blogs, case studies, and articles. While this content captures valuable insights, it often tells only part of the story. Most blogs focus on technical implementations and how the work was executed, rather than clearly articulating the business problem, transformation process, and measurable outcomes. As a result, the overall impact created often remains in the background. Marketing team at CloudFronts started noticing a few consistent patterns: The issue was not a lack of knowledge or expertise. Our teams had deep experience. The real challenge was that customer insights were spread across different team members, and marketing did not always have a structured way to capture the full journey. That is when we started rethinking how we can capture the customer Journeys. The Challenge with Traditional Customer Content In every customer project, valuable knowledge exists across multiple roles. However, marketing rarely has direct access to all these perspectives at the same time. Without a structured process to capture insights across teams, much of the content tends to focus on technical implementation, since delivery teams are best positioned to describe how the solution was designed and implemented. While these blogs are useful, they often miss the broader story: For decision makers evaluating partners, this business context is often more valuable than the technical details alone. Recognizing this gap pushed us to rethink our content process. Our Shift: Turning Customer Insights into Strategic Content Instead of relying on ad-hoc blog contributions, we introduced a structured customer Journey capturing process. The process starts with something simple but powerful: a conversation with the delivery team. For every major customer engagement, marketing team schedules a dedicated discussion with the people who were directly involved in the project. This usually includes architects, consultants, project manager, and sometimes presales. During these sessions, we guide the conversation using a structured set of questions designed to uncover the full customer journey. We focus on areas such as: In many cases, the delivery team also walks us through the system they implemented. Seeing the solution in action helps marketing understand the practical value delivered to the customer. These discussions capture something that traditional documentation often misses: the real story behind the transformation. Building an AI-Powered Customer Knowledge Base Capturing the conversation is only the first step. The real transformation in our process begins when we introduce AI. We record and transcribe these discussions and combine them with existing project documentation, including: We then bring all this information into AI-powered tool called NotebookLM, creating a dedicated knowledge repository for each customer journey. Instead of navigating through multiple documents and scattered notes, marketing team now has one structured knowledge base containing the full project story. This changes how we approach content creation. Using AI to Identify the Best Blog Ideas Once the knowledge base is built, we use AI to analyze the information and help us identify the most meaningful narratives within the project. Our goal is not simply to generate blogs automatically. Instead, we use structured prompts to help AI discover the strongest story angles hidden within the customer journey. This helps us uncover ideas such as: Instead of producing just one blog from a customer project, we often identify multiple content opportunities from a single engagement. Moving Beyond Technical Blogs This new approach has significantly changed the type of content we create. Rather than publishing isolated technical blogs, we now build a structured content ecosystem around each customer story. This includes: Customer Journey Blogs A narrative that captures the full transformation from the business challenge to the final outcomes. Use Case Blogs Detailed articles explaining how specific solutions solved operational challenges. Customer Milestone Stories Updates on key project achievements such as major implementations, go-lives, and expansion phases. In essence, one customer engagement now supports multiple layers of storytelling. Why AI Matters for Modern Marketing AI is often discussed as a way to generate content faster. In our experience, its real value is different. AI helps us access knowledge that already exists within the organization but is often difficult to gather and use effectively. Every customer project generates a significant amount of insight: Without the right tools, much of this knowledge remains buried in documents, presentations, and internal meetings. AI allows us to analyze, connect, and transform this knowledge into meaningful stories. The Future of Customer Storytelling Through this process, we see marketing evolving beyond content production. Our role increasingly becomes the bridge between delivery expertise and market insight. By capturing customer journeys, organizing knowledge, and using AI to uncover meaningful narratives, we are moving from fragmented content creation toward intentional storytelling. In a market where decision makers want partners who truly understand their challenges, authentic customer stories carry far more weight than generic marketing messages. The organizations that stand out will not necessarily be the ones producing the most content. They will be the ones that capture and communicate the stories that truly matter. To conclude, in today’s market, decision-makers are not looking for generic content.They are looking for partners who understand their challenges and can prove impact. The organizations that stand out will not be the ones producing the most contentbut the ones telling the most meaningful, authentic customer stories. And with AI, we now have the ability to do exactly that at scale, with precision, and with impact.