Sustainability certification is one of the most operationally demanding programs a nonprofit can run. It is not just a badge on a product, it is a multi-year, multi-stakeholder process involving manufacturers, independent assessment bodies, scoring frameworks, document issuance, and public transparency requirements. When you are managing thousands of products across global industries, the cracks in a manual, spreadsheet-driven operation show up fast. This is exactly the situation a Netherlands-based nonprofit found itself in. The organization administers a globally recognized product sustainability certification program, assessing products across five dimensions: material health, product circularity, clean air and climate protection, water and soil stewardship, and social fairness. Products move through certification levels Bronze, Silver, Gold, and Platinum across a lifecycle that spans application, third-party assessment, issuance, and periodic recertification every three years. As certification volumes grew, so did the operational complexity. Disconnected tools, manual document preparation, and no single place to track everything meant the team was spending more time managing the process than running it. Rather than bolt on yet another external tool, the organization made a deliberate architectural choice: build the entire certification management platform inside Microsoft Dynamics 365, extend it with Azure Function Apps for automation, and expose public APIs for ecosystem transparency. The Goal Build a unified, scalable certification lifecycle management system inside Dynamics 365 that automates document generation, manages logo assets, and exposes public APIs for published certification data — all without introducing new platform dependencies. The Business Problem To understand what was built, you first need to understand what was broken. The organization’s operational teams were trying to answer some fairly fundamental questions every single day — What is the current certification status of a given product? Which products are approaching their recertification deadline? Which assessment body certified a product and when? Is the certificate document ready for issuance? None of these questions had a reliable, centralized answer. Certification records lived across disconnected spreadsheets and email threads, which meant any “current” view of a product’s status was only as accurate as the last person who updated a row. Certificate documents were manually composed for every issuance a slow, error-prone process that created formatting inconsistencies and delayed the experience for certified manufacturers. Logo assets were managed informally, with no version control or consistent delivery process. No Single Source of Truth Certification records scattered across spreadsheets and email threads with no reliable current view. Manual Document Creation Every certificate composed by hand slow, inconsistent, and a bottleneck manufacturers felt directly. Zero Public Transparency External stakeholders relied on manually updated static pages with no programmatic access to live data. Unscalable Operations Growing program volumes with no automation meant every new product added to the manual workload. The Solution Architecture The platform was designed around one principle: build close to where the operational data already lives, and automate at the right trigger points rather than everywhere at once. The solution runs on three deliberate layers. Critically, this architecture avoided over-engineering entirely — no separate data warehouse, no heavy ETL pipeline, no dedicated certification SaaS platform requiring its own licensing and maintenance. Everything runs inside the Microsoft ecosystem. 1 Data Layer — Custom Dynamics 365 Tables Purpose-built Dataverse tables that mirror the certification domain exactly, products, certification events, assessment bodies, category scores, and logo assets all in a single relational, auditable structure. 2 Automation Layer — Azure Function Apps, Dynamics Plugins Two event-driven Function Apps sit alongside the CRM one for certificate document generation, one for logo package delivery, both triggered by real state changes in the certification lifecycle, not a schedule. 3 Transparency Layer — Public REST APIs Public-facing APIs expose published certification data to external stakeholders, brands, retailers, regulators, and third-party platforms without any manual data exchange with the organization. Custom Dynamics 365 Data Model The data model is the foundation everything else rests on. Rather than forcing certification concepts into standard CRM entities that were never designed for this domain, the team built purpose-specific custom tables inside Dataverse that mirror how the certification program actually works. Product data Core product records, variants, and identifiers — the foundational layer that everything else references. Application handling Applications, assessments, category and requirements assessments — all managed within accounts. Assessment bodies and related workflows live here too. Public-facing entities Public tables for products, certifications, certificates, and product variants — the data layer that powers external visibility and API exposure. Together, these layers gave the organisation a complete, relational view of every certified product across its full lifecycle — all within a single operational platform. Certificate Document Generation via Azure Function App Before this system existed, every certificate document was created by hand. Someone would take a template, fill in the product details, format it, check it, and send it. For an organization issuing certificates across thousands of products, this was not just slow — it was a source of constant inconsistency and a bottleneck that manufacturers felt directly. The Azure Function App for certificate generation eliminated this entirely. Here is how it works end to end: How It Works ⚡ Trigger Certification record reaches the correct status in Dynamics 365 → 🔍 Fetch Pulls record + product data via Dynamics 365 Web API → 📄 Generate Selects correct template, populates all fields, generates document → 🔗 Store & Link Saves document and links it back to the certification record What this means in practice is that certificate issuance is now consistent, fast, and entirely hands-off for the operational team. Formatting is guaranteed every time because the template logic is defined once and applied uniformly. The function also runs independently of the CRM interface — making it resilient and reusable across multiple trigger scenarios, including bulk recertification processing. The impact: A task that previously required manual effort for every single issuance now requires none. Eliminated entirely. Logo Image Generation via Azure Function App A certified product comes with more than a document — it comes with the right to use the certification mark. For manufacturers, that logo is a commercial asset. It goes … Continue reading How a Netherlands-Based Non-Profit Transformed Certification Management with Dynamics 365 and Azure Functions →

Why Incremental Loads Matter When integrating data from external systems, whether it’s a CRM, an ERP like Business Central, or an HR platform like Zoho People, pulling all data every time is expensive, slow, and unnecessary. The smarter approach is to track what has changed since the last successful run and fetch only that delta. This is the core idea behind an incremental data pipeline: identify a timestamp or sequence field in your source system, persist the last-known watermark, and use it as a filter on your next API call. Azure Logic Apps, paired with Azure Table Storage as a lightweight checkpoint store, gives you everything you need to implement this pattern without managing any infrastructure. Architecture Overview Instead of one large workflow doing everything, we separate responsibilities. One Logic App handles scheduling and orchestration. Another handles actual data extraction. Core components: 3. Metadata Design (Azure Table) Instead of hardcoding entity names and fields inside Logic Apps, we define them in Azure Table Storage. Example structure: PartitionKey RowKey IncrementalField displayName entity businesscentral 1 systemCreatedAt Vendor Ledger Entry vendorLedgerEntries zohopeople 1 modifiedtime Leave leave Briefly, this table answers three questions: – What entity should be extracted?– Which column defines incremental logic?– What was the last successful checkpoint? When you want to onboard a new entity, you add a row. No redesign needed. 4. Logic App 1 – Scheduler Trigger: Recurrence (for example, every 15 minutes) Steps: This Logic App should not call APIs directly. Its only job is orchestration. Keep it light. 5. Logic App 2 – Incremental Processor Trigger: HTTP (called from Logic App 1) Functional steps: Example: This is where the real work happens. 6. Checkpoint Strategy Each entity must maintain: – LastSuccessfulRunTime– Status– LastRecordTimestamp After successful extraction: Checkpoint = max(modifiedOn) from extracted data. This ensures: Checkpoint management is the backbone of incremental loading. If this fails, everything fails. This pattern gives you a production-grade incremental data pipeline entirely within Azure’s managed services. By centralizing entity configuration and watermarks in Azure Table Storage, you create a data-driven pipeline where adding a new integration is as simple as inserting a row — no code deployment required. The two-Logic-App architecture cleanly separates orchestration from execution, enables parallel processing, and ensures your pipeline is resilient to failures through checkpoint-based watermark management. Whether you’re pulling from Business Central, Zoho People, or any REST API that exposes a timestamp field, this architecture scales gracefully with your data needs. Explore the case study below to learn how Logic Apps were implemented to solve key business challenges: Ready to deploy AIS to seamlessly connect systems and improve operational cost and efficiency? Get in touch with CloudFronts at transform@cloudfronts.com.

Managing and processing large datasets efficiently is a key requirement in modern data engineering. Azure Databricks, an optimized Apache Spark-based analytics platform, provides a seamless way to handle such workflows. This blog will explore how PySpark and SQL can be combined to dynamically process, and clean data using the medallion architecture (Only Raw → Silver) and store the results in Azure Blob Storage as PDFs. Understanding the Medallion Architecture: – The medallion architecture follows a structured approach to data transformation: Aggregated Layer (Gold): Optimized for analytics, reports, and machine learning. In our use case, we extract raw tables from Databricks, clean them dynamically, and store the refined data into the silver schema. Key technologies / dependencies used: – Step-by-Step Code Breakdown 1. Setting Up the Environment Install & import necessary libraries The above command installs reportlab, which is used to generate PDFs. This imports essential libraries for data handling, visualization, and storage. 2. Connecting to Azure Blob Storage This snippet authenticates the Databricks notebook with Azure Blob Storage and prepares a connection to upload the final PDFs; Initiates the Spark Session as well. 3. Cleaning Data: Raw to Silver Layer Fetch all raw tables This dynamically removes NULL values from raw data and creates a cleaned table in the silver layer. 4. Verifying and comparing the Raw and the Cleaned (Silver) 4. Converting Cleaned Data to PDFs 5. Converting Cleaned Data to PDFs Output at the Azure Storage Container This process reads cleaned tables, converts them into PDFs with structured formatting, and uploads them to Azure Blob Storage. 6. Automating cleaning at Databricks at fixed scheduleThis is automated by scheduling the notebook & it’s associated compute instance to run at fixed intervals and timestamps. Further actions: – Why Store Data in Azure Blob Storage? To conclude, by leveraging Databricks, PySpark, SQL, ReportLab, and Azure Blob Storage, we have automated the pipeline from raw data ingestion to cleaned and formatted PDF reports. This approach ensures: a. Efficient data cleansing using SQL queries dynamically. b. Structured data transformation within the medallion architecture. c. Seamless storage and accessibility through Azure Blob Storage. This methodology can be extended to include Gold Layer processing for advanced analytics and reporting. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudFronts.com

In modern enterprises, documents stored across platforms like SharePoint often remain underutilized due to the lack of intelligent search capabilities. What if your organization could automatically extract meaning from those documents—turning them into searchable vectors for advanced retrieval systems? That’s exactly what we’ve achieved by integrating Azure Logic Apps with Azure AI Search. Workflow Overview Whenever a user uploads a file to a designated SharePoint folder, a scheduled Azure Logic App is triggered to: Once stored, a scheduled Azure Cognitive Search Indexer kicks in. This indexer: Technologies / resources used: –-> SharePoint: A common document repository for enterprise users, ideal for collaborative uploads. -> Azure Logic Apps: Provides low-code automation to monitor SharePoint for changes and sync files to Blob Storage. It ensures a reliable, scheduled trigger mechanism with minimal overhead. -> Blob Storage: Serves as the staging ground where documents are centrally stored for indexing—cheaper and more scalable than relying solely on SharePoint connectors. -> Azure AI Search (Cognitive Search): The intelligence layer that runs a skillset pipeline to extract, transform, and vectorize the content, enabling semantic search, multimodal RAG (Retrieval Augmented Generation), and other AI-enhanced scenarios. Why Not Vectorize Directly from SharePoint? Reference:-1. https://learn.microsoft.com/en-us/azure/search/search-howto-index-sharepoint-online2. https://learn.microsoft.com/en-us/azure/search/search-howto-indexing-azure-blob-storage How to achieve this? Stage 1: – Logic App to sync Sharepoint files to blob Firstly, create a designated Sharepoint directory to upload the required documents for vectorization. Then create the logic app to replicate the files along with it’s format and properties to the associated blob storage – 1] Assign the site address and the directory name where the documents are uploaded in Sharepoint – In the trigger action “When an item is created or modified”. 2] Assign a recurrence frequency, start time and time zone to check/verify for new documents and keep the blob container updated. 3] Add an action component – “Get file content using path”; and dynamically provide the full path (includes file extension), from the trigger 4] Finally, add an action to create blobs in the designated container that would be vectorized – provide the storage acc. name, directory path, the name of blob (Select to dynamically get the file name with extension for the trigger), blob content (from the get file content action). 5] On successfully saving & running this logic app, either manually or on trigger, the files are replicated in it’s exact form to the blob storage. Stage 2 :- Azure AI Search resource to vectorize the files in blob storage In Azure Portal (Home – Microsoft Azure), search for Azure AI Search service, and provide the necessary details, based on your requirement select a pricing tier. Once resource is successfully created, select “Import & vectorize data” From the 2 options – RAG and Multimodal RAG Index, select the latter one.RAG combines a retriever (to fetch relevant documents) with a generative language model (to generate answers) using text-only data. Multimodal RAG extends the RAG architecture to include multiple data types such as text, images, tables, PDFs, diagrams, audio, or video. Workflow: Now follow the steps and provide the necessary details for the index creation Enable deletion tracking, to remove the records of deleted documents from the index Provide a document intelligence resource to enable OCR, and to get location metadata for multiple document types. Select image verbalization (to verbalize text in images) or multimodal embedding to vectorize the whole image. Assign the LLM model for generating the embeddings for the text/images provide an image output location, to store images extracted from the files Assign a schedule to refresh the indexer and to keep the search index up to date with new documents. Once successfully created, search keywords in the search explorer of the index, to verify the vectorization, the results are provided based on it’s relevance and score/distance, to the user’s search query. Let us test this index in Custom Copilot Agent , by importing this index as an azure ai search knowledge source. On fetching details of certain document specific information, the index is searched for the most appropriate information, and the result is rendered in readable format by generative AI.  We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com.

Managing multiple Dynamics 365 integrations across environments often becomes complex when each integration depends on static or hardcoded configuration values like API URLs, headers, secrets, or custom parameters. We faced similar challenges until we centralized our configuration strategy using Azure Blob Storage to host the configs and Logic Apps to dynamically fetch and apply them during execution. In this blog, we’ll walk through how we implemented this architecture and simplified config management across our D365 projects. Why We Needed Centralized Config Management In projects with multiple Logic Apps and D365 endpoints: Key problems: Solution Architecture Overview Key Components: Workflow: Step-by-Step Implementation Step 1: Store Config in Azure Blob Storage Example JSON: json CopyEdit {   “apiUrl”: “https://externalapi.com/v1/”,   “apiKey”: “xyz123abc”,   “timeout”: 60 } Step 2: Build Logic App to Read Config Step 3: Parse and Use Config Step 4: Apply to All Logic Apps Benefits of This Approach To conclude, centralizing D365 integration configs using Azure Blob and Logic Apps transformed our integration architecture. It made our systems easier to maintain, more scalable, and resilient to changes.Are you still hardcoding configs in your Logic Apps or Power Automate flows? Start organizing your integration configs in Azure Blob today, and build workflows that are smart, scalable, and maintainable. I hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com.

If you’ve worked with Dynamics 365 CRM for any serious integration project, you’ve probably used Azure Logic Apps. They’re great — visual, no-code, and fast to deploy. But as your integration needs grow, you quickly hit complexity: multiple entities, large volumes, branching logic, error handling, and reusability. That’s when architecture becomes critical. In this blog, I’ll share how we built a modular, scalable, and reusable integration architecture using Logic Apps + Azure Functions + Azure Blob Storage — with a config-driven approach. Whether you’re syncing data between D365 and Finance & Operations, or automating CRM workflows with external APIs, this post will help you avoid bottlenecks and stay maintainable. Architecture Components Component Purpose Parent Logic App Entry point, reads config from blob, iterates entities Child Logic App(s) Handles each entity sync (Project, Task, Team, etc.) Azure Blob Storage Hosts configuration files, Liquid templates, checkpoint data Azure Function Performs advanced transformation via Liquid templates CRM & F&O APIs Source and target systems Step-by-Step Breakdown 1. Configuration-Driven Logic We didn’t hardcode URLs, fields, or entities. Everything lives in a central config.json in Blob Storage: { “integrationName”: “ProjectToFNO”,   “sourceEntity”: “msdyn_project”,   “targetEntity”: “ProjectsV2”,   “liquidTemplate”: “projectToFno.liquid”,   “primaryKey”: “msdyn_projectid” } 2. Parent–Child Logic App Model Instead of one massive workflow, we created a parent Logic App that: Each child handles: 3. Azure Function for Transformation Why not use Logic App’s Compose or Data Operations? Because complex mapping (especially D365 → F&O) quickly becomes unreadable. Instead: {   “ProjectName”: “{{ msdyn_subject }}”,   “Customer”: “{{ customerid.name }}” } 4. Handling Checkpoints For batch integration (daily/hourly), we store last run timestamp in Blob: {   “entity”: “msdyn_project”,   “modifiedon”: “2025-07-28T22:00:00Z” } This allows delta fetches like: ?$filter=modifiedon gt 2025-07-28T22:00:00Z After each run, we update the checkpoint blob. 5. Centralized Logging & Alerts We configured: This helped us track down integration mismatches fast. Why This Architecture Works Need How It’s Solved Reusability Config-based logic + modular templates Maintainability Each Logic App has one job Scalability Add new entities via config, not code Monitoring Blob + Monitor integration Transformation complexity Handled via Azure Functions + Liquid Key Takeaways To conclude, this architecture has helped us deliver scalable Dynamics 365 integrations, including syncing Projects, Tasks, Teams, and Time Entries to F&O all without rewriting Logic Apps every time a client asks for a tweak. If you’re working on medium to complex D365 integrations, consider going config-driven and breaking your workflows into modular components. It keeps things clean, reusable, and much easier to maintain in the long run. I hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com.