If you’ve ever needed to mark multiple quotes as lost in Dynamics 365, you know the default “Close Quote” dialog can be slow and repetitive.In my recent project, the sales team wanted a faster way, one click from the main Quotes view, to disqualify single or multiple quotes, without opening each one or clicking through extra prompts. Using the out-of-the-box CloseQuote action, a small JavaScript function, and a custom Ribbon Workbench button, I built exactly that. Here’s how. Why I Needed This Our sales team often manages multiple quotes at once. The standard process meant: It was time-consuming, especially for bulk operations. We needed a quick, grid-based action that would: Step 1 – Using the OOB CloseQuote Action Dynamics 365 provides a built-in CloseQuote bound action that changes the state and status of a quote to closed. Instead of creating a custom action, I decided to call this OOB action directly from JavaScript. Step 2 – JavaScript to Call the OOB Action Here’s the function I wrote to handle both single and multiple quotes: Step 3 – Adding the Ribbon Button in Ribbon Workbench Now, the button will be available directly on the Quotes view. Step 4 – Testing the Feature This reduced what was previously a multi-click, per-record task into a single action for any number of quotes. Why This Works Well To conclude, by combining the OOB Close Quote action with Ribbon Workbench, I could instantly disqualify quotes from the main grid, saving hours over the course of a month. If you’re looking to simplify repetitive processes in Dynamics 365, start by exploring what’s already available out of the box, then add just enough customization to make it your own. 🔗 Need help implementing a custom button or enhancing your Dynamics 365 sales process? At CloudFronts, we help businesses design and implement scalable, user-friendly solutions that streamline daily operations and improve adoption. Whether it’s customizing Ribbon Workbench, integrating OOB actions, or building tailored automation, our team can make it happen. 📩 Reach out to us at transform@cloudfronts.com and let’s discuss how we can optimize your Dynamics 365 environment.

Why This Matters Imagine you’ve just delivered an order, and now there’s a service issue or repair request from the customer. What’s the best way to track and resolve that? That’s where Cases come in. This blog walks you through how your company can use Cases in Dynamics 365 CRM to efficiently handle post-delivery service and repair requests—directly linked to the order fulfillment process for better visibility and control. Let’s break it down step by step. Step 1: Navigate to Cases from an Order Fulfillment Record Start by opening the Order Fulfillment record.Click on the “Related” dropdown and select “Cases” from the list. This takes you directly to all service cases related to that order. Step 2: Create a New Case Click on the “New Case” button in the Cases tab. A Quick Create: Case form appears. Here’s what you’ll see and fill in: Optional fields like Contact, Origin, Entitlement, and others can be filled in if needed.You can also include details such as First Response By, Resolve By, and Description, depending on your business requirements. Once done, hit Save and Close. Step 3: View All Related Cases After saving, you’ll see a list of all Cases associated with the order under the Case Associated View. Each entry includes key info like: This makes it easy to monitor all service activity related to an order at a glance. Step 4: Manage Case Details Click on any Case Title to open the full Case record. From here, you can: Step 5: Monitor Service Performance Navigate to Dashboards > Service and Repair to track ongoing Case performance. Here’s what you’ll see: This allows your company’s service team to monitor progress, manage workload, and identify recurring product or fulfillment issues. To conclude, by following this process, your company ensures that every post-delivery service or repair request is captured, tracked, and resolved—while keeping everything connected to the original order. It’s simple, efficient, and fully integrated into Dynamics 365 CRM. Hope this helps!!! 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.

Global equipment lessors often manage thousands of active contracts across multiple regions. Add in layered financing structures—equity, debt, and third-party investors—and the complexity grows rapidly. Manual processes in this environment create risks in billing accuracy, funding visibility, and profitability tracking. Choosing Microsoft Dynamics 365 Finance & Operations (F&O) by integrating Project Management, Subscription Billing, Dynamics 365 Sales Pro/CRM, Logic Apps, and Power BI, the platform automates the entire lease lifecycle while ensuring transparency and control. Lease Lifecycle Automation Subscription Billing Module: Lessors can: This automation ensures every lease follows consistent accounting treatment and reduces manual workload for finance teams. Multi-Layer Financing Most lessors fund contracts through multiple sources. Dynamics 365 F&O allows you to: This provides clarity not just for finance teams, but also for investors seeking insight into their returns. Business Impact To conclude, by automating lease setup and financing structures, lessors gain: If you are a Lessor and wish to digitize lease lifecycle management and layered financing, adopt the strategy explained above to scale systematically, reduce risks, and provide stakeholders with the visibility they expect. Let’s build the strategy together. You can reach out to us at transform@cloudfonts.com.

Dynamics 365 CRM provides an Out-of-the-Box (OOB) Business Closures feature to define non-working days across your organization. However, in many real-world scenarios, we often face limitations with the default interface in terms of customization, UX/UI control, or extensibility. In this blog post, I’ll Walk you through how you can replace the OOB Business Closures using a custom HTML + CSS + JavaScript web page embedded in Dynamics 365. This custom page will interact with a custom Dataverse table that stores your closure dates and related details. Why Replace the OOB Business Closures? Some of the common limitations of OOB Business Closures: What We’ll Build A custom web resource embedded in a Dynamics 365 CRM dashboard or form tab that: Step-by-Step Implementation 1. Create a Custom Table in Dataverse 2. Create the HTML Web Resource 3. Upload as Web Resource in CRM Benefits of this Approach – Fully customizable UI -Supports additional metadata (reason, region, team) -Extensible for APIs, workflows, Power Automate, etc. -Better UX for users with real-time interactivity To conclude, by using a simple HTML, CSS, and JavaScript front end, we can extend Dynamics 365 CRM to manage business closures in a much more flexible and modern way. It not only overcomes the limitations of the OOB feature but also gives us complete control over the user experience and data model. 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.

A job queue lets users set up and manage background tasks that run automatically. These tasks can be scheduled to run on a recurring schedule. For a long time, users had a common problem in Business Central—when a job queue failed, there was no alert or warning. You’d only notice something was wrong when a regular task didn’t run for a few days. Some people tried to fix this by setting up another job queue to watch and restart failed ones.But that didn’t always work, especially if an update happened at the same time. Now, Microsoft has finally added a built-in way to get alerts when a job queue fails.  You can get notified either inside Business Central or by using Business Events. In this blog, we’ll look at how to set up notifications directly within Business Central.  Configuration Search for “Assisted Setup” in Business Central’s global search. Scroll down till “Set up Job Queue notifications”. Click on Next. Add the additional users who need to be notified when the job queue fails along with the job creator (if required). Choose whether you want the notification to be in-product or using Business Events (and Power Automate). For now, I’m choosing in-product. Choose the frequency of the notification, you can have it either when a single job fails or you can have it after 3-5 jobs have failed (as per settings) Click on Finish. Now for testing I’ve run a job queue and on the home page, I get the following notification. Clicking on “Show more details” give me a list of all the failed job queues. To conclude, this new notification feature is a much-needed improvement and a good step forward. It helps users catch job queue failures quickly, without having to manually check every day.  However, the setup and experience still feel a bit buggy and lacklustre. With some refinements, it could be a lot smoother and more user-friendly.  If you need further assistance or have specific questions about your ERP setup, feel free to reach out for personalized guidance. 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.

As artificial intelligence continues to transform how we build and interact with software, AI agents are emerging as the new interface for users. Instead of clicking through menus or filling out forms, users can simply instruct agents to fetch reports, analyze datasets, or trigger workflows. The challenge is: how do these agents access external tools, APIs, or enterprise systems in a secure and standardized way? This is where the Model Context Protocol (MCP) comes into play. MCP is a protocol designed to connect AI agents to tools in a structured, consistent manner. Instead of building ad-hoc integrations for each agent and each tool, developers can expose their tools once via MCP — making them discoverable and callable by any MCP-compliant AI agent. In this article, we’ll explore: What an MCP server is and how it works a) How MCP uses JSON-RPC 2.0 as its communication layer b) How MCP solves the M×N integration problem c) How to implement a simple Weather Data MCP server in TypeScript d) How to test it locally using Postman or cURL What is an MCP Server? An MCP server is an HTTP or WebSocket endpoint that follows the Model Context Protocol, allowing AI systems to query, interact with, and call tools hosted by developers. MCP consists of several components: -Base Protocol – Core JSON-RPC message types -Lifecycle Management – Connection initialization, capability negotiation, and session handling -Server Features – Resources, prompts, and tools exposed by servers -Client Features – Sampling and root directory lists provided by clients -Utilities – Cross-cutting features such as logging or argument completion All MCP implementations must support the Base Protocol and Lifecycle Management. Other features are optional depending on the use case. Architecture: JSON-RPC 2.0 in MCP MCP messages follow the JSON-RPC 2.0 specification — a stateless, lightweight remote procedure call protocol that uses JSON for request and response payloads. Request format: json Copy Edit {   “jsonrpc”: “2.0”,   “id”: 1,   “method”: “methodName”,   “params”: {     “key”: “value”   } } id is required, must be a string or number, and must be unique within the session. method specifies the operation. params contains the method arguments. Response format: json Copy Edit {   “jsonrpc”: “2.0”,   “id”: 1,   “result”: {     “key”: “value”   } } Or, if an error occurs: json Copy Edit {   “jsonrpc”: “2.0”,   “id”: 1,   “error”: {     “code”: -32603,     “message”: “Internal error”   } } The ID must match the request it is responding to. The M×N Problem and How MCP Solves It. Without MCP, connecting M AI agents to N tools requires M×N separate integrations. This is inefficient and unscalable. With MCP, each agent implements a single MCP client, and each tool implements a single MCP server. Agents and tools can then communicate through a shared protocol, reducing integration effort from M×N to M+N. Project Setup Create the project directory: mkdir weather-mcp-sdk cd weather-mcp-sdk npm init -y Install dependencies: npm install @modelcontextprotocol/sdk zod axios express npm install –save-dev typescript ts-node @types/node @types/express npx tsc –init Implementing the Weather MCP Server We’ll use the WeatherAPI to fetch real-time weather data for a given city and expose it via MCP as a getWeather tool. src/index.ts import express from “express”; import axios from “axios”; import { McpServer } from “@modelcontextprotocol/sdk/server/mcp.js”; import { StreamableHTTPServerTransport } from “@modelcontextprotocol/sdk/server/streamableHttp.js”; import { z } from “zod”; const API_KEY = “YOUR_WEATHER_API_KEY”; // replace with your API key function getServer() {   const server = new McpServer({     name: “Weather MCP Server”,     version: “1.0.0”,   });   server.tool(     “getWeather”,     { city: z.string() },     async ({ city }) => {       const res = await axios.get(“http://api.weatherapi.com/v1/current.json”, {         params: { key: API_KEY, q: city, aqi: “no” },       });       const data = res.data;       return {         content: [           {             type: “text”,             text: `Weather in ${data.location.name}, ${data.location.country}: ${data.current.temp_c}°C, ${data.current.condition.text}`,           },         ],       };     }   );   return server; } const app = express(); app.use(express.json()); app.post(“/mcp”, async (req, res) => {   try {     const server = getServer();     const transport = new StreamableHTTPServerTransport({});     res.on(“close”, () => {       transport.close();       server.close();     });     await server.connect(transport);     await transport.handleRequest(req, res, req.body);   } catch (error) {     if (!res.headersSent) {       res.status(500).json({         jsonrpc: “2.0”,         error: { code: -32603, message: “Internal server error” },         id: null,       });     }   } }); const PORT = 3000; app.listen(PORT, () => {   console.log(`MCP Stateless HTTP Server running at http://localhost:${PORT}/mcp`); }); Testing the MCP Server Since MCP requires specific request formats and content negotiation, use Content-Type: application/json and Accept: application/json, text/event-stream headers. Step 1 — Initialize curl -X POST http://localhost:3000/mcp \   -H “Content-Type: application/json” \   -H “Accept: application/json, text/event-stream” \   -d ‘{     “jsonrpc”: “2.0”,     “id”: 1,     “method”: “initialize”,     “params”: {       “protocolVersion”: “2025-06-18”,       “capabilities”: { “elicitation”: {} },       “clientInfo”: { “name”: “example-client”, “version”: “1.0.0” }     }   }’ Example response: {   “jsonrpc”: “2.0”,   “id”: 1,   “result”: {     “protocolVersion”: “2025-06-18”,     “capabilities”: { “tools”: { “listChanged”: true } },     “serverInfo”: { “name”: “Weather MCP Server”, “version”: “1.0.0” }   } } Step 2 — Call the getWeather Tool curl -X POST http://localhost:3000/mcp \   -H “Content-Type: application/json” \   -H “Accept: application/json, text/event-stream” \   -d ‘{     “jsonrpc”: “2.0”,     “id”: 2,     “method”: “tools/call”,     “params”: {       “name”: “getWeather”,       “arguments”: { “city”: “London” }     }   }’ Example response: {   “jsonrpc”: “2.0”,   “id”: 2,   “result”: {     “content”: [       {         “type”: “text”,         “text”: “Weather in London, United Kingdom: 21°C, Partly cloudy”       }     ]   } } To conclude, we have built an MCP-compliant server in TypeScript that exposes a weather-fetching tool over HTTP. This simple implementation demonstrates: How to define and register tools with MCP How JSON-RPC 2.0 structures communication, and how to make your server compatible with any MCP-compliant AI agent. From here, you … Continue reading Creating an MCP Server Using TypeScript →

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.

. Key Takeaways 1. Bad data kills ML performance — duplicate, inconsistent, missing, or outdated data can break production models even if training accuracy is high.2. Databricks Medallion Architecture (Raw → Silver → Gold) is essential for turning raw chaos into structured, trustworthy datasets ready for ML & BI.3. Raw layer: capture all data as-is; Silver layer: clean, normalize, and standardize; Gold layer: curate, enrich, and prepare for modeling or reporting.4. Structured pipelines reduce compute cost, improve model reliability, and enable proactive monitoring & feature freshness.5. Data quality is as important as algorithms — invest in transformation and governance for scalable, accurate AI. While developing a Machine Learning Agent for Smart Pitch (Sales/Presales/Marketing Assistant chatbot) within the Databricks ecosystem, I’ve seen firsthand how unclean, inconsistent, and incomplete data can cripple even the most promising machine learning initiatives. While much attention is given to models and algorithms, what often goes unnoticed is the silent productivity killer lurking in your pipelines: bad data. In the chase to build intelligent applications, developers often overlook the foundational layer—data quality. Here’s the truth: It is difficult to scale machine learning on top of chaos. That’s where the Raw → Silver → Gold data transformation framework in Databricks becomes not just useful, but also essential. The Hidden Cost of Bad Data Imagine you’ve built a high-performance ML model. It’s accurate during training, but underperforms in production. Why?Here’s what I frequently detect when I scan input pipelines:– Duplicate records– Inconsistent data types– Missing values– Outdated information– Schema drift (Schema drift introduces malformed, inconsistent, or incomplete data that breaks validation rules and compromises downstream processes.)– Noise in DataThese issues inflate compute costs, introduce bias, and produce unstable predictions, resulting in wasted hours debugging pipelines, increased operational risks, and eroded trust in your AI outputs. Ref.: Data Poisoning: A Silent but Deadly Threat to AI and ML Systems | by Anya Kondamani | nFactor Technologies | Medium As you can see in this example – Despite successfully fetching data, it was unable to render it, due to hitting maximum request limit, as bad data was involved, thus AI Agents face issues if directly brute forced with Raw/Unclean data. But this isn’t just a data science problem. It’s a data engineering problem. And the solution lies in structured, governed data management—beginning with a robust medallion architecture. Ref.: Data Intelligence End-to-End with Azure Databricks and Microsoft Fabric | Microsoft Community Hub Raw → Silver → Gold: The Databricks Way Databricks ML Agents thrive when your data is managed through the medallion architecture, transforming raw chaos into clean, trustworthy features. For those new to Medallion architecture in Databricks, it is a structured data processing framework that progressively improves data quality through bronze (raw), silver (validated), and gold (enriched) layers, enabling scalable and reliable analytics. Raw Layer: Ingest Everything The raw layer is where we land all data, regardless of quality. It’s your unfiltered feed—logs, events, customer input, third-party APIs, CSV dumps, IoT signals, etc. e.g. CloudFronts Case studies as directly fetched from WordPress API This script automates the extraction, transformation, and optional upload of WordPress-based case study content into Azure Blob Storage as well as locally to dbfs of Databricks, making it ready for further processing (e.g., vector databases, AI ingestion, or analytics). What We’ve Done On running the above Raw to Silver Cleaning code in Databricks notebook we get a much formatted, relevant and cleaned fields specific to our requirement In Databricks Unity Catalog → Schema → Tables, it looks something like this: – Silver Layer: Structure and Clean Once ingested, we promote data to the silver layer, where transformation begins. Think of this layer as the data refinery. What happens here: Now we start to analyze trends, infer schemas, and prepare for more active feature generation. Once I have removed noise; I begin to see patterns. This script is part of a data pipeline that transforms unstructured or semi-clean data from a Raw Delta Table (knowledge_base.raw.case_studies) (Actually Silver, as we have already done much of the cleaning part in previous step) into a Gold Delta Table (knowledge_base.gold.case_studies) using Apache Spark. The transformation focuses on HTML cleaning, type parsing, and schema standardization, enabling downstream ML or BI workflow What have we done here ? Start Spark Session Initializes a Spark job using SparkSession, enabling distributed data processing within the Databricks environment. Define UDFs (User-Defined Functions) Read Data from Silver Table Loads structured data from the Delta Table: knowledge_base.raw.case_studies, which acts as the Silver Layer in the medallion architecture. Clean & Normalize Key Columns Write to Gold Table Saves the final transformed DataFrame to the Gold Layer as a Delta Table: knowledge_base.gold.case_studies, using overwrite mode and allowing schema updates. As you can see we have maintained separate schemas for Raw, Silver Gold etc; and at gold we finally managed to get a fully cleaned noiseless data suitable for our requirement. Gold Layer: Ready for ML & BI At the gold layer, data becomes a polished product, curated for specific use cases—ML models, dashboards, reports, or APIs. This is the layer where scale and accuracy become feasible, because it finally has clean, enriched, semantically meaningful data to learn from. Ref.: What is a Medallion Architecture? We can further make it more efficient to fetch with vectorization  Once we reach stage and test again in the Agent Playground, we no longer face the error we had seen previously as now it is easier for the agent to retrieve gold standard vectorized data. Why This Matters for AI at Scale The difference between “good enough” and “state of the art” often hinges on data readiness. Here’s how strong data management impacts real-world outcomes: Without Medallion Architecture With Raw → Silver → Gold Data drift goes undetected Proactive schema monitoring Models degrade silently Continuous feature freshness Expensive debugging cycles Clean lineage via Delta Lake Inconsistent outputs Predictable, testable results (Delta Lake is an open-source storage layer that brings ACID transactions, scalable metadata handling, and unified batch processing to data lakes, enabling reliable analytics on massive datasets.) … Continue reading The Hidden Cost of Bad Data:How Strong Data Management Unlocks Scalable, Accurate AI →

If you’ve worked on Dynamics 365 CRM projects, you know integration isn’t optional—it’s essential. Whether you’re connecting CRM with a legacy ERP, a cloud-based marketing tool, or a SharePoint document library, the way you architect your integrations can make or break performance and maintainability.  Azure Logic Apps makes this easier with its low code interface but using the right pattern matters. In this post, I’ll Walk through seven integration patterns I’ve seen in real projects, explain where they work best, and share some lessons from the field.  Whether you’re building real-time syncs, scheduled data pulls, or hybrid workflows using Azure functions, these patterns will help you design cleaner, smarter solutions.  A Common Real-World Scenario Let’s say you’re asked to sync Project Tasks from Dynamics 365 to an external project management system. The sync needs to be quick, reliable, and avoid sending duplicate data.  You might wonder:  Without a clear integration pattern, you might end up with brittle flows that break silently or overload your system.  Key Integration Patterns (With Real Use Cases)  1. Request-Response Pattern  What it is: A Logic App that waits for a request (usually via HTTP), processes it, and sends back a response.  Use Case: You’re building a web or mobile app that pulls data from CRM in real time—like showing a customer’s recent orders.  How it works:  Why use it:  Key Considerations:  2. Fire-and-Forget Pattern What it is: CRM pushes data to a Logic App when something happens. The Logic App does the work—but no one waits for confirmation.  Use Case: When a case is closed in CRM, you archive the data to SQL or notify another system via email.  How it works:  Why use it:  Keep users moving—no delays.  Great for logging, alerts, or downstream updates  Key Considerations:  Silent failures—make sure you’re logging errors or using retries  3. Scheduled Sync (Polling) What it is: A Logic App that runs on a fixed schedule and pulls new/updated records using filters.  Use Case: Every 30 minutes, sync new Opportunities from CRM to SAP.  How it works:  Why use it:  Key Considerations:  4. Event-Driven Pattern (Webhooks)  What it is: CRM triggers a webhook (HTTP call) when something happens. A Logic App or Azure Function listens and acts.  Use Case: When a Project Task is updated, push that data to another system like MS Project or Jira.  How it works:  Why use it:  Key Considerations:  5. Queue-Based Pattern  What it is: Messages are pushed to a queue (like Azure Service Bus), and Logic Apps process them asynchronously.  Use Case: CRM pushes lead data to a queue, and Logic Apps handle them one by one to update different downstream systems (email marketing, analytics, etc.)  How it works:  Why use it:  Key Considerations:  6. Blob-Driven Pattern (File-Based Integration)  What it is: Logic App watches a Blob container or SFTP location for new files (CSV, Excel), parses them, and updates CRM.  Use Case: An external system sends daily contact updates via CSV to a storage account. Logic App reads and applies updates to CRM.  How it works:  Why use it:  Key Considerations:  7. Hybrid Pattern (Logic Apps + Azure Functions)  What it is: Logic App does the orchestration, while Azure Function handles complex logic that’s hard to do with built-in connectors.  Use Case: You need to calculate dynamic pricing or apply business rules before pushing data to ERP.  How it works:  Why use it:  Key Considerations:  Implementation Tips & Best Practices  Area  Recommendation  Security  Use managed identity, OAuth, and Key Vault for secrets  Error Handling  Use “Scope” + “Run After” for retries and graceful failure responses  Idempotency  Track processed IDs or timestamps to avoid duplicate processing  Logging  Push important logs to Application Insights or a centralized SQL log  Scaling  Prefer event/queue-based patterns for large volumes  Monitoring  Use Logic App’s run history + Azure Monitor + alerts for proactive detection  Tools & Technologies Used Common Architectures You’ll often see combinations of these patterns in real-world systems. For example:  To conclude, integration isn’t just about wiring up connectors, it’s about designing flows that are reliable, scalable, and easy to maintain.  These seven patterns are ones I’ve personally used (and reused!) across projects. Pick the right one for your scenario, and you’ll save yourself and your team countless hours in debugging and rework.  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.

Automation in Microsoft Dynamics 365 Business Central can drastically improve efficiency, especially when scheduled jobs run without manual intervention. But occasionally jobs fail due to temporary issues like network glitches or locked records. Setting the Maximum number of attempts ensures the system retries automatically, reducing failures and improving reliability. Steps to Optimize Job Automation 1. Navigate to Job Queue Entries Go to Search (Tell Me) → type Job Queue Entries → open the page. 2. Select or Create Your Job Either choose an existing job queue entry or create a new one for your automated task. 3. Set Maximum No. of Attempts In the Maximum No. of Attempts field, enter the number of retries you want (e.g., 3–5 attempts). This tells BC to retry automatically if the job fails. 4. Schedule the Job Define the Earliest Start Date/Time and Recurring Frequency if applicable. 5.Enable the Job Queue Make sure the Job Queue is On and your job is set to Ready. 6.Monitor and Adjust Review Job Queue Log Entries regularly. Pro Tips -Keep your jobs small and modular for faster retries. -Avoid setting attempts too high it may overload the system. -Combine retries with proper error handling in the code or process. To conclude, by leveraging the Maximum No. of Attempts feature in Business Central, you can make your job automation more resilient, reduce downtime, and ensure business processes run smoothly without constant supervision. 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.