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 Enterprises have spent years solving the data extraction problem — moving SAP data into warehouses, lakes, and reporting platforms. But extraction is largely a solved problem. The real challenge now is making that data understandable, trustworthy, and useful — to both business users and AI systems. That shift requires business context, metadata, and governance, not another connector. This blog shares observations from an enterprise data modernization assessment and offers a perspective on how SAP Business Data Cloud should be evaluated — not as just another extraction tool, but as a capability that can bring SAP data, business semantics, metadata, and governance closer together. It also examines why zero-copy data sharing, while valuable, is only part of the answer, and why metadata strategy should be defined before any platform is selected. The central argument is straightforward: AI without trusted business context produces answers that are technically valid but business-wrong. Before any AI layer is added, the foundation must be right — and that means starting with the right question: not “which tool?” but “what does this organization need its data platform to become?” Table of Contents 01 Introduction 02 Extraction Is No Longer the Challenge 03 BDC Is Not Just a Connector 04 Metadata Is the Foundation 05 Zero-Copy — Important but Incomplete 06 From Technical Data to Business Data 07 The AI Conversation 08 Evaluate the Outcome, Not the Tool 09 So, Why SAP Business Data Cloud? 10 FAQs 11 Conclusion Introduction Most conversations about SAP data integration start in the wrong place. They begin with extraction — which tool moves data fastest, which connector supports CDC, which platform has the best SAP adapter. These are reasonable technical questions, but they are increasingly the wrong ones to be leading with. The organizations genuinely advancing their data capabilities are not asking “how do we get SAP data out?” They are asking “how do we make SAP data understandable, trustworthy, and useful — to both our people and our AI systems?” This blog shares observations from an enterprise data modernization assessment and offers a perspective on how we should be thinking about SAP Business Data Cloud — not as just another extraction option, but as part of a broader conversation about metadata, business context, and what modern enterprise data platforms actually need to deliver. Data Extraction Is No Longer the Biggest Challenge Over the years, organizations have invested heavily in moving data from ERP systems into data warehouses, data lakes, and reporting platforms. The architecture often becomes: SAP → Extraction → Staging → ETL → SQL → Semantic Model → Power BI It works. But over time, every additional layer introduces another copy of data, another technology to maintain, another process to monitor, and another place where business logic can be implemented. In one enterprise modernization assessment, the existing landscape included SAP, DP Agents, SAP Datasphere, SSIS, SQL Server, and Power BI. The challenge was not a shortage of technology. The challenge was multiple movement layers, duplicated logic, and no single place where the data could be understood as a whole. That is where the conversation about SAP BDC needs to start. BDC Is Not Just Another SAP Connector If we compare SAP BDC only on extraction capability, the difference becomes difficult to justify. Most modern tools — BDC, Datasphere, and various DBT-based approaches — can all support data extraction and incremental or CDC scenarios to varying degrees. But when we introduce another dimension — business context — the discussion changes entirely. A modern enterprise data platform needs to answer: 1What does this field actually mean in business terms? 2Is this a customer, vendor, product, or financial measure? 3What is the agreed business definition — and who owns it? 4Which KPIs depend on this data element? 5How does this business object relate to others? 6Can this data be trusted — and can an AI agent understand its context? This is where metadata stops being a nice-to-have and becomes the foundation on which everything else depends. Metadata Is the Foundation Metadata should be one of the first things defined before selecting a data platform. Technology should follow business requirements — not the other way around. A modern metadata strategy needs to cover: Business Metadata Technical Metadata Relationships Business Glossary Semantic Definitions Data Quality Ownership Lineage Classification & Change Why does this matter? Because the direction of enterprise analytics is shifting: From “Where is my data?” To “What does my data mean?” And eventually “Can AI understand my data and give me a trusted answer?” That progression requires context — and context requires metadata. You cannot shortcut this by starting with AI. “The future of analytics is not about finding data faster. It is about understanding data better — and making that understanding available to both people and AI systems.” Zero-Copy Is Important — But It Is Not the Whole Story One of the strongest technical capabilities highlighted in the assessment is BDC’s managed zero-copy data sharing approach. It can reduce unnecessary data movement while allowing SAP data to participate in the broader enterprise data architecture without being physically duplicated across systems. This matters because data movement has a cost — in infrastructure, in latency, in maintenance, and in the accumulation of inconsistent versions of the same data sitting in different places. But zero-copy should not be positioned as the only reason to choose BDC: Zero-copy solves the movement problem — reducing duplication and infrastructure cost Metadata and business semantics solve the understanding problem — making data meaningful and trusted The second problem is becoming increasingly important, and it is the one most extraction-focused evaluations fail to address. From Technical Data to Business Data A traditional data platform is typically designed around tables and pipelines. A modern data platform needs to move closer to business objects and business domains. Instead of asking a business user to understand technical SAP table names like VBAK, VBAP, KNA1, or MARA, the platform should provide business-level concepts: Customer → Sales Order → Product → Revenue → … Continue reading SAP Business Data Cloud: More Than a Data Platform →

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 →

Using Dataverse MCP with Claude to Unlock Business Insights for Senior Leaders Summary MCP Servers are making their way into the mainstream, connecting AI applications together with the AI tool of your choice to utilize them. One such powerful MCP Server, amongst several built by Microsoft, is the Dataverse MCP server. This post walks through what Dataverse MCP brings to users across five capability areas, practical use cases by role, the operational efficiency gains we’ve seen internally at CloudFronts, and answers to the questions this naturally raises around data security and scope. Table of Contents 01 Summary 02 A Quick Recap on MCP Servers 03 Dataverse MCP Capabilities 04 Use Cases by Role 05 Business Impact 06 FAQs 07 Conclusion A Quick Recap on MCP Servers Like several business and personal applications have come up with their own MCP Server, one such powerful MCP Server amongst many by Microsoft is the Dataverse MCP server. Before talking about some use cases, here’s a quick recap of what MCP Servers in general are, to set some context for readers stumbling upon “MCP Servers” for the first time: 1They are an API connection between applications, but capable of understanding human language to connect and execute. 2Don’t need technical knowledge to connect different applications and interact with each other functionally, operating on natural language. 3Widely used by AI Agents to talk to each other and get things done. 4Continue to work after the initial setup. So, given that, here’s what Dataverse MCP brings to users. Dataverse MCP Capabilities Briefly, there are 5 main categories in which Dataverse MCP Servers help: 1Discovery — Use Dataverse MCP to explore the schema of your Dynamics 365 CE / Dataverse environment. Assuming you are a technical team member, you need to explore behind the scenes when customizing solutions, which is where Dataverse MCP can be useful. It’ll go under the hood and make sense of your query to bring you the technical details, instead of you having to remember how it is set up and collate that information. Useful for Solution Architects. 2Query — Query data in simple language by just describing, in human language, what you would otherwise design an Advanced Find for. And when it returns this data, it can go a step further and process or work on the info you asked it to fetch (maybe package it in an Excel file, ready to download from your AI application). 3Record CRUD — Although it’ll ask you for permissions, you can ask your AI tool, connected through Dataverse MCP, to create, update, and delete records. The other day, I just made my Time Entries for the week and asked it to collect Invoice information for a custom entity and bulk-update a custom status on some contacts. So, anything that would need you to go into the system and scrub through forms can be done using Dataverse MCP. 4Schema — I would advise using this carefully. Dataverse MCP is capable of also updating the schema, like creating new tables, fields, etc. If done correctly, with the correct publisher and established naming conventions, this is possible. But I did find myself stuck with incorrect schema creation and a bit of a mess. So, this one is to be used carefully. At times, the schema definition is misunderstood, and you’ve already altered what’s set. 5Skills/Playbooks — Upsert and Delete Skills. This topic on Dataverse Skills deserves a separate blog post in itself. Use Cases by Role To keep things simple, here are some common use cases by role on how Dataverse MCP can be useful: 1Solution Architect — you can use Dataverse MCP to query metadata/schema to help identify what the developers have done, if going through developer documentation is too much to go through. 2Manager — if you want to query some data, you can do this by simply establishing some common vocabulary as context first, and then letting Dataverse MCP query what you need, then process that info retrieved within the chat context to make better sense of what you need. 3Developer — if you want to create a series of tables and a templatized field-set in those, you can simply do so by uploading an Excel file and utilizing Dataverse MCP to create the right fields and schema based on the customizations described. Doing this at scale for multiple customers is painstaking and time-consuming, so utilize Dataverse MCP to get this turned around quickly. 4Even your own data — to identify pitfalls and take measures immediately. Every Monday I need to check where I should pay attention the most and get sticking issues out of the way, and this gives me a good understanding, or a high-level picture, of where I need to pay attention. A weekly check-in: asking Claude, connected via Dataverse MCP, to review time entry compliance over the last 90 days. Business Impact We have enabled Dataverse MCP for all team members to help with their operational efficiencies. Business Impact here is operational efficiency gains — if this saves me an hour a day, it saves me 20 hours a month, and about 240 hours a year, which is a significant gain on a broader time horizon. So, if I multiply this by 15 team members, then we are collectively saving 3,600 hours a year, which can be taken back to focus on growth and client projects more so. FAQs Now, this naturally brings some questions to mind, which I thought to anticipate and answer: 1Is the data being used by Claude? No data is copied over to Claude or its models — only MCP (Model Context Protocol) is used to have a conversation with your existing data, in this case Dataverse. No data is sent anywhere. 2Will users be able to query and modify data belonging to someone else? No — only data which belongs to self is available for any operation. It follows the security architecture of the hosting SaaS application itself, in this case Dynamics 365 CRM / Dataverse. … Continue reading Using Dataverse MCP with Claude to Unlock Business Insights for Senior Leaders →

Summary Our previous article (Check out my previous blog here – Transforming Return Logistics for a USA Manufacturer: Automating Shipment Processing with Dynamics 365 Customer Service) covered how we integrated Dynamics 365 Customer Service with FedEx to automate the creation of return shipments for a USA-based manufacturer — solving the shipment-creation half of the requirement. But creating a shipment is only the start. Once a package leaves the customer, the business still needs to know what’s happening to it — has FedEx received it, is it still with the customer, or has it been delivered? Previously, agents answered this manually by checking the FedEx site case by case, which didn’t scale. The second phase closes that gap with a scheduled integration between Dynamics 365 Customer Service, Dataverse, Integration, and the FedEx Tracking API. It automatically identifies eligible Cases, pulls the latest FedEx tracking events, determines whether the shipment has entered FedEx possession, and updates the Case accordingly. The result is a closed-loop process: Create Shipment → Capture Tracking Number → Monitor Shipment → Detect FedEx Possession → Update CRM. This article covers how the integration was designed, how tracking events were interpreted, how Integration processes the API response, and the technical considerations involved in building against the FedEx Tracking API. Table of Contents From Shipment Creation to Shipment Visibility The Business Challenge Solution Overview Identifying Cases Requiring Tracking Calling the FedEx Tracking API Understanding FedEx Tracking Events Determining Whether a Shipment Has Been Tendered Updating Dynamics 365 Customer Service Handling Exceptions and Empty Tracking Responses Technical Architecture Designing the Integration Around Business Events Business Impact FedEx Tracking API Limitations and Guardrails Final Thoughts This Blog Explains Why shipment creation alone was not enough to complete the return logistics process. How Dynamics 365 Customer Service was connected to the FedEx Tracking API. How eligible Cases are identified automatically. How tracking events such as Dropped Off, Picked Up, and In FedEx Possession are interpreted. How the solution determines when a shipment should be considered tendered. How the latest tracking information is written back to Dynamics 365. How Integration handles API responses and exceptions. The limitations and throttling considerations of the FedEx Tracking API. From Shipment Creation to Shipment Visibility In the previous implementation article (Check out my previous blog here – Transforming Return Logistics for a USA Manufacturer: Automating Shipment Processing with Dynamics 365 Customer Service), the primary objective was to eliminate the manual process of creating FedEx return shipments. The customer service representative could initiate the shipment directly from the Dynamics 365 Case. The system handled the rest: Collect Case and customer information. Register the shipment with FedEx. Generate the return label. Capture the tracking number. Store the tracking number against the Case. Send the return label to the customer. That created a significant improvement in the shipment creation process. However, there was still a gap. The tracking number was now inside Dynamics 365, but the shipment status was still outside Dynamics 365. This highlighted an important principle in integration design: True integration goes beyond just creating data in an external system—its real power lies in closing the information loop. By including end-to-end shipment tracking, we ensure full visibility, proactive exception management, and a seamless experience from order creation to final delivery. The second phase therefore asked a different question: Once Dynamics 365 creates a shipment, can it also continuously understand what is happening to that shipment? The answer was yes. The Business Challenge The existing process (Before FedEx Intg. Was implemented) required customer service representatives to manually monitor return shipments. A typical workflow looked like this: Open Dynamics 365 Customer Service. Find the Case. Copy the FedEx tracking number. Open the FedEx tracking website. Enter the tracking number. Enter the tracking number. Review the latest shipment event. Review the latest shipment event. Determine whether the package had been handed over to FedEx. Return to Dynamics 365. Update the Case status. Repeat the process for other Cases. This created several operational challenges. 1. Repetitive Manual Work Tracking information had to be checked repeatedly for multiple shipments. 2. Context Switching Agents moved between Dynamics 365 and the FedEx tracking website to complete a single business process. 3. Delayed CRM Updates Even when FedEx had already received a shipment, the corresponding Case could remain unchanged until somebody manually checked it. 4. Human Interpretation FedEx returns multiple tracking events and statuses. Agents had to interpret those events and determine which ones represented meaningful milestones for the organization’s return process. 5. Poor Scalability As the number of return shipments increased, the amount of manual tracking increased with it. The business did not need another screen for agents to monitor. It needed the tracking information to come back to the system where the business process was already being managed: Dynamics 365. Solution Overview I extended the previous FedEx integration by introducing an automated shipment-tracking process. The solution uses: Dynamics 365 Customer Service Dataverse Integration FedEx Tracking API The high-level process is: Dynamics 365 Customer Service | v Active Cases with Tracking Numbers | v FedEx Tracking | v Tracking Response | v Interpret Scan Events | v Determine Shipment Status | v Update Dynamics 365 Case The process runs automatically on a scheduled basis. There is no requirement for a customer service representative to manually visit the FedEx website for every shipment. Functional Integration Approach The functional design was intentionally centered around the existing Case lifecycle. The Case already contained the information required to identify the shipment. The integration therefore did not introduce a separate tracking application or another user interface. Instead, it used the Case itself as the operational source of truth. The process can be summarized as: Scheduled Trigger ↓ Find eligible Cases ↓ Read Tracking Number ↓ Call FedEx Tracking API ↓ Read Tracking Events ↓ Interpret Latest Status ↓ Determine Tendered / Not Tendered ↓ Update Case This approach keeps the integration aligned with the business process rather than creating a separate operational process around the API. Identifying Cases Requiring Tracking … Continue reading Closing the Loop on Return Logistics: How a U.S.-Based Consumer Appliance Manufacturer Automated FedEx Shipment Tracking in Dynamics 365 Customer Service →

What the CloudFronts PMO Does on a Microsoft Dynamics 365 ERP Project Summary Most Microsoft Dynamics 365 ERP implementations that struggle do so for the same reason: the technology was delivered, but the collaboration wasn’t. The CloudFronts PMO runs every Dynamics 365 ERP engagement on a structured operating model, onsite discovery, daily working sessions, Azure DevOps tracking, a clear RACI framework, and tiered communication, so both teams always know what’s happening, what was decided, and what comes next. On a real Dynamics 365 deployment for a Leading North American commercial vehicle manufacturer, this structure replaced scattered status updates with a live, always-current view of project health that protects the Client well beyond go-live. Table of Contents 01 Summary 02 About the Engagement 03 The Challenge 04 The PMO Approach 05 RACI Framework 06 Environment Pipeline 07 Communication Cadence 08 Documentation & Handover 09 Business Impact 10 FAQs 11 Conclusion About the Engagement Engagement Spotlight A Leading North American Commercial Vehicle Manufacturer Dynamics 365 ERP Rollout, Run Onsite from Day One What follows comes directly from a real Microsoft Dynamics 365 ERP deployment CloudFronts is running for a manufacturing Client. Before a single configuration was touched or a user story written in Azure DevOps, our Solution Architect and the project manager visited the Client’s manufacturing facility together, walking the production floor, spending time in warehousing and operations, and sitting with the teams who work with these processes every day. The goal was straightforward: understand the business before touching the system. Every practice described below, the onsite visit, the daily sessions, the structure, is something the team lived, not something read about. The Challenge Dynamics 365 ERP projects don’t usually fail because the technology can’t do the job. They fail because of how teams collaborate, communicate, and take ownership throughout the project. Without a structured PMO, teams on ERP engagements frequently find themselves asking: 1Did the Client actually sign off on this, or did we just move on? 2Who owns this decision, us or the Client? 3Is this environment actually production-ready? 4Has this been tested, or just built? 5Will the Client’s team be able to run this on their own after go-live? Left unanswered, these questions turn into scope creep, missed sign-offs, go-live delays, and end users who were never truly ready. The PMO Approach To close that gap, the CloudFronts PMO runs every Dynamics 365 ERP engagement on four connected practices: Onsite Discovery Walking the production floor and operations areas before configuration starts, so scope reflects the real business, not just what’s written in a document. Scope Tied to Outcomes Every phase begins with a written scope, and milestone sign-offs are tied to confirmed outcomes, not calendar dates. Daily Working Sessions Four sessions a week, Monday through Thursday, where work is demonstrated, tested, and decided on in real time. Azure DevOps Tracking Every Epic, Feature, User Story, Task, and Bug tracked on one shared board, visible to the Client at all times. RACI Framework One of the first things the CloudFronts PMO does on any Dynamics 365 ERP engagement is establish a clear RACI matrix, who is Responsible, Accountable, Consulted, and Informed for every area of the project. It isn’t a governance document that sits in a folder; it’s a shared agreement people refer to when a decision needs to be made. Project Area Client CloudFronts Requirements & business process documentation Accountable Responsible Build & configuration — Responsible & Accountable Testing & go-live Accountable Responsible (supports & executes) Environment Pipeline The CloudFronts PMO maintains a full environment pipeline for every D365 ERP implementation. Each environment has a defined purpose, and nothing reaches Production that hasn’t been proven first. 1Developer VM — configuration and build work begins here 2QA — demonstrated and validated in daily working sessions 3UAT / Sandbox — the Client’s business users test and sign off 4Gold — the clean backup environment 5Pre-Production — a full mock cutover before the real go-live 6Production — go-live, after repeated proof it works The Client goes live with confidence because they have already seen their system work under production-like conditions, repeatedly. Communication Cadence The CloudFronts PMO structures communication deliberately across three levels, so the right people get the right information at the right time: Every 2 weeks — Management Status readout for leadership, covering project status, risks, and decisions that need escalation Twice a week — Project managers align on priorities and blockers Four days a week — Implementation and integration teams run hands-on working sessions There are no surprises at the executive level, because issues are surfaced and handled before they become big enough to need that conversation. Documentation & Handover Every CloudFronts D365 ERP implementation produces a complete documentation set, stored in SharePoint/Teams and Azure DevOps so both teams can access it at all times: Status Update Presentations Daily Checklists Configuration & Customisation Docs Integration Documents User Manuals Test Scenarios Issue-Solution Tracker Documentation is the work nobody enjoys doing. But it’s also what allows the Client’s internal team to support and maintain the system independently after go-live. A well-documented implementation is not just a delivered project, it’s a handover that actually works. Business Impact Before After Status updates delivered monthly, after the fact Live working sessions four days a week Ownership unclear across workstreams RACI matrix used daily to resolve decisions Environments used inconsistently across the project Full Dev-to-Production pipeline with a mock cutover Documentation created only at the end, if at all Complete documentation set maintained throughout Sign-offs based on completed sprints Sign-offs tied to outcomes confirmed in QA Frequently Asked Questions 1What does the CloudFronts PMO approach look like on a Microsoft Dynamics 365 ERP project? The CloudFronts PMO combines structured scope definition, daily working sessions, Azure DevOps-based tracking, a clear RACI framework, and a full environment pipeline from Dev through to Production. This ensures the Client has full visibility at every stage and that every milestone is signed off on outcomes, not just activity. 2Does CloudFronts implement both Dynamics 365 Finance & Operations and Business Central? … Continue reading A Successful Microsoft Dynamics 365 ERP Implementation Isn’t Just About the Software – It’s About How You Show Up →

Summary Designed and deployed a mobile-first Power Apps Canvas App for a Texas-based industrial cybersecurity firm specializing in operational technology (OT) security for oil and gas infrastructure. Unified time tracking, expense management, material consumption logging, and approvals into a single experience integrated with Dynamics 365 Project Operations. Eliminated fragmented desktop-based workflows that delayed project reporting, approvals, and billing. Automated expense receipt processing through Power Automate, improving compliance and reducing manual effort. Implemented project-scoped approval routing to ensure submissions were reviewed only by authorized stakeholders. Enabled real-time project visibility through structured Dataverse-driven workflows and lifecycle tracking. Provided mobile approvals and submission monitoring, dramatically reducing turnaround times. Improved data accuracy, audit readiness, and billing efficiency across field operations. Table of Contents Introduction Requirement & Business Scenario Solution Implementation Implementation Gallery Outcome FAQs Conclusion 1. Introduction Field-driven organizations live and die by the accuracy and speed of their project data. For a company securing critical infrastructure like oil rigs, every hour an engineer spends fighting with a clunky time-entry screen is an hour not spent on the job site — and every delayed expense submission is a delay in client billing and financial reporting. This is the story of how a Texas-based cybersecurity firm moved away from a fragmented, desktop-oriented workflow inside Dynamics 365 Project Operations and adopted a unified, mobile-first Canvas App that brought time tracking, expense submission, and material logging into one place, with built-in compliance controls and project-specific approval routing. The Goal: Build a unified mobile-first experience that allows field engineers to submit time, expenses, and materials from anywhere while ensuring compliance, controlled approvals, and real-time project visibility. 2. Requirement & Business Scenario The firm manages multiple concurrent field engagements using Dynamics 365 Project Operations as its system of record. Consultants and field engineers were expected to log three categories of activity against active projects: Time entries for hours worked Expense entries covering travel, accommodation, airfare, and related costs Material usage logs for equipment, parts, and consumables The core issue was that the underlying system was built for desktop use, not for engineers working on-site at remote rig locations. This created several compounding problems: Field staff had no efficient way to submit entries from a mobile device, so submissions piled up until they were back at a desk. Time, expense, and material tracking lived in separate workflows, forcing users to context-switch between screens for what should have been a single daily task. Expense compliance was inconsistent — receipts were sometimes attached, sometimes forgotten, and the process for linking a receipt to an expense record involved several manual, error-prone steps behind the scenes. Approvals had no project-level boundaries, making it hard to guarantee that only the right project stakeholders could review and approve specific submissions. Project managers lacked real-time visibility into resource usage, which meant billing and client reporting cycles were consistently delayed. Left unaddressed, these gaps were directly affecting data accuracy, audit readiness, and the speed at which the business could invoice clients. 3. Solution CloudFronts designed a unified mobile experience using Power Apps Canvas Apps layered on top of Dynamics 365 Project Operations and Dataverse, built around one guiding principle: One App. All Submissions. Controlled Approvals. Real-Time Visibility. For field users, the app became the single place to submit time entries on a daily or weekly basis, create expense entries with automatic receipt handling, log material consumption against the correct project, and track the live status of every submission. For project approvers, the same app surfaced only the entries tied to projects they were actually responsible for, let them approve or reject submissions directly from their phone, and preserved a clean, audit-ready trail for every decision. Day Mode and Week Mode Users could switch between a detailed single-day entry view, useful for precise logging and corrections, and a bulk weekly view that sped up repetitive data entry — letting each person work the way that suited their role. Calendar-Based Swipe Navigation A Dynamics-style calendar with swipe gestures let users move quickly across days and weeks, reviewing or correcting historical entries without friction. Stage-Aware Interface Every record followed the same lifecycle — Submitted, Pending, Approved, Rejected, Recall Requested, Recall Approved, Recall Rejected — and the UI adapted to whatever stage a record was in. Action buttons such as Submit, Approve, Reject, and Recall only appeared when they were actually valid, significantly reducing user confusion and accidental actions. Conditional Receipt Enforcement Rather than requiring a receipt for every expense category, the app applied compliance rules selectively. Receipts were mandatory for airfare and OT hardware purchases, while remaining optional for lower-risk categories such as meals and local transportation. 4. Implementation The technical implementation centered on a unified Dataverse data model and a set of automations that removed manual work from both the field user and the back office. Unified Data Model Time, expense, and material entries were all structured in Dataverse and linked back to the relevant project, resource, approval record, and — for expenses — supporting documentation. Every submission created a record with a clearly defined lifecycle stage, ensuring all three entry types behaved consistently even though their underlying business logic differed. Validation Before Submission The Canvas App enforced field-level validation before allowing a record to be saved, checking that essentials such as transaction date, project, category, quantity, and cost information were populated. If( Or( IsBlank(DatePicker.SelectedDate), IsBlank(ProjectCombobox.Selected), IsBlank(CategoryCombobox.Selected), IsBlank(QuantityInput.Value), IsBlank(PriceInput.Value) ), Notify(“Required fields are missing.”, NotificationType.Error) ) Patch-Based Record Creation Once validation passed, the application used Dataverse Patch operations to create records and calculate derived values such as expense subtotals dynamically based on quantity and unit price. Automated Receipt Handling For expense submissions, the previously manual chain of creating an Expense Receipt record, attaching a file as a Note, converting it to the correct document format, and updating the status to Submitted was fully automated. The Canvas App passed the expense ID, file name, and file content to a Power Automate flow, which created the Expense Receipt record, stored the file as a Note (Annotation) with the correct MIME type, … Continue reading How an Industrial Cybersecurity Company in Texas Improved Field Time and Expense Tracking with Microsoft Power Apps and Dynamics 365 Project Operations →

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 →

Summary Implemented Markdown-based formatting standards for Power Automate Approval Requests at a Texas-based Operational Security Provider. Transformed plain-text approval emails into structured, executive-friendly approval experiences. Improved readability through headers, sections, tables, lists, hyperlinks, and emphasis formatting. Reduced approver effort by presenting key business information in a consistent and easily consumable format. Leveraged native Power Automate Approval Markdown capabilities without requiring custom development. Improved approval turnaround times by making critical information easier to review and approve. Table of Contents Introduction The Business Problem The Solution Using Headers for Section Separation Using Line Breaks and Paragraphs Using Bullet Lists for Business Information Using Numbered Lists for Approval Steps Using Nested Lists for Additional Context Using Tables for Approval Summaries Using Hyperlinks for Record Navigation Using Emphasis for Important Information Escaping Special Characters Building a Structured Approval Request Limitations Business Impact FAQs Conclusion 1. Introduction In Microsoft Dynamics 365 Project Operations, quotes represent a critical milestone in the sales lifecycle. Before a quote can be activated and progress toward project execution, organizations often require review and approval controls to ensure pricing accuracy, contractual compliance, and business alignment. Since Quote Review & Approval is not a standard capability within Dynamics 365 Project Operations, this requirement typically requires customization. For a Texas-based Operational Security Provider, the requirement extended beyond a simple approval process. The organization needed a controlled workflow where only designated business leads associated with a specific Opportunity or Quote could generate, submit, and approve customer quotations, ensuring accountability and governance throughout the approval chain. A custom approval framework was developed using Microsoft Power Automate and Dynamics 365 Project Operations to automatically identify approvers and route quotes through the required approval process before activation. While the workflow successfully enforced the necessary business controls, the approval requests themselves were difficult to review. Critical information such as customer details, quote values, approval notes, and record links were presented as plain text, making approvals slower and less efficient. To improve the approver experience, Markdown formatting was introduced within Power Automate Approval Requests. Using structured headers, tables, hyperlinks, emphasis formatting, and organized sections, approval notifications became significantly more readable and actionable across Outlook, Outlook Web, and Power Automate approval channels. This article focuses on how Markdown was used to transform standard approval request bodies into professional, executive-friendly approval experiences that improved readability, reduced approval effort, and accelerated quote approval decisions. 2. The Business Problem The organization manages a high volume of customer opportunities and project-based engagements, where quotes serve as the commercial foundation for service delivery. Before a quote could be activated and converted into an operational project, it needed to undergo a formal review and approval process involving designated business stakeholders. To support this requirement, a custom quote approval workflow was implemented within Dynamics 365 Project Operations and Power Automate. The workflow successfully enforced business rules, ensured only authorized personnel could submit and approve quotes, and provided the necessary governance around pricing and customer commitments. However, a significant usability challenge emerged during adoption. The approval requests being sent to approvers contained all the required information, but the content was presented as large blocks of plain text. As quote complexity increased, approvers found it difficult to quickly identify key details such as: Customer Name Opportunity Information Quote Number Total Quote Value Requested Approval Type Business Justification Requestor Information Direct Links to Dynamics 365 Records This often forced approvers to spend additional time reviewing approval requests or navigating back into Dynamics 365 to locate information that should have been immediately visible within the approval notification itself. The lack of visual structure created several operational challenges: Slower approval turnaround times Increased requests for clarification Inconsistent user experience across approval requests Difficulty identifying critical information at a glance Reduced executive engagement with approval emails Higher likelihood of approval delays for time-sensitive opportunities The business needed a way to present approval information in a format that was clear, professional, and easy to consume without requiring additional custom applications or significant development effort. The Objective: Transform approval requests from plain-text notifications into structured, decision-ready approval experiences that allowed stakeholders to review and act on quote approvals quickly and confidently. 3. The Solution One important limitation of the Power Automate Approval action is that it does not support custom HTML rendering within approval request bodies. Unlike standard email notifications where HTML templates can be used extensively, Approval actions rely on a restricted rendering engine that supports a subset of Markdown syntax. As a result, many approval requests are delivered as large blocks of plain text, making them difficult to review, especially when multiple business details need to be presented to approvers. To improve readability without introducing custom applications or alternative notification mechanisms, the approval request body was redesigned using Power Automate’s native Markdown capabilities. This approach allowed approval requests to be structured into clearly defined sections, highlight important information, provide direct navigation links, and present approval summaries in a more professional format. 3.1 Using Headers for Section Separation Headers are one of the simplest ways to introduce structure into approval requests. Syntax # Main Heading ## Section Heading ### Subsection Heading Example # Quote Approval Request ## Opportunity Information ## Financial Summary ## Approval Notes Headers create visual separation between different parts of the approval request and help approvers quickly locate relevant information. 3.2 Using Line Breaks and Paragraphs Approval requests often contain multiple fields and explanatory comments. Proper spacing prevents information from appearing crowded. Syntax Line One Line Two Or force a new line using two trailing spaces: Line One Line Two Example Requested By: John Smith Department: Operations Approval Required Before Quote Activation Proper spacing significantly improves readability compared to continuous blocks of text. 3.3 Using Bullet Lists for Business Information Bullet lists are useful when presenting multiple approval considerations, requirements, assumptions, or supporting notes. Syntax – Item One – Item Two – Item Three Example ### Key Considerations – Executive review required – New customer engagement – Pricing exception applied – Legal review completed Bullet lists allow approvers to scan … Continue reading Enhancing Power Automate Approval Experiences with Markdown Formatting for a Texas-Based Security Operations Firm →