Subtitle: Environment movement in Microsoft Dynamics 365 Business Central is not supported across tenants or regions – migration is the only viable approach. Author: Siddhi Patekar · Sr. Functional ConsultantSiddhi specializes in helping organizations transition from manual processes to fully digital systems using Microsoft Dynamics 365. She has worked closely with pharmaceutical manufacturers, service organizations, and the banking sector to design and implement solutions that enhance compliance, improve traceability, and drive operational efficiency. Industry: Cross-industry | Technology: Microsoft Dynamics 365 Business Central | Years of experience: 5 | Certification: MB800 Summary The Core Reality: You Don’t Transfer – You Migrate Most organizations using Microsoft Dynamics 365 Business Central eventually ask:“Can we move our environment to another tenant or region?” The answer is simple: No. This is not a limitation of configuration – it is a platform-level restriction enforced by Microsoft. Why this restriction exists: The one rule to remember: What You Cannot Do Organizations often attempt shortcuts that are simply not supported: These are not edge cases – they are hard platform constraints. What Actually Works: The Only Supported Approach The only viable method is: Recreate + Migrate A successful migration typically follows this structure: This is not a lift-and-shift – it is a controlled rebuild. What Always Breaks (Be Prepared) Every migration involves rework. The most common areas impacted: Planning for this upfront avoids delays later. Where “Transfer Environment” Actually Helps There is often confusion around this feature. Important clarification: It is useful for internal environment movement – but not for restructuring tenants. Real-World Scenario: Tenant Consolidation for Integration Situation A company was running: This resulted in: Project Goals What Should Be Done Instead A structured approach ensures success: 1. Align Tenant Strategy Early Define a single primary tenant for all business applications. 2. Plan Data Migration Properly 3. Rebuild Integrations the Right Way 4. Re-evaluate Licensing Migration is the best time to optimize licensing before renewal cycles. Business Impact Following this approach, organizations typically achieve: Frequently Asked Questions Can Business Central environments be transferred across tenants? No. Microsoft does not support cross-tenant environment transfers. Migration is the only option. Is there any way to retain integrations during migration? No. Integrations must be reconfigured in the new tenant to ensure stability and compliance. Does Microsoft provide a direct migration tool? No single tool handles full migration. A combination of RapidStart, APIs, and manual configuration is required. Conclusion The biggest misconception in Microsoft Dynamics 365 Business Central is assuming environments can be moved. They cannot. The real decision is not whether to migrate- it is when and how well you plan it. Organizations that define their tenant strategy early avoid: Those that delay the decision often face migration under pressure – when it becomes unavoidable. Thinking about restructuring your Business Central environment or tenant strategy?Plan it early, design it right, and treat migration as a strategic initiative – not a technical task. Connect with CloudFront’s to get started at transform@cloudfonts.com.

Summary A non-profit sustainability certification organization reduced CRM complexity by replacing multiple custom entities with a JSON-based data structure in Microsoft Dynamics 365 CRM. CloudFronts implemented a custom HTML interface to dynamically render input fields and manage document uploads within a single, unified UI. The approach eliminated repeated schema changes, reduced admin overhead, and enabled faster adaptation to evolving certification requirements. Business impact: Reduced CRM customization overhead, accelerated onboarding of new certification types, and a more maintainable solution that scales without structural rework. About the Customer The customer is a non-profit organization focused on sustainability certification across industries. They operate across multiple certification programs, each with distinct documentation requirements, input fields, and approval workflows. Their team relies on Microsoft Dynamics 365 CRM as the central platform for managing certification applications, applicant data, and compliance records. The Challenge Microsoft Dynamics 365 CRM is built for structured data — but not all business processes follow fixed structures. The organization managed several certification programs, each requiring different sets of input fields, document uploads, and validation logic. Initially, each new certification type was handled by creating a new custom entity or modifying existing ones to accommodate the required fields. While this worked for a small number of programs, the approach quickly revealed significant limitations: Schema rigidity: Every time a new certification type was introduced, or an existing one updated, the CRM schema had to be modified. This meant new fields, new relationships, and repeated deployment cycles. Administrative overhead: Each schema change required coordination between developers and CRM administrators, creating delays and dependency bottlenecks. Inconsistent UI experience: With different entities handling different certification types, the user interface lacked consistency. Applicants and internal users faced a fragmented experience depending on which program they were working in. Scalability ceiling: The entity-per-program model was not designed to scale. Adding a tenth or fifteenth certification type would exponentially increase the complexity of the CRM data model. Document management friction: Handling document uploads across multiple entities was cumbersome, with no unified approach to tracking submission status or linking files to the correct certification record. The organization needed a solution that could accommodate evolving certification structures without requiring constant schema modifications or developer intervention. The Solution CloudFronts redesigned the data architecture by replacing the multi-entity model with a JSON-based structure stored within Dynamics 365 CRM, paired with a custom HTML interface to dynamically render the appropriate fields and manage document workflows. Technologies Used Microsoft Dynamics 365 CRM, Core platform for certification records, applicant data, and workflow management JSON, Flexible data structure for storing dynamic certification inputs within a single CRM field Custom HTML with JavaScript, Dynamic front-end interface rendered within the CRM form, replacing static entity-based layouts Power Automate, Supporting workflows for notifications, approvals, and document status updates What CloudFronts Configured Rather than creating a separate entity for each certification type, CloudFronts introduced a single Certification Application entity with a dedicated JSON field to store all variable inputs. A configuration-driven approach was used, each certification type is defined by a schema that specifies which fields to show, what validations to apply, and which documents are required. The custom HTML interface reads this configuration at runtime and dynamically renders the correct form, no code changes required when a new certification type is added or an existing one is modified. The same interface handles document uploads, linking each file to its corresponding certification record and tracking submission status in real time. CloudFronts also implemented role-based visibility within the HTML component, ensuring that internal reviewers, applicants, and administrators each see only the sections relevant to their function. Business Impact Metric Before After Adding a new certification type Requires schema changes and deployment Configuration update only UI consistency Fragmented across entities Unified interface for all programs Developer dependency High, every change needed development effort Low, administrators manage configurations Document tracking Manual, per entity Centralized and automated CRM data model complexity Growing with each program Stable and maintainable The organization can now onboard new certification programs in a fraction of the time, without touching the underlying CRM schema. Internal teams manage certification configurations independently, and the development team focuses on feature improvements rather than reactive schema maintenance. Frequently Asked Questions When should I use JSON instead of CRM entities? JSON is a strong fit when input structures vary frequently, differ across record types, or are driven by business rules that change regularly. If your data model is stable and relational, entities remain the better choice. Is it possible to query or filter on JSON data in CRM? Direct filtering on JSON fields in Dynamics 365 is limited. CloudFronts structured the solution so that key filterable attributes, such as certification type, status, and applicant ID, remain as standard CRM fields, while the variable payload lives in JSON. Does the custom HTML approach work on mobile? Yes. The HTML web resource is built to be responsive and functions within the Dynamics 365 mobile app, though optimal use is on desktop given the complexity of certification forms. Can this approach support approval workflows? Yes. Power Automate workflows trigger based on standard CRM field changes, such as status updates, and do not depend on the JSON structure, keeping workflow logic clean and maintainable. Conclusion Not every data problem in CRM needs a new entity. When business requirements are variable and evolving, as they often are in certification, compliance, and document-heavy workflows, a rigid entity model can become a liability rather than an asset. By combining JSON-based storage with a dynamic HTML interface, CloudFronts helped this organization build a CRM solution that adapts to change without requiring structural rework. The result is a leaner data model, a more consistent user experience, and a team that can move faster because they are no longer dependent on developer cycles for every process update. Sometimes the best CRM architecture is the one that knows when not to add more to the schema. We hope you found this article useful. If you would like to explore how AI-powered customer service can improve your support … Continue reading Stop Creating Entities: Simplifying CRM with JSON and Custom HTML for a Sustainability Certification Non-Profit in the Netherlands →

Summary In one of our recent client engagements for a service company based in Africa, we observed that prior-year transactions appearing in current-year bank reconciliation in Microsoft Dynamics 365 Business Central caused confusion during financial review and raised concerns about data accuracy. This occurs due to differences between posting date and clearing date and is a normal accounting scenario, not a system issue, as reconciliation is based on open entries until they are cleared and matched with bank statements. “Why is a 2024 entry appearing in reconciliation when the year is already closed?” At first glance, this may seem like a system issue. However, it is actually a fundamental accounting concept that every finance team should understand. Understanding the Scenario Let’s break down the situation: a. A payment (check) was issued on 31-Dec-2024b. The vendor deposited the check in January 2025c. The bank processed the transaction in 2025 During January 2025 reconciliation, the system shows: a. A 2024 ledger entry on the system sideb. A 2025 bank statement line on the bank side This often raises a common concern: “Why is a prior-year transaction still appearing?” The Root Cause – Timing Difference in Accounting This is a classic example of a timing difference in accounting. There are two important dates involved: a. Posting Date (System) – The date when the transaction is recorded in Business Central (31-Dec-2024)b. Clearing Date (Bank) – The date when the bank processes the transaction (January 2025) These dates do not always match – and that is completely normal in financial operations. How Business Central Handles This Microsoft Dynamics 365 Business Central follows a simple and accurate principle: Bank reconciliation is based on open (unreconciled) entries, not fiscal years. This means: a. Even if the financial year is closedb. Even if financial statements are finalizedc. Any unreconciled bank ledger entry will still appear The 2024 transaction appears in the January 2025 reconciliation because: a. It was posted in 2024b. It was not cleared by the bank at that timec. It remained open in the system Once the bank processes it in 2025, Business Central correctly includes it in the reconciliation. The Solution – Simple and Straightforward There are no error and no correction required. The correct approach is: a. Match the 2024 ledger entry with the 2025 bank statement lineb. Once matched, the entry is marked as reconciledc. It will no longer appear in future reconciliations Key Takeaway Bank reconciliation is not about when a transaction is recorded – it is about when it is cleared. Understanding this distinction helps finance teams: a. Avoid unnecessary confusionb. Improve reconciliation accuracyc. Ensure smoother financial operations in Business Central To conclude, seeing prior-year entries during reconciliation in Microsoft Dynamics 365 Business Central is completely normal and expected in scenarios involving timing differences. By understanding how posting dates and clearing dates interact, organizations can confidently manage reconciliations without misinterpreting system behavior. If you are implementing or optimizing bank reconciliation in Business Central and want more clarity in your finance processes, feel free to reach out to us at transform@cloudfonts.com. We have helped multiple organizations streamline exactly these scenarios.

In global implementations of Microsoft Dynamics 365 Business Central, reports are consumed by users across multiple regions. While the underlying data remains the same, the way it is presented—especially numbers, dates, and currency-must adapt to regional expectations. A common mistake developers make is focusing only on translations while ignoring regional formatting differences. This often results in reports where values appear correct but are interpreted incorrectly due to formatting. This blog explains how to dynamically control both language and format region in RDLC reports using AL, ensuring accurate and user-friendly reporting across regions. What You Will Learn The Report Example Below is a working example where the report dynamically sets language and formatting before execution: report 50121 “Test Multilingual Report”{    Caption = ‘Test Multilingual Report’;    UsageCategory = ReportsAndAnalysis;    ApplicationArea = All;    DefaultLayout = RDLC;    RDLCLayout = ‘./Report Layouts/TEstrepo.rdl’; dataset    {        dataitem(PurchaseHeader; “Purchase Header”)        {            column(Customer_No; “Buy-from Vendor No.”) { }            column(Customer_Name; “Buy-from Vendor Name”) { }            column(Balance_LCY; Amount) { }        }    } trigger OnPreReport()    var        LanguageMgt: Codeunit Language;        VendorRec: Record Vendor;    begin        if VendorRec.Get(PurchaseHeader.”Buy-from Vendor No.”) then begin            CurrReport.Language :=                LanguageMgt.GetLanguageIdOrDefault(VendorRec.”Language Code”); CurrReport.FormatRegion :=                LanguageMgt.GetFormatRegionOrDefault(VendorRec.”Format Region”);        end;    end;} What This Code Actually Does Before the report starts rendering, the OnPreReport trigger executes. a. CurrReport.Language sets the language used for captions and labels in the report b. CurrReport.FormatRegion defines how numbers, dates, and currency values are formatted The key point is that these values are applied at runtime, meaning the same report behaves differently depending on the data it processes. Why This Matters Consider the same numeric value: a. In US format: 1,234.56 b. In French format: 1.234,56 If a report shows the wrong format, users may misread values. In financial documents, this is not just a cosmetic issue-it can lead to real errors. By setting FormatRegion, you ensure that: a. Decimal separators are correct b. Thousand separators follow regional standard c. Currency formatting aligns with expectations Best Practices for RDLC Reports in Business Central Common Mistake to Avoid Avoid hardcoded expressions like: =Format(Fields!Balance_LCY.Value, “#,##0.00”) This overrides regional settings and prevents dynamic formatting. Why This Matters for Global Implementations Accurate localization ensures: Final Thoughts Multilingual reporting in Microsoft Dynamics 365 Business Central is not just about translating text. True localization means presenting data in a way that aligns with regional expectations. By dynamically setting both language and format region using AL, you can build scalable, globally adaptable reports without increasing RDLC complexity. I hope you found this blog useful. If you would like to discuss anything further, feel free to reach out to us at transform@cloudfronts.com.

Summary RDLC expressions may seem like small details, but they have a significant impact on the overall user experience. When building reports in Microsoft Dynamics 365 Business Central: Small refinements in formatting can dramatically elevate the quality of your reports – and the perception of your solution. When building reports in Microsoft Dynamics 365 Business Central, most developers focus heavily on calculations – totals, balances, VAT, charges, and more. But after working across multiple client implementations, one thing becomes very clear: A correctly calculated number is only half the job. How that number is displayed defines how professional your report looks. In this article, we’ll walk through practical RDLC expression patterns that help you: Let’s break it down step by step. The Business Requirement Consider common reports such as: Typically, you calculate totals using: Then the client asks for refinements: These are very common requirements in Indian financial reporting. Example 1: Hide Zero and Format Numbers RDLC Expression =IIf( Fields!BaseAmount.Value + Fields!ServiceCharge.Value + Fields!VATAmount.Value + Fields!TransportCharge.Value = 0, “”, Replace( Format( Fields!BaseAmount.Value + Fields!ServiceCharge.Value + Fields!VATAmount.Value + Fields!TransportCharge.Value, “#,##,##0” ), “,”, ” ” )) What This Does Step 1 – Calculate TotalAdds all amount fields. Step 2 – If Total = 0Returns blank (nothing displayed). Step 3 – If Total ≠ 0 Example Output Actual Value Displayed Value 0 (blank) 5000 5 000 125000 1 25 000 12345678 1 23 45 678 Even a small formatting tweak like this makes reports significantly cleaner. Example 2: Negative Values in Brackets (Accounting Format) Many clients prefer: (50 000) instead of -50 000 RDLC Expression =IIf( Fields!NetAmount.Value = 0, “”, IIf( Fields!NetAmount.Value < 0, “(” & Replace(Format(Abs(Fields!NetAmount.Value), “#,##,##0”), “,”, ” “) & “)”, Replace(Format(Fields!NetAmount.Value, “#,##,##0”), “,”, ” “) )) How It Works Where This Is Useful Example 3: Adding Currency Symbol To include ₹ in your reports: RDLC Expression =IIf( Fields!InvoiceAmount.Value = 0, “”, “₹ ” & Replace( Format(Fields!InvoiceAmount.Value, “#,##,##0”), “,”, ” ” )) Output 250000 → ₹ 2 50 000 Clean. Readable. Professional. Important Note About IIf() A common mistake developers make: IIf() evaluates both TRUE and FALSE conditions. If your fields can be NULL, always handle safely: =IIf(IsNothing(Fields!Amount.Value), 0, Fields!Amount.Value) This prevents runtime errors in production. Best Practice: Keep Expressions Clean If you’re calculating the same total multiple times: Do not repeat logic in RDLC. Instead, create a calculated field in your dataset: TotalAmount = BaseAmount + ServiceCharge + VATAmount + TransportCharge Then simplify your expression: =IIf( Fields!TotalAmount.Value = 0, “”, Replace(Format(Fields!TotalAmount.Value, “#,##,##0”), “,”, ” “)) Benefits Especially important in large Business Central reports. Why This Matters in Real Projects In most implementations, clients rarely complain about incorrect calculations. Instead, they say: These are formatting concerns, not calculation issues. And they are what separate: a. A technically correct reportfromb. A production-ready financial document Key Takeaways I hope you found this blog useful. If you would like to discuss anything further, feel free to reach out to us at transform@cloudfronts.com.

For many organizations using Dynamics GP, job costing has worked for years. Until it doesn’t. As GP approaches end-of-life, companies are being pushed to move – but when job costing is complex, the real question becomes:“Can we just move this to Business Central?” In one of our recent implementations, we learned that the answer is no – not directly. What’s needed is not a migration, but a re-architecture. Let’s look at why, using a smaller, real-life example. The Starting Point: Job Costing That “Works” in GP Our client had been using: The system worked – but it was tightly tied to GP logic and tables. When the move to Business Central was discussed, it became clear that a straight migration would carry old limitations into a new system. Why Business Central Alone Was Not Enough Business Central’s Jobs module is powerful, but it is best suited for simpler job structures. The client needed: Trying to force all of this into standard BC Jobs would have meant heavy customization and long-term maintenance risk. So instead, we rethought the design. The Re-Architecture Approach We clearly separated responsibilities: This allowed us to keep Business Central clean while still supporting real-world job complexity. A Real-Life Example A company wins a project worth $50,000. Job Setup This becomes the baseline for performance tracking. Committed & Actual Costs Now management can compare: Estimate vs Committed vs Actual – and see margin trends early. Forecast Revision Labor is running higher than planned. Instead of changing the original estimate: Change Order The client approves an extra $5,000 scope. Percent of Completion (POC) At month-end: Revenue is recognized based on actual cost incurred. Finance gets accurate revenue, WIP, and margin – without manual adjustments. Why This Architecture Worked This approach delivered: Most importantly, the system supported how people actually run jobs – not just how software expects them to. The Bigger Lesson: Don’t Migrate Problems When moving from Dynamics GP to modern platforms, the goal should not be to recreate the past. It should be to: Job costing is not just a module – it’s a business process. Final Thought If you are planning a transition away from Dynamics GP and rely on job costing, ask yourself: Are we simply moving systems – or are we redesigning job costing for better control and visibility? The answer makes all the difference. I hope you found this blog useful. If you would like to discuss anything further, feel free to reach out to us at transform@cloudfronts.com.

In a recent implementation, we were asked to redesign the purchase process for a client who needed tighter financial control. The requirement was not just about adding approvals. It was about enforcing structure, visibility, and responsibility at every stage of the purchase lifecycle. The client wanted: To achieve this, we implemented a structured workflow in Microsoft Dynamics 365 Business Central, supported by document stage flags and user-based permission control. The Core Challenge Standard approval workflows can handle basic approval logic. However, they do not always provide: We needed a solution that was both technically controlled and functionally transparent. Our Approach We structured the solution around three pillars: 1. Multi-Level Purchase Order Workflow We divided the Purchase Order process into distinct stages: Each stage had a different approver and responsibility. Roles configured: This ensured segregation of duties throughout the process. 2. Stage Identification Using Flags One important improvement we implemented was the use of stage flags on the document. We introduced boolean fields such as: These flags helped us clearly identify: Instead of relying only on the document Status (Open, Released, Pending Approval), we created logical control using these flags. Why was this important? Because standard document status alone cannot differentiate between: By using flags, we achieved: The system logic checked these flags before allowing the Post action. If the required flags were not set, posting was blocked. 3. Restricting Approval Actions via User Setup Another major requirement was controlling who can: To implement this, we extended the User Setup configuration. We added permission indicators such as: In our page action logic, we validated User Setup before enabling the action. If the logged-in user did not have the required permission flag, the action was either: This ensured that only authorized users could trigger workflow transitions. For example: This removed ambiguity and prevented unauthorized workflow manipulation. Handling Rejections and Cancellations We carefully handled rejection scenarios. When a request was: We did not reset the document to Open status. Instead: This design prevented document inconsistency and ensured clean reprocessing. Direct Purchase Invoice Workflow For direct Purchase Invoices (without PO), we implemented the same structure: This ensured that direct invoices did not bypass financial control. How This Resolved the Client’s Concerns Before implementation, the client faced: After implementing: The system now enforces: Most importantly, the solution aligned system behavior with real business hierarchy. Key Takeaways A strong approval workflow is not just about enabling the Approval feature in Business Central. It requires: By combining workflow configuration, document flags, and user-based permission validation, we created a robust and audit-ready purchase control mechanism. Final Thoughts When designing approval workflows, always think beyond basic approval entries. Consider: A well-designed workflow does not slow down operations. It protects them. If you are working on a similar purchase control requirement in Business Central, implementing stage flags along with User Setup-based access control can significantly strengthen your solution. 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.

Summary ERP migration in the pharmaceutical industry is not just a technology upgrade – it is a compliance and quality decision. For highly regulated manufacturers, cloud migration must ensure that regulatory processes, audit trails, and product quality controls remain intact. This article explains why pharmaceutical ERP migrations feel risky, how modern cloud platforms such as Microsoft Dynamics 365 Business Central can strengthen compliance controls, and how a compliance-first migration approach helps pharmaceutical organizations modernize safely. Table of Contents 1. ERP Migration in Pharma Is a Strategic Decision 2. Why Cloud Migrations Feel Risky in Pharma 3. Cloud Does Not Mean Less Control 4. How CloudFronts Approaches Pharma ERP Migration 5. Real-World Example The Outcome ERP Migration in Pharma Is a Strategic Decision In pharmaceuticals, ERP migration is never just an IT upgrade. It is a compliance decision, a quality decision, and often a decision that senior leadership and QA teams will remain accountable for long after the system goes live. When pharmaceutical organizations evaluate cloud ERP adoption, the biggest concern is rarely performance or cost. The real question is: “How do we move to the cloud without putting compliance, audits, or product quality at risk?” The answer lies in one core principle: Compliance-First Migration. Why Cloud Migrations Feel Risky in Pharma Pharmaceutical ERP systems support highly regulated manufacturing processes such as: Batch manufacturing Quality control and approvals Quarantine and release processes Expiry and retesting End-to-end product traceability Because of these requirements, a generic “lift-and-shift” cloud migration approach rarely works in pharmaceutical environments. In pharma operations: A missed QC step is not just a process gap – it becomes a compliance issue. A broken batch trail is not just an inconvenience – it becomes an audit finding. This is why many ERP migrations in the pharmaceutical industry stall or exceed expected timelines. The issue is rarely technology. It is usually the absence of compliance as the foundation of the migration strategy. Cloud Does Not Mean Less Control In pharmaceutical organizations, cloud ERP adoption is sometimes perceived as a loss of control. In reality, modern cloud ERP platforms such as Microsoft Dynamics 365 Business Central can provide stronger compliance capabilities than many legacy on-premise systems when implemented correctly. Cloud ERP systems enable: System-driven audit trails Role-based approvals Enforced quality and release controls End-to-end batch and lot traceability Cloud technology enables compliance – but it does not automatically guarantee it. Compliance ultimately depends on how processes are designed and enforced within the ERP system. Real-World Example One of our customers – an EU-GMP and TGA-approved pharmaceutical company specializing in advanced solutions for pellets, granules, tablets, and capsule manufacturing – modernized its ERP landscape by migrating from Microsoft Dynamics NAV to Microsoft Dynamics 365 Business Central in the cloud. The migration strengthened quality processes, improved operational efficiency, and enhanced regulatory compliance across manufacturing operations. Read the full customer success story here: EU-GMP & TGA Approved Pharmaceutical Company – Dynamics 365 Business Central Case Study The Outcome A compliance-first ERP migration approach builds confidence across the organization. Quality assurance teams trust the system. Operational risks are significantly reduced. Regulatory audits become more predictable and easier to manage. When compliance becomes the foundation of the migration strategy, the cloud stops feeling risky – and starts becoming a reliable platform for growth. Final Thought Pharmaceutical companies do not struggle with cloud ERP migrations because the cloud is unsafe. They struggle when compliance is treated as a phase instead of a foundation. A compliance-first migration does not slow digital transformation – it protects the organization while allowing the cloud to deliver its full value. We hope you found this blog useful. If you would like to discuss ERP modernization for pharmaceutical manufacturing, you can reach out to us at transform@cloudfronts.com.

Security is a critical aspect of any ERP implementation. When integrating Microsoft Dynamics 365 Business Central with external systems such as APIs, payment gateways, banks, IRIS, VAT systems, or third-party services, SSL/TLS certificates play a key role in securing communication. A common misconception is that Business Central itself generates SSL certificates. In reality, Business Central only consumes certificates-the generation and management are handled externally. In this blog, we will cover: What Is an SSL Certificate in Business Central? An SSL (Secure Sockets Layer) / TLS certificate is used to:\Hook: In Business Central, certificates are commonly used for: Important: Business Central does not create SSL certificates—it only stores and uses them. Steps to Generate an SSL Certificate (Self-Signed) This approach is typically used for development or on-premises environments. Step 1: Create a Self‑Signed Certificate in IIS Step 2: Provide Certificate Details Step 3: Copy the Certificate Thumbprint This thumbprint will be required in the next step. Step 4: Configure Certificate Using PowerShell Step 5: Verify Required Properties Ensure all required certificate properties are set to True, including: Step 6: Bind the Certificate in IIS Step 7: Add Certificate Using MMC Step 8: Verify Certificate Installation The certificate should now be visible under: Step 9: Grant Permissions to Business Central Service This ensures the Business Central service can access the certificate. To conclude, SSL certificates are a core security component in Business Central integrations. While Business Central does not generate certificates, it provides robust mechanisms to store and consume certificates securely in both cloud and on‑prem environments. Understanding the generation, configuration, and usage flow ensures secure, compliant, and reliable integrations. 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