Scheduling meetings manually through emails can be time-consuming and inefficient, especially for organizations that handle frequent customer inquiries and consultations. A Houston-based firm was facing similar challenges, where coordinating appointments required multiple email exchanges, leading to delays and administrative overhead. To address this, we proposed and implemented Microsoft Bookings as an integrated scheduling solution within Microsoft 365. By connecting the booking system directly to their website, customers can now schedule meetings based on real-time staff availability without back-and-forth communication. The solution automatically manages confirmations, calendar updates, and Microsoft Teams meeting creation, ensuring a seamless, professional, and fully automated booking experience for both customers and internal teams. In this blog, I’ll walk you through how we configured Microsoft Bookings and how it can be used to enable effortless appointment scheduling. By the end of this guide, you’ll understand: Let’s get started. What is Microsoft Bookings? Microsoft Bookings is a scheduling solution available within Microsoft 365 that allows users to book meetings based on real-time calendar availability. It automatically: This eliminates manual coordination and ensures a consistent booking experience. How Microsoft Bookings Works Microsoft Bookings connects a public or internal booking page with users’ Microsoft 365 calendars. Here’s the overall process: This ensures a fully automated scheduling experience. Configuration Steps Step 1: Access Microsoft Bookings Step 2: Create a Booking Page This creates the base structure of your booking system. Step 3: Add Staff Members This ensures meetings are assigned correctly and availability is synced with their calendars. Step 4: Configure Services Next, configure the service being offered. You can: Enabling Teams integration ensures every booking automatically includes a meeting link. Step 5: Define Booking Permissions Choose who can access your booking page: For our implementation, selecting Anyone made the booking page publicly accessible. Step 6: Create the Booking Page Step 7: Share and Use the Booking Page URL Once created, you can: This makes appointment booking simple and accessible. Benefits of Microsoft Bookings Implementation Implementing Microsoft Bookings provides a seamless and automated way to manage appointments. From configuration to sharing the booking page, the entire process is straightforward and efficient. With just a few setup steps, organizations can enable customers and internal users to schedule meetings based on real-time availability, without manual coordination. If you’re looking to simplify your scheduling process and improve efficiency, Microsoft Bookings is a powerful solution within Microsoft 365. If you found this blog useful and would like to discuss how Microsoft Bookings can be implemented for your organization, feel free to reach out to us. 📩 transform@cloudFronts.com

In Microsoft Dynamics 365 CRM, every Case (Incident) record comes with a default Ticket Number. Microsoft generates it automatically, and while that’s fine for basic tracking, it usually doesn’t survive first contact with real business requirements. Users want meaningful Case IDs—something that actually tells them what kind of case this is, what service it belongs to, and where it came from. Unfortunately, since Ticket Number (ticketnumber) is a Microsoft-managed field, you can’t just slap a custom format on it using configuration alone. That’s exactly where a Pre-Operation plugin comes in. This blog walks through a real production use case where we customize the default Case ID format without breaking Microsoft’s auto-numbering, and without creating race conditions or duplicate numbers. Use Case Table: Case (Incident) Field: Ticket Number (ticketnumber) Requirement: Execution: Why Pre-Operation Microsoft generates the Ticket Number before the Create operation completes. In Pre-Operation, we can: This gives us: The Custom Ticket Number Format The final Case ID looks like this: Example: Plugin Logic Overview Here’s what the plugin does, step by step: The Plugin Code Plugin Registration Details Message: Create Primary Entity: Case (incident) Stage: Pre-Operation Mode: Synchronous Filtering Attributes: Not required. To conclude, customizing a Microsoft-managed field like Ticket Number often sounds risky, but as you’ve seen, it doesn’t have to be. By letting Dynamics 365 generate the number first and then reshaping it in a pre-Operation plugin, you get the best of both worlds. 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

Dynamics 365 CRM plugins are a powerful way to enforce business logic on the server but choosing when and how to use them is just as important as writing the code itself. In one implementation for a Netherlands-based sustainability certification organization, the client needed their certification journey to begin with a custom application entity while still ensuring that applicant and company details were captured as leads for downstream sales and engagement processes. This blog explores how a server-side plugin was used to bridge that gap, reliably creating and associating lead records at runtime while keeping the solution independent of UI behavior and future integrations. In this scenario, the certification application was the starting point of the business process, but sales and engagement still needed to operate on leads. Simply storing the same information in one place wasn’t enough, the system needed a reliable way to translate an application into a lead at the right moment, every time. That transformation logic is neither data storage nor UI behavior; its core business process logic, which is why it was implemented using a Dynamics 365 plugin. Scenario: Certification Application Not Flowing into Sales Users reported the following challenge: a. A user submits or creates a Certification Applicationb. Applicant and company details are captured on a custom entityc. Sales teams expect a Lead to be created for follow-upd. No Lead exists unless created manually or through inconsistent automatione. Application and sales data become disconnected This breaks the intended business flow, as certification teams and sales teams end up working in parallel systems without a reliable link between applications and leads. Possible Solution: Handling Lead Creation Through Manual Processes (Original Approach) Before implementing the plugin, the organization attempted to manage lead creation manually or through disconnected automation. How It Worked (Initially) a. A Certification Application was submittedb. Users reviewed the applicationc. Sales team manually created a Lead with applicant/company detailsd. They tried to match accounts/contacts manuallye. Both records remained loosely connected. Why This Might Look Reasonable a. Simple to explain operationallyb. No development effortc. Works as long as users follow the steps perfectly The Hidden Problems 1] Inconsistent Data Entry a. Users forgot to create leadsb. Leads were created with missing fieldsc. Duplicate accounts/contacts were createdd. Sales lost visibility into new certification inquiries 2] Broken Cross-Department Workflow a. Certification team worked in the custom entityb. Sales team worked in Leadsc. No structural linkage existed between the twod. Downstream reporting (pipeline, conversion, source tracking) became unreliable. Workaround to This Approach: Use Server-Side Logic Instead of Manual Steps Practically, the transformation of an application into a lead is business logic, not user behavior. Once that boundary is respected, the solution becomes stable, predictable, and automation-friendly. Practical Solution: A Server-Side Plugin (Improved Approach) Instead of depending on people or scattered automation, the lead is created centrally and automatically through a plugin registered on the Certification Application entity. Why a Plugin? a. Executes consistently regardless of data sourceb. Not tied to form events or UI interactionsc. Can safely check for existing accounts/contactsd. Ensures one source of truth for lead and application linkagee. Works for portal submissions, integrations, and bulk imports This is essential for a client, where applications may originate from multiple channels and must feed accurately into the sales funnel. How the Plugin-Based Solution Works The solution was implemented using a server-side plugin registered on the Certification Application entity. The plugin executes when a new application is created, retrieves the necessary applicant and organization details, performs basic checks for existing accounts and contacts, creates a Lead using the extracted data, and finally links the Lead back to the originating application record. This ensures that every certification application automatically enters the sales pipeline in a consistent and reliable manner. Implementation Steps (For Developers New to Plugins) If you’re new to Dynamics 365 plugins, the implementation followed these core steps: Build and Register the Plugin. Once the plugin logic is implemented, build the project to generate the signed assembly. After a successful build: After registration, every new Certification Application will automatically trigger the plugin, ensuring that a Lead is created and linked without any manual intervention. a. Open the Plugin Registration Toolb. Connect to the target Dynamics 365 environmentc. Register the compiled assemblyd. Register the plugin step on the Create message of the Certification Application entitye. Configure the execution stage (typically post-operation) and execution mode (Synchronous or Asynchronous, depending on business needs) To encapsulate, this solution shows why server-side plugins are the right place for core business logic in Dynamics 365. By automatically creating and linking a Lead when a Certification Application is created, the organization removed manual steps, prevented data inconsistencies, and ensured that every application reliably flowed into the sales pipeline. 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 Part 1, we built a simple MCP server in TypeScript that exposed a “getWeather” tool. Now, let’s take the next step: connecting our MCP server to Microsoft Copilot Studio so that Copilot agents can call it directly. This section will cover: Step 1 — Publish Your MCP Server to Azure To make your MCP server accessible to Copilot Studio, you’ll need to host it online. There are multiple ways to deploy it — Azure App Service, Azure Container Apps, or even Azure Functions if you prefer serverless. For example, using Azure App Service: Test using curl to ensure it responds with MCP-compatible JSON: Step 2 — Create a New Copilot in Copilot Studio Step 3 — Add Knowledge Sources Optionally, you can enrich your Copilot by adding: This gives your Copilot a baseline knowledge to answer broader questions, while the MCP server will handle specific tasks (like fetching live weather data). Step 4 — Create a Custom Connector in Dataverse To let Copilot Studio talk to our MCP server, we need a custom connector inside Dataverse/CRM. Step 5 — Add the Custom Connector to Copilot Studio you’ll see the MCP server in your Tools section of copilot. To test the setup, let’s ask Copilot: “What’s the current weather in Mumbai?” On the first attempt, Copilot will prompt you to establish a connection. Simply open the Connection Manager, click Connect, and authorize the link to your MCP server. Once connected, Copilot will fetch the live weather details for Mumbai directly from your MCP server. and click retry on the Test window of your copilot. And just like that, your MCP server is live and fully integrated. It can now provide real-time weather updates for any city mentioned in your conversation with Copilot. You can try out different variations of questions or phrasings — Copilot will intelligently interpret your request, extract the city name, and seamlessly call the MCP server to deliver accurate weather details. Beyond Weather: Business Integrations The same process works for enterprise systems. For example, instead of getWeather, you could expose: By publishing these tools via MCP, your Copilot becomes a true enterprise assistant, capable of pulling structured business data and triggering workflows on demand. 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.

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 →