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 →

Summary A Houston-based cybersecurity firm eliminated report failures (~65%) by replacing SSRS with an Azure Function App pipeline. Dynamics 365 bound action ensured authentication stayed internal, bypassing Defender-related token failures. Integrated Power Pages, Power Automate, Dynamics 365, and Azure Functions for real-time PDF generation. Report generation time reduced from 3–8 minutes to under 15 seconds with zero infrastructure overhead. Table of Contents 1. About the Customer 2. The Challenge 3. The Solution 4. Technical Implementation 5. Business Impact 6. FAQs 7. Conclusion 1. About the Customer The client is a technology consulting and cybersecurity services firm based in Houston, Texas. They manage multiple concurrent client engagements using Dynamics 365 Project Operations as their core platform. Project managers and clients access live project data through a customer-facing portal built on Microsoft Power Pages. 2. The Challenge The organization needed one-click downloadable Project Status Reports from their Power Pages portal covering risks, issues, logs, and timelines. Their SSRS-based solution failed frequently due to authentication breakdowns caused by Microsoft Defender for Cloud Apps across multiple service boundaries. Key pain points: Silent authentication failures with no clear errors Retry delays of 60–90 seconds per attempt Separate SSRS infrastructure dependency Slow report customization cycle Project managers avoided generating reports during live meetings due to reliability concerns. 3. The Solution At Cloudfronts, while working on this project, I replaced the SSRS pipeline entirely with a synchronous, serverless architecture that keeps the authentication context inside the Dynamics 365 service layer. Technologies Used: Dynamics 365 Project Operations Power Pages Power Automate Plugins Azure Function Apps The solution generates fully formatted PDFs in real time using structured JSON payloads. This eliminated authentication failures while significantly improving speed and reliability. 4. Technical Implementation 1] Power Pages Button triggers Flow A “Download Report” button captures the project GUID and triggers a Power Automate flow with real-time progress feedback. 2] Dynamics 365 Plugin prepares JSON payload A bound action plugin retrieves all project data and converts it into a clean JSON payload for PDF generation. 3] Azure Function generates PDF The Azure Function processes the JSON and generates a formatted PDF, returning it as a Base64 string. 4] SharePoint Integration The generated PDF is automatically stored in the associated SharePoint document location linked to the project. This ensures centralized document management, version control, and easy access for stakeholders directly within the project workspace. 5] Portal PDF Preview The Base64 PDF is rendered directly in the portal using an iframe, allowing instant preview and download. Video: End-to-end implementation of real-time PDF report generation. 5. Business Impact 100% success rate — zero failures post deployment Under 15 seconds report generation time No infrastructure — fully serverless Zero authentication failures Faster iteration for report updates Project managers can now confidently generate reports during live client meetings. 6. FAQs Why not fix the SSRS authentication issue instead of replacing SSRS entirely? The authentication failures were a structural consequence of traversing multiple service boundaries in an environment with strict Defender for Cloud Apps session policies. Fixing them would have required either relaxing those policies — which the client’s security posture did not permit — or re-architecting the data retrieval to stay inside the platform, which is exactly what the bound action approach achieves. Replacing SSRS also removed a separate infrastructure dependency and gave the client full control over report formatting in code. Can this pattern be reused for other document types in Dynamics 365? Yes. The Azure Function App’s renderer is data-driven — it consumes a JSON payload and builds tables from whatever keys are present. The Dynamics 365 plugin can be adapted to query any entity and produce an equivalent payload. CloudFronts has applied the same pattern to inspection records, summary reports, and client-facing status documents across Professional Services and Manufacturing implementations. Does this work for environments without Microsoft Defender for Cloud Apps? Yes. The architectural benefits — synchronous generation, serverless PDF rendering, no SSRS infrastructure, and in-browser preview — apply regardless of the security layer on the environment. 7. Conclusion Replacing SSRS with an Azure Function App-based PDF renderer resolved both the reliability and authentication problems in a single architectural shift, delivering instant, professional-quality Project Status Reports from a Microsoft Power Pages portal with no legacy reporting infrastructure to maintain. The key lesson from this project is that keeping authentication within the Dynamics 365 service layer — rather than bridging to external systems — eliminates an entire category of environment-specific failures that are otherwise very difficult to diagnose and fix. By keeping authentication within Dynamics 365 and leveraging serverless architecture, the solution delivers instant, high-quality reports without infrastructure overhead. This approach demonstrates how modern cloud-native patterns can eliminate entire classes of system failures while improving user experience dramatically. Ready to modernise document generation in your Dynamics 365 environment?CloudFronts builds scalable Power Platform and Dynamics 365 solutions that replace legacy reporting infrastructure and automate document workflows. Reach out at transform@cloudfronts.com. Shashank Keny Associate Consultant · CloudFronts Shashank Keny is an Associate Consultant at CloudFronts with 1.5+ years of experience in cloud, data, and business applications. He specializes in building scalable, API-driven architectures and integrating enterprise systems across the Microsoft ecosystem. He is a Certified Databricks Data Engineer with hands-on experience in Dynamics 365 Project Operations and Dynamics 365 Sales, along with delivering business intelligence solutions using Power BI. His expertise also extends to modern AI solutions, including building custom copilots and implementing intelligent applications using Azure AI Foundry. Passionate about solving real-world business challenges through data and AI, he focuses on delivering efficient, scalable, and production-ready solutions. Experience: 1.5+ years Certification: Databricks Certified Data Engineer Specialization: Dynamics 365 Project Operations, Power BI, Azure Integrations, AI Solutions View LinkedIn Profile

Summary This blog highlights the integration of Microsoft Dynamics 365 Customer Service Hub with FedEx Shipping Manager to handle automated email return shipments for a consumer electronic appliances company based in Massachusetts, USA. In the original process, customer service representatives were required to manually register each return shipment through the FedEx Shipping Manager portal. This process involved copying customer details, creating shipments, generating labels, and capturing tracking numbers — a workflow that typically required 20–30 minutes per request. The integration project automated the entire return shipment process directly within the Dynamics 365 Customer Service Hub. With a single click, the system now registers the shipment using FedEx Shipment APIs, generates a return label, captures the tracking number, and updates the case record automatically. This innovation eliminated the need for agents to switch between systems and reduced shipment registration time from 20–30 minutes to just a few seconds, significantly improving operational efficiency and the overall customer service experience. This blog explains: 1] The operational challenges caused by manual shipment registration. 2] How Dynamics 365 Customer Service Hub was integrated with FedEx Shipping Manager. 3] The functional workflow used to automate shipment creation. 4] How customer service representatives trigger shipments directly from CRM. 5] The business impact achieved through automation and system integration. Table of Contents 1. Customer Scenario 2. Solution Overview 3. Functional Implementation Approach 4. Email Return Label Experience 5. Handling Complex Data Automatically 6. Business Impact 7. Preview Video 8. Final Thoughts Customer Scenario A Massachusetts-based consumer appliance manufacturer known for building innovative kitchen technology was experiencing a growing operational challenge in its customer service operations. As demand for its products increased across major retail channels, the number of customer support cases related to product returns and replacements also grew significantly. The company’s customer support team handled all service requests through Microsoft Dynamics 365 Customer Service. However, when a product needed to be returned for inspection, replacement, or warranty evaluation, agents were required to manually create a shipment in FedEx Ship Manager. This manual process involved several steps: 1] Opening the customer case in the CRM system 2] Copying customer information and shipping details 3] Logging into the FedEx portal 4] Registering the shipment manually 5] Generating a return label 6] Capturing the tracking number 7] Returning to CRM to update the case Each shipment registration typically took 20–30 minutes. When hundreds of return requests were processed weekly, this created several operational challenges: 1] Agents constantly switched between multiple systems 2] Manual data entry increased the risk of errors 3] Customer response times increased, leading to customer resentment 4] Tracking information was not always immediately available in the case record The organization needed a more efficient way to handle returns while keeping the entire process inside their CRM platform. Solution Overview To streamline the returns process, I implemented an integration between Microsoft Dynamics 365 Customer Service and FedEx shipping manager services. The goal was simple: Allow customer service representatives to generate a return shipment directly from the case record with a single click. Instead of navigating to the separate external shipping portal, agents can now initiate a return shipment directly from the CRM case page. Once triggered, the system automatically handles the entire shipment (Email/Return/Label) registration process. With this solution in place, the workflow now looks like this: A customer contacts support regarding a product return via their website, which registers an associated Case record in D365 Case Management (via existing case automation). The support agent opens the case in Dynamics 365. A “Create Return Shipment” button becomes available when the case meets the required conditions, e.g., Case Stage, RMA availability, Region of Customer, etc., thus validating and restricting shipment privileges. With one click, the system registers the shipment with FedEx (via appropriate FedEx Shipment APIs, as per customer requirements). The shipment tracking number is automatically captured and stored in the case record. This tracking number is useful for the customer support team as well as the customer to check the progress of the shipment on the FedEx Shipping Manager portal. The customer receives an email return label that they can print and attach to their package. FedEx Email Return Shipment Process Flow This transformation reduced a 20–30 minute process to just a few seconds. Functional Implementation Approach The implementation focused on simplifying the experience for customer service agents while maintaining strict control over when and how shipments could be created. Intelligent Shipment Trigger Visibility Within the CRM case interface, the return shipment button appears only when specific conditions are met. This ensures that shipments are created only for valid return scenarios. Examples of conditions include: The case must have an approved return authorization The case must be in an appropriate service stage The customer address must be eligible for shipment Required customer information must be available Example: Return Shipment Trigger inside Dynamics 365 Customer Service Hub By embedding these conditions into the CRM interface, agents are guided through the correct service workflow without needing to remember complex procedures. Automated Shipment Creation Once the button is clicked, the system automatically gathers key information from the case record, such as: Customer details Shipping address Product description Return authorization number Contact phone number This information is then used to register the shipment through the FedEx shipping system. The system generates: A unique shipment tracking number A return shipment registration A digital return label The warehouse where the shipment would reach based on the product and end consumer requirement – e.g., return, replacement, or repair of the product Example: A Successful Return Shipment to a specific warehouse. Example: Tracking a Return Shipment using the Tracking No. updated on D365 Customer Service Hub. Example: The FedEx Shipping Manager for Tracking the Integrated Shipments. The tracking number is immediately written back to the case record in Microsoft Dynamics 365 Customer Service, ensuring that support agents can track the return shipment without leaving the case. Email Return Label Experience After the shipment is registered, the customer automatically receives an email containing their return label. … Continue reading Transforming Return Logistics for a USA Manufacturer: Automating Shipment Processing with Dynamics 365 Customer Service →

Summary Many project-based organizations evaluating Microsoft solutions often ask the same question: If Microsoft Dynamics 365 Business Central already includes a project module, why do companies also use Microsoft Dynamics 365 Project Operations? This article explains the difference between the two systems, why both exist in the Microsoft ecosystem, and how integrating Project Operations with Business Central helps organizations manage project delivery and financial performance more effectively. Table of Contents 1. Why This Question Comes Up 2. Business Central: Built for Project Accounting 3. Project Operations: Built for Project Delivery 4. Why Companies Use Both 5. The Value of Integration The Outcome Why This Question Comes Up Many organizations assume Microsoft Dynamics 365 Business Central can manage all aspects of project operations because it includes the Jobs module. The Jobs module supports project budgeting, costing, and invoicing, which works well for organizations focused mainly on financial tracking. However, as projects grow more complex, involving multiple resources, time tracking, delivery planning, and client reporting, companies begin to experience limitations. This is when the difference between project accounting and project delivery becomes important. One system manages project finances. The other manages how projects are executed. Business Central: Built for Project Accounting Microsoft Dynamics 365 Business Central is an ERP system designed primarily for financial management. Its Jobs module helps finance teams track the financial performance of projects. Using Business Central, organizations can: Track project budgets and costs Manage purchase orders and project expenses Generate project invoices Monitor project profitability Handle revenue recognition and financial reporting For finance teams, this provides strong control over costs, billing, and compliance. However, financial visibility alone does not guarantee successful project delivery. Project Operations: Built for Project Delivery Microsoft Dynamics 365 Project Operations focuses on how projects are planned and executed. It provides tools specifically designed for project managers and delivery teams. Project Operations enables organizations to: Plan projects and manage tasks Schedule resources and manage capacity Track time and expenses Monitor project progress Collaborate across teams These capabilities help project managers manage people, timelines, and delivery commitments. However, Project Operations is not designed to replace an ERP system for financial management. Why Companies Use Both In most project-based organizations, different teams depend on different systems. Team Focus System Project Managers Planning and project delivery Project Operations Finance Teams Cost control, billing, accounting Business Central Trying to manage everything in a single system often creates operational friction. Project teams struggle with financial processes, while finance teams lack visibility into project execution. The Value of Integration When Microsoft Dynamics 365 Project Operations integrates with Microsoft Dynamics 365 Business Central, organizations gain the best of both systems. A typical workflow looks like this: Opportunities and project quotes are created Projects are planned and executed in Project Operations Time, expenses, and resource usage are captured Billing data flows to Business Central Finance manages invoicing and accounting This integration connects project execution with financial performance. Project managers gain operational visibility, while finance teams maintain control over billing and reporting. The Outcome Projects are delivered more efficiently Financial reporting remains accurate and compliant Manual work and duplicate data entry are reduced Project managers and finance teams work from connected data This creates a unified platform where project delivery and financial performance remain aligned. Final Thought The question is not whether Business Central can manage projects — it can. The real question is whether one system should manage both delivery and financial operations. For many organizations, combining Microsoft Dynamics 365 Project Operations with Microsoft Dynamics 365 Business Central provides the ideal balance between operational execution and financial governance. At CloudFronts Technologies, we help organizations connect Project Operations with Business Central through our PO-BC integration solution. For more information: PO-BC Integration Solution on Microsoft AppSource If you would like to discuss how this integration can support your organization, feel free to reach out to us at transform@cloudfronts.com.