Light Sepia Dark 01Summary Part 1 covered the data model behind a certification Agreement Manager in Microsoft Dataverse: eleven tables, a strict ownership boundary that leaves signing to Adobe Acrobat Sign and document storage to Azure Blob, and a coverage model whose whole purpose is to let certification logic answer a question with a query instead of a judgement call. This part covers the automation built on top of it, and it is written against the environment rather than the specification. I went back into the development org and checked, because a build note written at two in the morning is not evidence. What is there: six cloud flows, all activated, a validation action with a plugin step behind it, Adobe configured with real workflow identifiers, and eight agreement requests that have genuinely run through the process, four of them to Fully Executed. What is not there: the custom API that creates coverage, which was never built. Nothing else is permitted to write coverage, so the coverage table is empty. The interesting part is that the system already says this about itself. 02In This Blog What is actually deployed, verified against the environment, and what the gap between the specification and the org tells you about handing work over. The Scenario: A finished data model that still needed to send agreements, track them, store evidence, and produce coverage. The Approach: A decision table fixing flow against plugin against custom API for every operation, written before any automation existed. The Action: Six solution aware flows, a validation action with a plugin behind it, and Adobe wired to real template workflow identifiers. The Outcome: A process that runs end to end up to signature, and one clearly identified missing component that the validation data names out loud. A half finished system is safe to inherit when it tells you what is missing. It is dangerous when you have to find out. Table of Contents 01Summary→ 02In This Blog→ 03Where Part 1 Left Off→ 04Flow, Plugin, or Custom API→ 05What Is Built, and What Comes Next→ 06The Coverage Gate→ 07Impact→ 08Conclusion→ 09FAQ→ 10Get in Touch→ 03Where Part 1 Left Off The foundation was eleven Dataverse tables in three layers. A configuration layer holding Agreement Type, Agreement Template Version, Agreement Role Definition and Agreement Requirement Policy. A process layer centred on Agreement Request with four parental children: Agreement Party, Agreement Recipient, Agreement Document and Agreement Validation Issue. An evidence layer of Agreement Coverage and Agreement Coverage Scope. Adobe Acrobat Sign for Microsoft Dynamics 365 owns signature execution. Azure Blob Storage owns the binaries. Dataverse owns the business decision. Eight alternate keys hold the integrity guarantees, the strongest being the one that makes a second active coverage for the same scope impossible. Everything below assumes that foundation, because the specification forbade starting automation until the tables, keys, forms and views were finished and validated. That sequencing held, and it is the reason the automation layer is as small as it is. 04Flow, Plugin, or Custom API Most Power Platform builds decide implementation style per developer preference, which produces a system where nobody can predict where a given behaviour lives. This build used one canonical decision table, written before any automation existed. Operation Preferred implementation Escalate to code when Validate Agreement Request Solution aware flow or command action that clears unresolved issues, writes new ones, and updates the validation summary The gate needs synchronous reuse, in which case it is promoted to a custom API Send for Signature Power Automate using the Adobe connector, only after validation leaves no blocker Multiple callers need one stable callable action Adobe status sync Adobe managed app plus a lightweight sync flow where needed Concurrency or idempotency require server side code Retrieve and store documents Power Automate for small files, Azure Function for large ones Blob SDK, managed identity, hashing or retry handling are awkward in a flow Create Coverage Custom API, mandatory. A pure flow is explicitly not acceptable Always, because supersession must be transaction safe Open final document Flow or Azure Function generating a short lived link Managed identity and key vault access are easier in a function Coverage gate Synchronous plugin or custom API Certificate issuance must be blocked immediately rather than eventually The canonical matrix. Deviating from it required a written justification, not a preference. Why coverage creation cannot be a flow Creating active coverage means superseding the previous active row, clearing its key, linking the supersession, and inserting the replacement. A flow performs those as separate operations, so a failure between them leaves the legal entity with either no coverage or two. A custom API performs them in one transaction, which is why the specification made it mandatory rather than preferred. The three custom APIs Validate Agreement RequestRe runs validation, populates the policy reference date if blank, enforces legal review approval where the agreement type demands it, upserts validation issues by alternate key, and returns a summary with blocker and warning counts. Create Agreement CoverageResolves policy and scope, builds the coverage match key, supersedes the prior active row and inserts the new one in a single transaction, creates the scope rows, and moves the request to Coverage Created. Evaluate Coverage GateGiven an account, legal entity, agreement type code, scope context and reference date, returns pass, block or exception with the reason and the coverage identifier that satisfied it. 05What Is Built, and What Comes Next It is worth being precise here, because a diagram of the full design would overstate what runs. The following is what the environment reports, not what the specification asked for. Figure 1: What is running today, and what is designed and waiting The automation, as deployed Component What it does State in the environment Validate Agreement Request Writes a structured issue row for every problem found on a request Custom action and plugin step, both activated FLW-01 Send for Signature Hands the prepared agreement to Adobe Activated FLW-02 Adobe Status Sync Brings signing progress back onto the request and … Continue reading How a Sustainability Certification Nonprofit Automated Agreement Management with Adobe Acrobat Sign and Power Automate →

Summary A consumer appliance manufacturer was receiving warranty claims through its customer mobile app, but the replacement process still required several manual checks and handoffs. We connected the mobile warranty claim process, Dynamics 365 Customer Service, and Business Central so the claim, RMA decision, replacement order, and case history remain linked throughout the process. Table of Contents 01 Summary 02 About the Customer 03 Business Challenge 04 Solution 05 How the RMA Process Works 06 Business Impact 07 Conclusion 08 FAQs About the Customer Our customer is a consumer appliance manufacturer that sells cooking products and supports customers after purchase. When a customer faces a product issue, the service team reviews the warranty claim and decides whether a replacement or exchange is required. The company already had customer, product, and warranty information in its systems. The main challenge was moving that information from the initial claim to the replacement order without relying on repeated emails or manual data entry. Business Challenge Customers submit warranty claims through a mobile app. These claims contain important details about the customer, registered product, and reported issue. Earlier, the service team still had to review information across different records and coordinate the replacement order separately. This created a few common problems: Agents had to check customer, product registration, warranty, duplicate claim, and fraud information manually. Replacement details could be shared through emails before the order was created. The same product and shipping information could be entered more than once. The Business Central Sales Order number was not always easy to trace from the original Case. Customer Service had to spend extra time checking whether the replacement order had been created. The goal was simple: keep the warranty claim, service review, RMA details, and replacement order connected from beginning to end. Solution We connected the customer warranty journey across the mobile app, Dynamics 365 Customer Service, and Microsoft Dynamics 365 Business Central. When a customer submits a web warranty claim through the mobile app, the integration sends the claim and product details to Dynamics 365. A Case is created for the Customer Service team, giving the agent one place to review the request. During the Identification and Research stage, the agent checks the customer, product registration, warranty, duplicate claim, and potential fraud information. If a replacement or exchange is required, the agent sets RMA to Yes and records the warehouse, warranty type, shipment method, location, and products to be exchanged or added. Sample Dynamics 365 Case used to review the warranty claim and capture the RMA details. Once the required information is available, the related Sales Order is created in Business Central. The Business Central Sales Order ID is then stored back on the Dynamics 365 Case. This keeps the service request and replacement order connected, so the agent can trace the order without searching through email threads. How the RMA Process Works The connected warranty claim and RMA process from mobile submission to case closure. Step Stage What Happens 1 Warranty Claim The customer submits a web warranty claim through the mobile app. 2 Warranty Claim Integration The integration sends the customer, claim, and product information to Dynamics 365. 3 Case Creation A Dynamics 365 Case is created for the Customer Service team. 4 Identification and Research The agent checks the product registration, warranty, duplicate claim, and potential fraud information. 5 RMA Details The agent sets RMA to Yes and records the warehouse, warranty type, shipment method, location, and replacement products. 6 Business Central Order The related Sales Order is created in Business Central for replacement processing. 7 Update and Resolve The Sales Order ID is saved on the Case, and the agent resolves the Case after the required work is completed. Business Impact The connected process gives Customer Service a clearer and more consistent way to manage replacement requests. The main improvements include: Less repeated data entry: Claim and product information received through the mobile app integration is available in Dynamics 365 for the service review. Better traceability: The Business Central Sales Order ID remains linked to the original Case. Clearer agent process: Important RMA information is captured in defined fields instead of being kept only in emails. Fewer follow-ups: Agents can check the Case for the RMA and order details instead of asking another team for the order number. More consistent replacements: Warehouse, shipment, warranty, location, and product details are recorded before the Sales Order is created. Complete case history: The claim review and replacement information stay connected for future reference. Conclusion RMA automation does not need to replace the service agent’s decision. It should remove repeated entry and make the next step clear. By connecting the mobile warranty claim process, Dynamics 365 Customer Service, and Business Central, this consumer appliance manufacturer created one traceable path from a customer’s warranty claim to the related replacement order. Customer Service can work from the Case, the order can be traced through its Business Central Sales Order ID, and the complete history remains available when the Case is resolved. Frequently Asked Questions 1. What is an RMA? RMA stands for Return Merchandise Authorization. It records that a product return, replacement, or exchange has been reviewed and approved for processing. 2. How does the warranty claim enter Dynamics 365? The customer submits a web warranty claim through the mobile app. The integration sends the claim and product information to Dynamics 365, where a Case is created for Customer Service. 3. Does the automation approve every replacement automatically? No. The Customer Service agent still reviews the product registration, warranty, duplicate claim, and potential fraud information before confirming the RMA. 4. What information is captured for an approved RMA? The Case can include the warehouse, warranty type, shipment method, location, replacement products, and the related Business Central Sales Order ID. 5. Why is the Business Central Sales Order ID stored in Dynamics 365? It gives Customer Service a direct reference to the replacement order. This makes the order easier to trace from the original customer Case. Looking to … Continue reading How a U.S.-Based Consumer Appliance Manufacturer Stopped Chasing RMA (Return Merchandise Authorization) Emails with a Single Automated Workflow →

Are You Struggling to Understand Where Your Customer Cases Stand? As appliance brands grow, managing customer service requests becomes increasingly complex. Warranty claims, replacement requests, product issues, and customer inquiries can quickly overwhelm teams if there isn’t a structured process in place. Have you ever found yourself asking: “Where is this case right now?“ It sounds like a simple question, yet in many organizations, finding the answer requires checking multiple systems, following up with different teams, or waiting for updates from customer service representatives. The issue isn’t a lack of effort; it’s a lack of visibility. Most customer service systems rely on a handful of generic case statuses such as Open, In Progress, or Closed. While these statuses indicate whether a case is active, they reveal very little about what is actually happening behind the scenes. For appliance manufacturers, a customer service case often involves much more than a support ticket. Warranty validation, product registration checks, troubleshooting, replacement approvals, shipping coordination, and customer follow-ups all form part of the resolution journey. This is where Multi-Stage Business Process Flows (BPFs) in Microsoft Dynamics 365 can make a significant difference. Why Traditional Case Management Falls Short Imagine a customer contacts support because their toaster is no longer heating properly. A standard ticketing process may record the issue and mark the case as “In Progress.” A single status value cannot answer these questions. As a result, service teams spend time chasing updates, managers struggle to identify bottlenecks, and leadership lacks visibility into where cases are getting delayed. Example: Imagine two cases both marked as “In Progress.” From a traditional status perspective, both cases appear identical. With a Multi-Stage BPF, the difference becomes immediately visible, enabling managers to prioritize actions and allocate resources more effectively. A Better Approach: Multi-Stage Business Process Flows A Business Process Flow (BPF) in Dynamics 365 provides a guided framework that moves a case through predefined stages. Each stage can contain mandatory fields, validations, and business rules, ensuring that critical information is captured before the case progresses further. Rather than relying on a single status value, organizations gain visibility into exactly where a case sits within the overall service journey. For a premium appliance manufacturer, a typical service case might progress through the following stages: Bringing Structure to the Appliance Service Journey A Multi-Stage Business Process Flow transforms a case from a simple ticket into a clearly defined process. Instead of tracking a case using one status field, the case progresses through a series of business stages that mirror the real-world workflow. For example, a warranty replacement case for a defective toaster may move through stages such as: 1. ID & Research – Customer Information The service team captures and validates customer information, product registration details, serial number, purchase source, warranty eligibility At this stage, the goal is to verify that the claim is legitimate and gather all required information. 2. Receiving The returned product is reviewed and inspected. Teams can confirm receipt of the item, validate the reported issue, document inspection findings This ensures that decisions are based on actual product conditions rather than assumptions. 3. Accounting Before a replacement is issued, financial and operational reviews may be required. Activities can include warranty claim validation, credit approvals, replacement authorization, internal accounting reviews This creates accountability while maintaining process consistency. 4. Shipping Once approved, the replacement process moves into fulfillment. Required information may include tracking number, shipping date, return label status, logistics confirmation At this stage, the customer is actively waiting for their replacement product. 5. Resolve Case Once delivery is confirmed and the customer is satisfied, the case can be formally closed. The entire service journey is documented from start to finish. A Real-World Customer Story Imagine Sarah purchased a toaster a few months ago and suddenly found that it stopped heating. She contacts customer support expecting a quick resolution. Behind the scenes, her request needs to pass through product verification, warranty validation, inspections, approvals, and shipping before a replacement reaches her doorstep. Without a structured process, delays can occur at any stage, leaving both the customer and support teams frustrated. With a Multi-Stage BPF, every step is visible, tracked, and managed, ensuring the case continues moving forward while providing clarity to both employees and customers. Why This Matters for Leadership The biggest benefit of Multi-Stage BPFs is not just process control—it’s visibility. When cases are tracked by stage, leaders can quickly identify where delays are occurring. For example: Instead of simply knowing that cases are open, leaders gain insight into why they are still open. This makes it easier to make informed decisions and address bottlenecks before they impact customer satisfaction. Why We Believe in Structured Service Management At CloudFronts, we’ve worked with organizations looking to streamline customer service operations using Dynamics 365. One common challenge we consistently encounter is the lack of visibility into the lifecycle of customer requests. Through our implementations and observations, we’ve found that Multi-Stage Business Process Flows help organizations bring structure, accountability, and transparency to service operations while improving the overall customer experience. More importantly, they help leadership teams move from reactive case management to proactive service management. Better Accountability Across Teams Customer service cases often involve multiple departments. Without a structured process, it’s easy for tasks to fall through the cracks during handoffs. A Multi-Stage BPF helps ensure that each team completes its responsibilities before the case moves forward. Required information can be captured at each stage, creating consistency across the organization while also improving data quality. Most importantly, everyone involved knows exactly what needs to happen next. Improving the Customer Experience Customers don’t care which internal department owns the next step. They simply want their issue resolved quickly and efficiently. By providing a clear, structured process, organizations can reduce delays, improve communication, and deliver a more consistent customer experience. For appliance brands, where warranty claims and replacement requests can directly influence customer loyalty, these improvements can have a significant impact. Final Thoughts A customer service case is rarely just a ticket. Behind every … Continue reading Managing Complex Warranty and Replacement Requests with Dynamics 365 Multi-Stage Business Process Flows for a North American Appliance Brand →

These days there are so many companies that are developing software applications to help businesses manage the projects. But, nothing comes close to dynamics 365 project service automation. It is unique and is one software that every business should have if they want to manage projects and help them to become successful. Companies can track as well as manage projects well when they use this particular software.astering this software is essential if you want to use this application efficiently. PowerApps is one service that Microsoft offers, and developers can use it to build apps as per the requirement of the client. As my thoughts build to initiate writing this blog, similar was the feeling when I first thought about exploring Power Apps. The expression was, “What exactly is Power Apps?”. When the world is talking about it, it brings me more curiosity to understand what is so powerful about it. Let’s first commence with understanding what exactly is Power Apps: PowerApps is an initiative by Microsoft that allows developers and nontechnical users to build mobile applications from selectable templates. The objective of PowerApps is to enable business users to build new capabilities via apps, without requiring that they have code expertise. Types of Power Apps: Model driven apps: These types of apps directly publish the entity on the mobile/ tablet. These apps can be used from Microsoft Dynamics 365 App from mobile. They are very easy to make and can be ready within 15mins of time. Canvas apps: These apps are blank canvas given to the developers with a free hand to design the app in the way they want. In this blog we shall focus more on how to make a Canvas app. Follow the steps below to make a PowerApps. Step 1: Login to www.portal.office.com Step 2: Click on PowerApps icon as shown in the image below: This will open a new browser tab where we need to select what kind of app do we need to make. Step 3: Click on Canvas app from blank, which opens a pop up. Please name your app and select whether the app is for Phone or for Tablet as shown below and click on Create button. This opens the Canvas app editor as shown below: To take this blog forward, I will use an app that is created by me and explain a few commands used by me and how was the design done in that app. The app captures the Grievances of people in office. There are 5 screens created by me and they are: list_Grievances Screen: This list all the grievances in the system. 2. frm_GrievanceRecord Screen: This opens a grievance record. 3. Frm_NewGrievance Screen: This screen is used to capture a new grievance. 4. Frm_CameraScreen : This is used to capture the image of the grievance using camera control. 5. SuccessScrn: This is used to display the success on the screen. Technical dive Let’s take a dive in each screen and get into understanding of functionalities developed on each screen: List_grievances: a. New Grievance button: This button will navigate to a frm_NewGrievance Record to capture new grievance from the employee. The code written behind that is:………………………………………………………………………………………………………………Navigate(frm_NewGrievance,ScreenTransition.Fade );   …………………………………………………………………………………………………………………….b. To display the list of Grievance I have inserted a List Screen as shown in the image below: c. To display the list of Grievance, we need to add a Data Source. How to add a data source is shown below: There are approximately more than 250 Data sources to which Power apps can connect. Select the data source you wish to connect. In my case, I will connect to Dynamics 365 Data Source. It will ask you to choose your entity and then you can click on connect. Your Data Source “Grievances” will start appearing in Items drop down of Property Window. Post that we can align the attributes that we need to see on the list view: To Display Employee Full Name, below is the code that I wrote: ………………………………………………………………….. ThisItem.’Employee Full Name’ ………………………………………………………………… To get the department value, which is a lookup to another entity below is the code that was written: …………………………………………………………………. LookUp(Departments,new_departmentid=ThisItem.Department, new_name) …………………………………………………………………. To display the image from the SharePoint Library, below is the code: LookUp(GrievanceLibrary, Title = TitleGrievance.Text, Image)   Where GrievanceLibrary is the Sharepoint Datasource added in Powerapp and Title and image are the fields created in SharePoint.   To open the Grievance record on frm_Grievance Record, write the below code: Navigate(frm_GrievanceRecord,ScreenTransition.Fade,glryGrievances.Selected)   frm_NewGrievanceRecord: To store the new grievance record, we used the Form Screen. On the update button, write the below code: Patch(     Grievances,     Defaults(Grievances),     {         new_employeefullname: DataCardValue3.Text,         new_description: DataCardValue15.Text,         _new_departmentl_value: DataCardValue10.Selected.new_departmentid,         _new_grievancetypel_value: DataCardValue6.Selected.new_grievancetypeid,         new_signature: PenInput4.Image     } ); Patch(     GrievanceLibrary,     Defaults(GrievanceLibrary),     {         Title: DataCardValue3.Text,         Image: First(Collection1).Url     } ); UpdateContext({resettext: !resettext}); UpdateContext({resetcombobox: !resetcombobox}); Navigate(SuccessScrn,ScreenTransition.Fade); frm_CameraScreen Insert a Camera Media Control on the form as shown in the below screen shot. Insert an image control on the form below the Camera Media control. Capture button code: ClearCollect(Collection1, Camera1.Photo) Collection 1 s described above is the SharePoint collection object which needs to be cleared and then referred with the new Photo from the Camera Control, which in our case is Camera1. Confirm button code: Confirm Button will only Navigate it to New Grievance form and the code is ass per below: Navigate(frm_NewGrievance)  To summarise: We learned how to create a Canvas Power app. Different controls that can be used. How to store image on Sharepoint in a Power app. Again I am sharing the code for storing the image on Sharepoint herewith: Patch(     GrievanceLibrary,     Defaults(GrievanceLibrary),     {         Title: DataCardValue3.Text,         Image: First(Collection1).Url     } ); To explain the above code, GrievanceLibrary is the SharePoint site of which Data Source is added. Title: This is a field in the Sharepoint library that will store the name of the Grievance. The data type in Sharepoint for Title is Single line Text Image: This will store … Continue reading First Canvas Power App: Learn Few Easy and Important Commands →

Customer Service is one of the essential segments of any business if they want to become successful. Every single thing about it does matter. Dynamics 365 for customer service is one of the tools that a business can use to improve brand loyalty and also to improvise the value that the companies offer to their clients. Any company that wants to improve in this segment needs to work on this thing. D365 Customer Service will set your company apart from the rest of the firms out there. This software will help you stay ahead of the customer’s expectations and to resolve their concerns a lot faster. Customers can reach out to the company a lot quicker and get resolutions for the problems they are facing at a much faster pace. Microsoft Dynamics 365 CE streamlines the way your employees communicate with customers and enhances their ability to collaborate. Problem Statement Clients implement D365 CE for all departments also need home/landing/default page for each department. This blog will help you to configure default URI for each department in D365 CE implementation for Company. Configuration Steps 1.       Open Dynamics 365 Sales app 2.       Navigate to “My Apps” in Settings group 3.       Open Manage Roles Click on ellipses(…) and pop-up open, click on Manager Role 4.       Setup App URL Enter URL Suffix e.g. SL and automatically URL is generated. 5.       Setup Roles Roles are assigned to URL, Users with specific roles can only access App. 6.       Copy URL and click Save button also share with Users for opening. Conclusion After following above configuration steps, we can share App URL with Sales Department similarly we can configure for Customer Service, Project Service, Field Service or any custom App share with the respective department. Hope this blog helps you to configure Department-wise or based on App for a group of people.