Summary Enterprise API integrations require more than simply obtaining an access token. The authentication model must provide a reliable way for an application to establish its identity while protecting the credentials used to do so. In this implementation, we explored a certificate-based authentication architecture using Microsoft Entra ID, an X.509 self-signed certificate, Azure Key Vault, Azure Functions, Managed Identity, and Microsoft Authentication Library (MSAL). The objective was to replace dependency on an expiring client secret with a certificate-backed application identity, while keeping the private certificate protected within Azure infrastructure. This article walks through the complete implementation — from creating the certificate and registering its public key, to storing the private certificate in Key Vault, configuring the Function App, and ultimately obtaining an OAuth 2.0 access token through MSAL. Table of Contents Introduction The Business Requirement Why Certificate-Based Authentication? Solution Overview The Authentication Architecture Step 1 — Creating the Microsoft Entra App Registration Step 2 — Creating the Self-Signed Certificate Step 3 — Exporting the Certificate Step 4 — Importing the Private Certificate into Azure Key Vault Step 5 — Registering the Public Certificate with Entra ID Step 6 — Creating the Azure Function Step 7 — Enabling Managed Identity Step 8 — Granting Key Vault Access Step 9 — Configuring Function App Settings Step 10 — Implementing Certificate Authentication with MSAL Step 11 — Obtaining the Access Token Understanding the Client Assertion Security and Production Considerations Key Implementation Lessons Frequently Asked Questions Conclusion Case Study Read more about our Journey with this Customer over here: View Case Study Introduction Enterprise applications increasingly depend on APIs to connect business processes across platforms. Microsoft Partner Center and other Microsoft services provide powerful APIs for automation, reporting, partner operations, customer processes, and broader Microsoft ecosystem integrations. As an integration moves toward production, however, authentication becomes an architectural concern rather than simply a configuration task. A client secret may be sufficient during initial development, but production integrations introduce additional questions: How should application credentials be protected? How should credentials be rotated? How can private credentials be kept outside application code? How can authentication be centralized for multiple consumers? How can the solution reduce dependency on manually managed secrets? These considerations led to a certificate-based authentication approach: Use a certificate-backed application identity, protect the private certificate in Azure Key Vault, and use an Azure Function with Managed Identity and MSAL to obtain the downstream access token. The implementation described in this article demonstrates that architecture from beginning to end using a self-signed certificate as the initial certificate credential. The Business Requirement The requirement was to establish an application-to-application authentication mechanism for Microsoft API integrations without relying on a long-lived client secret embedded across application components. The traditional client-secret model is straightforward: Application ↓ Client ID + Client Secret ↓ Microsoft Entra ID ↓ Access Token ↓ Target API The challenge is that the client secret behaves like a password. It must be securely stored, rotated, replaced before expiration, and carefully distributed to every application or service that needs it. The target architecture instead establishes application identity using a certificate: Application ↓ Certificate-backed application identity ↓ Microsoft Entra ID ↓ Access Token ↓ Target API Azure Key Vault then provides the security boundary for the private certificate material. Why Certificate-Based Authentication? Certificate authentication is based on asymmetric cryptography. The certificate contains a public key and corresponds to a private key. The public certificate can be registered with Microsoft Entra ID, while the private key remains protected by the application infrastructure. Microsoft Entra ID │ Public Certificate │ │ validates ▼ Azure Function ────── Signed Assertion │ │ └── Private Key protected by Azure Key Vault The important difference from a client secret is that the application proves possession of the private key rather than sending a reusable password-like credential as its application credential. Microsoft Authentication Library (MSAL) supports certificate credentials for confidential client applications. In MSAL.NET, the .WithCertificate() configuration allows MSAL to use the certificate to perform the client authentication process. Solution Overview End-to-end certificate-based authentication architecture The implementation separates authentication responsibilities across several Azure and Microsoft identity components. Component Responsibility Microsoft Entra App Registration Represents the application identity Public Certificate Registered with Entra ID to validate the application Private Certificate Used to prove possession of the registered certificate Azure Key Vault Protects the private certificate material Managed Identity Allows the Function App to access Key Vault without another secret Azure Function Centralizes token acquisition MSAL Handles the OAuth 2.0 client-credential authentication process Access Token Used to authorize requests against the target API The Authentication Architecture The complete authentication sequence can be simplified to: 1. Application calls the authentication Function ↓ 2. Function authenticates to Azure Key Vault using Managed Identity ↓ 3. Function retrieves the private certificate ↓ 4. MSAL loads the certificate ↓ 5. MSAL creates the signed client assertion ↓ 6. Assertion is sent to Microsoft Entra ID ↓ 7. Entra validates the certificate ↓ 8. Entra issues the access token ↓ 9. Function returns the access token ↓ 10. Consumer uses the token against the target API The key architectural separation is that the consumer does not need to manage the private certificate directly. The authentication layer manages certificate access and token acquisition. Step 1 — Creating the Microsoft Entra App Registration The first step is to create an App Registration representing the application that will authenticate with Microsoft Entra ID. For this implementation, the test application registration was: skenycerttestappreg The App Registration provides the application’s Client ID and Tenant ID and acts as the identity against which the certificate credential is registered. The App Registration stores the public certificate credential. It does not require the private key to be uploaded to Entra ID. Step 2 — Creating the Self-Signed Certificate For the initial implementation, a self-signed certificate was created locally using PowerShell. $cert = New-SelfSignedCertificate ` -Subject “CN=Test App Registration Certificate” ` -CertStoreLocation “Cert:\CurrentUser\My” ` -KeyExportPolicy Exportable ` -KeySpec Signature ` -KeyLength 2048 ` -NotAfter (Get-Date).AddYears(2) This creates a certificate … Continue reading From Client Secrets to Certificate-Based Authentication: Building a Secure Integration with Azure Key Vault and Azure Functions for a US based AI & Cyber Security Company →

Summary A global life-sciences and laboratory equipment supplier sends purchase orders to our customer (BÜCHI’s customer-centric vision accelerates innovation using Azure Integration Services | Microsoft) as machine-generated cXML OrderRequest.xml documents. The customer runs Infor LN, which expects a SalesOrder BOD delivered through the Infor ION I/O Box. Between the two sat a translation problem that was being solved by hand. Every order arriving from the trading partner had to be read, interpreted and re-keyed into Infor LN by the order desk. That worked at low volume. It did not scale, it delayed order confirmation by hours, and it introduced transcription errors on the fields that matter most — quantities, delivery dates and ship-to addresses. We closed that gap with Azure Integration Services: API Management as the secure front door, Blob Storage as the immutable archive, Service Bus for asynchronous decoupling and retries, Azure Functions in C# for the cXML-to-BOD translation, and a write into the Infor ION I/O Box SQL database from which ION creates the sales order in LN. Key Vault and App Configuration hold secrets and environment-specific values; Application Insights makes every transaction traceable end to end. The result is a straight-through process: Partner posts cXML → Archive → Queue → Transform to BOD → I/O Box → Infor ION → Sales Order in LN. This article covers how the interface was designed, how the mapping and its business rules were kept maintainable, how failures are handled and replayed, and the guardrails that keep an asynchronous EDI interface trustworthy in production. Table of Contents From Manual Order Entry to Automated Order Intake The Business Challenge Solution Overview Receiving the Purchase Order: Azure API Management Decoupling the Interface: Azure Service Bus Translating cXML into the Infor Process.SalesOrder BOD The Business Rules Hidden Inside the Mapping Writing to the Infor ION I/O Box Handling Exceptions, Retries and Replay Technical Architecture Monitoring with Application Insights Designing the Integration Around Business Events Business Impact Design Constraints and Guardrails Final Thoughts This Blog Explains Why manual order entry from EDI purchase orders stops scaling, and what it costs. How a partner cXML OrderRequest is received, archived and queued on Azure. How the cXML document is translated into an Infor Process.SalesOrder BOD. How conditional business rules — partner cross-references, note construction, ship-date fallbacks — are kept out of hard-coded logic. How multi-line orders are looped into SalesOrderPosition blocks. How the BOD is handed to Infor LN through the ION I/O Box. How failures are retried, dead-lettered and replayed without asking the partner to resend. How a single transaction ID makes the whole interface searchable in Application Insights. From Manual Order Entry to Automated Order Intake For manufacturers that sell through large, process-driven customers, the order does not arrive as a phone call or an email attachment. It arrives as a machine-generated EDI document, posted to an endpoint at any hour of the day, in a format defined entirely by the buyer. Our customer — a European division of a global life-sciences and laboratory equipment supplier — runs Infor LN as its ERP. Their key trading partner sends purchase orders as cXML OrderRequest.xml documents. Infor LN, on the other side, expects a Process.SalesOrder BOD delivered through the Infor ION I/O Box. Both systems were working exactly as designed. The problem lived in the space between them, and that space was being crossed by a person with a keyboard. A purchase order that arrives electronically and is then typed in by hand is not an integrated process. It is a manual process with an electronic first step. The objective of the project was therefore narrow and concrete: when the trading partner posts an order, a sales order should appear in Infor LN — correctly mapped, without human intervention, and with enough visibility that the support team can prove it happened. The Business Challenge On the surface this looks like a file conversion. In practice, five things made it anything but. 1. Two Schemas That Share Almost No Vocabulary cXML is a flat, attribute-heavy commerce format. The Infor BOD is a deeply nested OAGIS structure with an ApplicationArea envelope, a DataArea payload and a UserArea carrying LN-specific properties. Almost every field required transformation rather than a straight copy. 2. Business Logic Hidden Inside the Mapping The partner’s identity codes had to be cross-referenced to Infor LN business partner IDs — with different values in Test and Production. Header comments needed a hardcoded Remark: prefix. Goods marks, customer references and order numbers had to be concatenated into a single footer note, skipping the values that did not arrive so no blank lines were left behind. 3. A Ship Date With a Rule of Its Own Requested ship date could not simply be copied. If the line carries a date, use it. If it is missing, or in the past, use the current date. If the order has multiple lines with different dates, take the earliest. A rule that reads as one sentence in a specification becomes a decision tree in code. 4. Line-Level Repetition A single order can contain many ItemOut elements, each of which becomes a SalesOrderPosition block in the BOD, carrying its own item ID, quantity, required delivery date and note. 5. No Second Chances, and No Visibility The exchange is asynchronous and real-time. If a message failed silently, the first sign of trouble would be the customer asking why their order had not shipped. Operations needed to answer “what happened to this order?” without raising a support ticket. Manual re-keying was the fallback, and it carried exactly the costs you would expect: order entry delays measured in hours, transcription errors on quantities and delivery dates, and a team doing work that added no value. Solution Overview We built the interface on Azure Integration Services as a set of small, independently deployable components rather than one monolithic job. The solution uses: Azure API Management Azure Blob Storage Azure Service Bus Azure Functions (C#) Infor ION I/O Box (SQL) Azure Key Vault and App Configuration Application … Continue reading From Trading Partner cXML to Infor LN Sales Order: How a European Life-Sciences Manufacturer Automated EDI Order Intake with Azure Integration Services →

Summary Enterprises running large, multi-country ERP systems often extract data that is technically complete but practically unusable, split across duplicate language columns and encoded with undocumented numeric values. We built a self-service data platform on Azure so that business users, not just data engineers, could define, validate, and process ERP extracts without writing a single line of code. The solution resolves two of the most common ERP data problems: a single field like “Item Description” spread across nine language-specific columns, and reference fields like “Order Status” stored only as numeric codes. A custom web portal puts business users in control of table specifications, validation rules, and processing status, while Azure Databricks and Delta Lake quietly do the heavy lifting behind the scenes. Business impact: dozens of ERP tables moved from raw, multi-language, code-heavy extracts to a single, trusted, human-readable data layer, without adding headcount to the data engineering team. Table of Contents 01  About the Customer 05  Self-Service Data Onboarding 02  The Challenge 06  Medallion Architecture 03  The Solution 07  Business Impact 08  FAQs 09  Conclusion About the Customer Customer Spotlight A Leading Digital Transformation Partner — Europe Our customer is a leading enterprise headquartered in Europe, operating across diverse manufacturing and supply chain divisions. Having already standardized their ERP data through a medallion architecture on Databricks, leadership wanted to go a step further: not only manage ERP data at scale, but also connect it seamlessly into process mining tools to uncover how core processes truly perform in practice. The focus was on gaining operational clarity into workflows such as purchase order management, invoice handling, and procurement cycles. The Challenge Most organizations extracting data from a large ERP system successfully get the data out. The problem isn’t extraction, it’s making that data mean something the moment it lands. Business and IT teams found themselves asking the same questions on repeat: 1Why does the same field appear nine times, with a different value in each column? 2What does “Order Status= 3” actually mean, and who is the source of truth for that mapping? 3How much manual translation and lookup work happens before a single report can be trusted? 4Can business users resolve these issues themselves, without waiting weeks on an IT backlog? 5How do we scale this across dozens of tables without writing dozens of one-off scripts? Two problems came up again and again, and both are far more common across ERP implementations than most leadership teams realize. Multi-Language Columns Because the ERP system was configured for every Order Status the business operates in, a single logical field such as “Item Description” existed as up to nine separate columns, one per language: English, French, German, Spanish, and more. Reports built directly on top of the raw extract had no reliable way of knowing which column to use for which record. In practice, this meant a plant manager in France could open a report and see item names in German, while a sales report for the Spanish market silently pulled blank fields because the Spanish-language column hadn’t been populated for that record. The data was all there; it just wasn’t usable without someone manually deciding, table by table, which language column to trust. Undocumented Domain Values Reference fields like Country, Currency, and Order Status were stored as raw numeric codes rather than readable labels, for example Order Status: 1 = Completed , 2 = In Progress, 3 = Shipped. These mappings lived inside ERP configuration screens, not in the extracted data itself. That meant every downstream report, dashboard, or spreadsheet needed its own copy of the same lookup table, manually kept in sync. When a code changed or a new Order Status was added in the ERP, there was no guarantee every report using it would be updated at the same time, which meant leadership could be looking at the performance chart that was quietly wrong. The Solution Rather than writing custom transformation logic for every table (a solution that ages badly the moment a new table or region gets added), we designed a configuration-driven pipeline built on Azure Databricks, fronted by a self-service web application that puts control directly in the hands of business and functional users. Self-Service Web Portal Business users upload table specifications, review validation results, and queue tables for processing, entirely through a browser. Medallion Architecture Azure Databricks and Delta Lake refine raw extracts through Bronze, Silver, and Gold layers, without table-specific code. Automated Language Resolution Multi-language columns are detected and normalized automatically based on the specification, not hardcoded per table. Centralized Domain Mapping Numeric and coded reference values are resolved against a single, maintained lookup layer instead of scattered spreadsheets. Self-Service Data Onboarding: No Databricks Knowledge Required The centerpiece of the solution is a custom web application that lets a business or functional analyst, not a Databricks engineer, onboard a new ERP table from start to finish. Here’s what that looks like in practice: A business user uploads an Excel-based table specification defining the expected columns, data types, which fields are multi-language, and which fields are domain-coded and how to decode them. The portal validates the specification instantly, flagging missing mandatory columns or mismatches before any data is processed, so problems are caught at the source rather than three reports downstream. Once validation passes, the same user queues the table for processing with a single click. No notebook to open, no cluster to configure, no code to write or review. Behind the scenes, that specification feeds a generic, reusable Databricks framework that already knows how to apply the correct language resolution and domain-value decoding rules, so engineering effort doesn’t scale linearly with the number of tables. In effect, the portal turns “add a new ERP table to the analytics environment” from a data engineering request into a form a finance or operations analyst can complete in minutes, while still enforcing the same rigor and consistency a hand-built pipeline would require. Medallion Architecture on Databricks Once a table is queued through the portal, Azure Databricks takes over: Bronze: Raw ERP extracts are landed as-is, preserving … Continue reading How a Self-Service Data Portal Solved Multi-Language and Domain Value Chaos in ERP Data →

As businesses scale, payroll complexity grows bringing challenges around employee data, attendance, compensation structures, and compliance. Manual processes not only consume valuable time but also increase the risk of costly errors. The Zoho People-FNO integration transforms payroll into a streamlined, automated process, ensuring accurate salary calculations, seamless data synchronization, and complete transparency across HR and finance operations. We recently implemented this solution for a global manufacturing hardware enterprise, enabling them to automate payroll workflows, eliminate manual data reconciliation, improve payroll accuracy, and reduce administrative overhead. The integration provided a scalable foundation for managing a growing workforce while maintaining compliance and enhancing the employee experience through faster, more transparent payroll processing. For organizations focused on operational efficiency and sustainable growth, this integration delivers measurable business value from day one. Understanding the Architecture of Zoho and FNO Integration The integration between Zoho People and FNO involves a clear, structured workflow. Below is an overview of the steps involved: This architecture ensures a smooth flow of data between Zoho and FNO, simplifying payroll management for businesses of all sizes. Key Advantages of Zoho and FNO Integration The integration between Zoho People and FNO streamlines payroll management, providing several key benefits: Effortless Payroll Management for Growing Businesses To conclude, efficient payroll management is essential for any growing business. By integrating Zoho People with FNO, businesses can automate payroll processes, ensure accurate calculations, and provide employees with easy access to their payslips. The seamless data flow, real-time updates, and reduced manual intervention significantly improve operational efficiency and transparency. If you’re ready to optimize your payroll system, now is the time to take action. Embrace the Zoho and FNO integration to simplify your processes, reduce errors, and create a transparent payroll system that benefits both your employees and your organization. Contact us today to learn how this integration can simplify your payroll management process. Reach out at transform@cloudfronts.com.

Organizations today generate massive volumes of raw data from multiple sources such as ERP systems, CRMs, APIs, logs, and IoT devices. However, raw data by itself holds little value unless it is properly processed, transformed, and optimized for analytics. In our data engineering journey, we faced challenges in building scalable and maintainable ETL pipelines that could handle growing data volumes while still delivering reliable insights. Azure Databricks helped us bridge the gap between raw data and business-ready insights. In this blog, we’ll walk through ETL best practices using Azure Databricks and how they helped us build efficient, production-grade data pipelines. Why ETL Best Practices Matter When working with large-scale data pipelines: – Raw data arrives in different formats and structures– Poorly designed ETL jobs lead to performance bottlenecks– Debugging and maintaining pipelines becomes difficult– Data quality issues propagate to downstream reports Key challenges we faced: – Tight coupling between ingestion and transformation– Reprocessing large datasets due to small logic changes– Lack of standardization across pipelines– Slow query performance on analytical layers Solution Architecture Overview Key Components: – Azure Data Lake Storage Gen2– Azure Databricks– Delta Lake– Power BI / Analytics Tools ETL Flow: – Ingest raw data from source systems into the Raw (Bronze) layer– Clean, validate, and standardize data in the Processed (Silver) layer– Apply business logic and aggregations in the Curated (Gold) layer– Expose curated datasets to reporting and analytics tools Step-by-Step ETL Best Practices with Azure Databricks Step 1: Separate Data into Layers (Bronze, Silver, Gold) – Bronze Layer: Store raw data exactly as received– Silver Layer: Apply cleansing, deduplication, and schema enforcement– Gold Layer: Create business-ready datasets and aggregations This separation ensures reusability and prevents unnecessary reprocessing. Step 2: Use Delta Lake for Reliability – Store tables in Delta format– Enable schema enforcement and schema evolution– Leverage time travel for data recovery and debugging Step 3: Build Incremental Pipelines – Process only new or changed data using watermarking– Avoid full reloads unless absolutely required– Design pipelines to safely re-run without duplications Step 4: Parameterize and Modularize Code – Use notebook parameters for environment-specific values– Create reusable functions for common transformations– Avoid hardcoding paths, table names, or business rules Step 5: Optimize Performance Early – Use partitioning based on query patterns– Apply Z-ORDER on frequently filtered columns– Cache datasets selectively for heavy transformations Step 6: Implement Data Quality Checks – Validate nulls, ranges, and duplicate records– Log rejected or invalid records separately– Fail pipelines early when critical checks fail Benefits of Following These ETL Best Practices – Scalability: Easily handle growing data volumes– Reliability: ACID-compliant pipelines with Delta Lake– Maintainability: Modular and reusable code structure– Performance: Faster queries and optimized storage– Cost Efficiency: Reduced compute usage through incremental processing Conclusion Transforming raw data into meaningful insights requires more than just moving data from one place to another. By following ETL best practices with Azure Databricks, we were able to build robust, scalable, and high-performing data pipelines that deliver reliable insights to the business. If your Databricks pipelines are becoming complex, slow, or difficult to maintain, it might be time to revisit your ETL design. Start applying these best practices today and turn your raw data into insights that truly drive decision-making. 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.

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.

Summary A global manufacturing client was facing rising middleware costs, poor visibility, and growing pressure to support analytics and AI initiatives. A forced three-year middleware commitment became the trigger to rethink their integration strategy. This article shares how the client moved away from legacy middleware, reduced integration costs by nearly 95%, improved operational visibility, and built a strong data foundation for the future. Table of Contents 1. The Middleware Cost Problem 2. Building a New Integration Setup 3. Making Integrations Visible 4. Preparing Data for AI 5. How We Did It Savings Metrics The Middleware Cost Problem The client was running critical integrations on a legacy middleware platform that had gradually become a financial and operational burden. Licensing costs increased sharply, with annual fees rising from $20,000 to $50,000 and a mandatory three-year commitment pushing the total to $160,000. Despite the cost, visibility remained limited. Integrations behaved like black boxes, failures were difficult to trace, and teams relied on manual intervention to diagnose and fix issues. At the same time, the business was pushing toward better reporting, analytics, and AI-driven insights. These initiatives required clean and reliable data flows that the existing middleware could not provide efficiently. Building a New Integration Setup Legacy middleware and Scribe-based integrations were replaced with Azure Logic Apps and Azure Functions. The new setup was designed to support global operations across multiple legal entities. Separate DataAreaIDs were maintained for regions including TOUS, TOUK, TOIN, and TOCN. Branching logic handled country-specific account number mappings such as cf_accountnumberus and cf_accountnumberuk. An agentless architecture was adopted using Azure Blob Storage with Logic Apps. This removed firewall and SQL connectivity challenges and eliminated reliance on unsupported personal-mode gateways. Making Integrations Visible The previous setup offered no centralized monitoring, making it difficult to detect failures early. A Power BI dashboard built on Azure Log Analytics provided a clear view of integration health and execution status. Automated alerts were configured to notify teams within one hour of failures, allowing issues to be addressed before impacting critical business processes. Preparing Data for AI With stable integrations in place, the focus shifted from cost savings to long-term readiness. Clean data flows became the foundation for platforms such as Databricks and governance layers like Unity Catalog. The architecture supports conversational AI use cases, enabling questions like “Is raw material available for this production order?” to be answered from a unified data foundation. As a first step, 32 reports were consolidated into a single catalog to validate data quality and integration reliability. How We Did It Retrieve config.json and checkpoint.txt from Azure Blob Storage for configuration and state control. Run incremental HTTP GET queries using ModifiedDateTime1 gt [CheckpointTimestamp]. Check for existing records using OData queries in target systems with keys such as ScribeCRMKey. Transform data using Azure Functions with region-specific Liquid templates. Write data securely using PATCH or POST operations with OAuth 2.0 authentication. Update checkpoint timestamps in Azure Blob Storage after successful execution. Log step-level success or failure using a centralized Logging Logic App (TO-UAT-Logs). Savings Metrics 95% reduction in annual integration costs, from $50,000 to approximately $2,555. Approximately $140,000 in annual savings. Integrations across D365 Field Service, D365 Sales, D365 Finance & Operations, Shopify, and SQL Server. Designed to support modernization of more than 600 fragmented reports. FAQs Q: How does this impact Shopify integrations? A: Azure Integration Services acts as the middle layer, enabling Shopify orders to synchronize into Finance & Operations and CRM systems in real time. Q: Is the system secure for global entities? A: Yes. The solution uses Azure AD OAuth 2.0 and centralized key management for all API calls. Q: Can it handle attachments? A: Dedicated Logic Apps were designed to synchronize CRM annotations and attachments to SQL servers located behind firewalls using an agentless architecture. 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 a world where timing, accuracy, and coordination make or break profitability, modern project-based enterprises demand more than isolated systems. You may be leveraging Dynamics 365 Project Operations (ProjOps) to manage projects, timesheets, and resource planning and Dynamics 365 Finance & Operations (F&O) for financials, billing, and accounting. But without seamless integration, you’re stuck with manual transfers, data silos, and delayed insights.  That’s where PO F&O Connector app comes in built to synchronize Project Operations and F&O end-to-end, bringing together delivery and finance in perfect alignment. In this article, we’ll explore how it works, why it matters to CEOs, CFOs, and CTOs, and how adopting it gives you a competitive edge.  The Pain Point: Disconnected Project & Finance Workflows  When your project execution and financial systems aren’t talking:  The result? Missed revenue, resource inefficiencies, and poor visibility into project financial health.  The Solution: Cloudfronts Project-to-Finance Integration App  Cloudfronts new app is purpose-built to connect Project Operations → Finance & Operations seamlessly, automating the flow of project data into financial systems and enabling real-time, consistent delivery-to-finance synchronization. Key capabilities include:  Role  Core Benefits  Outcomes  CEO  Visibility into project margins and outcomes; faster time to value  Better strategic decisions, competitive agility  CFO  Automates billing, enforces accounting rules, ensures audit compliance  Revenue gets recognized faster, finance becomes a strategic enabler  CTO  Reduces custom integration burdens, ensures system integrity  Lower maintenance costs, scalable architecture  Beyond roles, your entire organization benefits through:  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

When integrating Dynamics 365 with external systems, one of the first decisions you’ll face is real-time vs batch (scheduled) integration. It might sound simple, but choosing the wrong approach can lead to performance issues, unhappy users, or even data inconsistency. In this blog, I’ll Walk through the key differences, when to use each, and lessons we’ve learned from real projects across Dynamics 365 CRM and F&O. The Basics: What’s the Difference? Type Description Real-Time Data syncs immediately after an event (record created/updated, API call). Batch Data syncs periodically (every 5 mins, hourly, nightly, etc.) via schedule. Think of real-time like WhatsApp you send a message, it goes instantly. Batch is like checking your email every hour you get all updates at once. When to Use Real-Time Integration Use It When: Example: When a Sales Order is created in D365 CRM, we trigger a Logic App instantly to create the corresponding Project Contract in F&O. Key Considerations When to Use Batch Integration Use It When: Example: We batch sync Time Entries from CRM to F&O every night using Azure Logic Apps and Azure Blob checkpointing. Key Considerations Our Experience from the Field On one recent project: As a Result, the system was stable, scalable, and cost-effective. To conclude, you don’t have to pick just one. Many of our D365 projects use a hybrid model: Start by analysing your data volume, user expectations, and system limits — then pick what fits best. 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

From AI Experiments to AI That Can Be Trusted  Generative AI has moved from experimentation to executive priority. Yet across industries, many organizations struggle to convert pilots into dependable business outcomes.  At CloudFronts, we’ve consistently seen why.  Whether working with Sonee Hardware in distribution and retail or BÜCHI Labortechnik AG in manufacturing and life sciences, AI success has never started with models. It has started with trust in data.  AI that operates on fragmented, inconsistent, or poorly governed data introduces risk not advantage. The organizations that succeed follow a different path: they build intelligence on top of trusted, enterprise-grade data platforms.  The Real Challenge: AI Without Context or Control  Most stalled AI initiatives share common traits:  This pattern leads to AI that looks impressive in demos but struggles in production.  CloudFronts has seen this firsthand when customers approach AI before fixing data fragmentation. In contrast, customers who first unified ERP, CRM, and operational data created a far smoother path to AI-driven decision-making.  What Data-Native AI Looks Like in Practice  Agent Bricks represents a shift from model-centric AI to data-centric intelligence, where AI agents operate directly inside the enterprise data ecosystem.  This aligns closely with how CloudFronts has helped customers mature their data platforms:  In both cases, AI readiness emerged naturally once data trust was established.  Why Modularity Matters at Enterprise Scale  Enterprise intelligence is not built with a single AI agent.  It requires:  Agent Bricks mirrors how modern enterprises already operate through modular, orchestrated components rather than monolithic solutions.  This same principle guided CloudFronts data architecture work with customers:  AI agents built on top of this architecture inherit the same scalability and control.  Governance Is the Difference Between Insight and Risk  One of the most underestimated risks in AI adoption is hallucination, AI confidently delivering incorrect or unverifiable answers.  CloudFronts customers in regulated and data-intensive industries are especially sensitive to this risk.  For example:  By embedding AI agents directly into governed data platforms (via Unity Catalog and Lakehouse architecture), Agent Bricks ensures AI outputs are traceable, explainable, and trusted.  From Reporting to “Ask-Me-Anything” Intelligence  Most CloudFronts customers already start with a familiar goal: better reporting.  The journey typically evolves as follows:  This is the same evolution seen with customers like Sonee Hardware, where reliable reporting laid the groundwork for more advanced analytics and eventually AI-driven insights.  Agent Bricks accelerates this final leap by enabling conversational, governed access to enterprise data without bypassing controls.  Choosing the Right AI Platform Is About Maturity, Not Hype  CloudFronts advises customers that AI platforms are not mutually exclusive:  The deciding factor is data maturity.  Organizations with fragmented data struggle with AI regardless of platform. Those with trusted, governed data like CloudFronts mature ERP and analytics customers are best positioned to unlock Agent Bricks’ full value.  What Business Leaders Can Learn from Real Customer Journeys  Across CloudFronts customer engagements, a consistent pattern emerges:  AI success follows data maturity not the other way around.  Customers who:  were able to adopt AI faster, safer, and with measurable outcomes.  Agent Bricks aligns perfectly with this reality because it doesn’t ask organizations to trust AI blindly. It builds AI where trust already exists.  The Bigger Picture  Agent Bricks is not just an AI framework it reflects the next phase of enterprise intelligence.  From isolated AI experiments to integrated, governed decision systems  From dashboards to conversational, explainable insight  From AI as an initiative to AI as a core business capability  At CloudFronts, this philosophy is already reflected in real customer success stories where data foundations came first, and AI followed naturally.  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