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

Many growing companies work with multiple legal entities. Each month, they exchange bills, services, or goods between companies. Doing this manually often leads to delays and mistakes. Microsoft Dynamics 365 Business Central helps fix that through Intercompany Automation. This feature lets you post one entry in a company, and the system automatically creates the same transaction in the other company. Let’s see how you can set it up and how it works with a real example. Why Intercompany Automation Matters If two companies within the same group trade with each other, both sides must record the same transaction, one as a sale and one as a purchase. When done manually, the process is slow and can cause mismatched balances. Automating it in Business Central saves time, reduces errors, and keeps both companies’ financials in sync automatically. Step 1: Setup Process 1. Turn on Intercompany Feature Open Business Central and go to the Intercompany Setup page. Turn on the setting that allows the company to act as an Intercompany Partner. 2. Add Intercompany Partners Add all related companies as partners. For example, if you have Company A and Company B, set up each as a partner inside the other. 3. Map the Chart of Accounts Make sure both companies use accounts that match in purpose. Example: 4. Create Intercompany Customer and Vendor 5. Create Intercompany Journal Templates Use IC General Journals to record shared expenses or income regularly. You can automate them using job queues or recurring batches. Step 2: Automation in Action Once the setup is complete, every time a user posts a sales invoice or general journal related to an Intercompany Customer or Vendor, Business Central creates a matching entry in the partner company. Both companies can see these transactions in their IC Inbox and Outbox. You can even add automation rules to post them automatically without approval if desired. Step 3: Use Case – Monthly IT Service Charges Scenario: The Head Office provides IT services to a Subsidiary every month for ₹1,00,000. Steps: Both companies now have matching entries, one as income and one as expense, without any manual adjustments. Result: Transactions are accurate, time is saved, and your accountants can focus on analysis rather than repetitive posting. To conclude, automating intercompany postings in Business Central makes financial management simple and reliable. Once configured, it ensures transparency, reduces errors, and speeds up reporting. I Hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com.

If you’ve worked with data in Business Central, you’ve undoubtedly used the DELETE or DELETEALL commands. They get the job done, but when you’re dealing with massive datasets ike clearing out old ledger entries, archived sales orders, or temporary import tables they can feel painfully slow. There’s a better, faster way. Let’s talk about the TRUNCATE TABLE command, the unsung hero of high-performance data purging. What is TRUNCATE TABLE? In simple terms, TRUNCATE TABLE is a SQL command that instantly removes all rows from a table. Unlike DELETE, it doesn’t log individual row deletions in the transaction log. It’s a bulk operation that de-allocates the data pages used by the table, which is why it’s so incredibly fast. In the context of Business Central, you can execute this command directly from an AL codeunit. Yes, it’s that simple. Calling the .TruncateTable() method on a record variable targets its corresponding table and empties it completely. TRUNCATE TABLE vs. DELETE/DELETEALL: What’s the Difference? This is the crucial part. Choosing the right tool is key to performance and data integrity. Feature TRUNCATE TABLE DELETE / DELETEALL Performance Extremely Fast. Operates at the data page level. Slow. Logs every single row deletion individually. Transaction Log Minimal logging. Fills the log with a single “deallocated page” entry. Heavy logging. Fills the log with an entry for every row deleted. Where Clause No. It’s all or nothing. You cannot add a filter. Yes. You can use SETFILTER or SETRANGE to delete specific records. Table Triggers Does not fire. No OnBeforeDelete or OnAfterDelete triggers are executed. Fires for each row that is deleted. Referential Integrity Can fail if a FOREIGN KEY constraint exists. Respects and checks constraints, potentially failing on related records. Resets Identity Seed Yes. The next record inserted will have the first ID in the series (e.g., 1). No. The identity seed continues from where it left off. Transaction Rollback Can be rolled back if used inside a transaction, but it’s still minimally logged. Can be rolled back, as all individual deletions are logged. When Should You Use TRUNCATE TABLE? Given its power and limitations, TRUNCATE TABLE is perfect for specific scenarios: A Real-World Business Central Example Imagine you have a custom “Data Import Staging” table. Every night, a job imports thousands of items from an external system. The first step is always to clear the staging area. The Slow Way (using DELETEALL): The Blazing-Fast Way (using TRUNCATE TABLE): The performance difference can be staggering, turning a minutes-long operation into one that completes in under a second. Critical Warnings and Best Practices With great power comes great responsibility. The limitations of TRUNCATE TABLE are not just footnotes—they are critical considerations. NO FILTERS! This is the biggest “gotcha.” You cannot use SETRANGE before calling TruncateTable(). The method will ignore any filters and always delete everything. Double and triple-check your code to ensure you are targeting the correct table. Bypasses Business Logic: Because table triggers do not fire, any essential business logic in the OnDelete trigger will be skipped. Do not use TRUNCATE TABLE on tables where the delete triggers perform critical actions (e.g., posting, ledger entry creation, validation). Using it on main transaction tables like “G/L Entry” or “Sales Line” is almost always a bad idea. Foreign Key Constraints: If another table has a foreign key constraint pointing to the table you’re trying to truncate, the command will fail with an error. DELETEALL would also fail in this case, but the error message might be different. To Conclude, TRUNCATE TABLE is a powerful tool that should be in every Business Central developer’s arsenal. When used correctly, it can dramatically improve the performance of data maintenance tasks. The Rule of Thumb: Use DELETEALL when you need to respect business logic, delete specific records, or work with tables that have complex relationships. Use TRUNCATE TABLE when you need to quickly and completely empty a large, standalone table where bypassing business logic is safe and acceptable. Embrace TRUNCATE TABLE for the right jobs and watch your large-scale data operations fly. Reference: https://yzhums.com/67343/, 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

The landscape of digital transformation has never been more complex. Rapid market shifts, rising customer demands, and tightening budgets have made technology decisions more consequential than ever. The challenge isn’t adopting new tools it’s leading transformation by ensuring that every investment is grounded in clarity, alignment, and predictability. At CloudFront’s, we understand this. That’s why our Business Assessment Engagement model has become a proven first step toward successful, low-risk technology implementations. What Is a Business Assessment? A Business Assessment is a structured, short-term engagement conducted before signing a full implementation Statement of Work (SoW). It is designed to create complete visibility into your current business processes, desired future state, and the potential risks that could impact your project. Typically spanning 3 – 4 weeks, this engagement brings together functional and technical stakeholders from both your organization and CloudFront’s. Whenever feasible, we conduct this assessment onsite, ensuring close collaboration and a deep understanding of your business landscape. During this engagement, our experts: The result is a detailed Business Requirements Study (BRS) a comprehensive document that translates assessment insights into an actionable implementation roadmap. This BRS becomes the foundation for a precise and mutually agreed Statement of Work, ensuring every phase of your digital transformation is built on validated insights and shared understanding. Why a Business Assessment Matters For enterprise technology leaders, the Business Assessment approach delivers tangible benefits: Ultimately, this process transforms uncertainty into informed decision-making, enabling IT leaders to confidently advance from planning to execution. Proven Success with CloudFront’s At CloudFront’s, we’ve seen firsthand how Business Assessment engagements set the stage for successful digital transformations. Clients who adopt this model enter implementation phases with greater predictability, stronger governance, and renewed confidence in both the technology and the partnership driving it. Recently, we partnered with one of the world’s largest U.S. based commercial vehicle manufacturers to conduct an onsite Business Requirements Study (BRS). Our team worked closely with their stakeholders to map existing systems and design a strategic roadmap for migration to Microsoft Dynamics 365 Supply Chain Management (SCM). Following the successful completion of the BRS, we are now leading Phase 1, enabling their inventory, advanced warehouse, and procurement operations to establish a strong operational foundation. In Phase 2, we will enable master planning, production, and quality management to deliver end-to-end operational efficiency, ensuring a seamless and future-ready digital ecosystem. Our clients consistently tell us that this approach not only de-risks their investment but also enhances alignment between business and IT, a crucial factor in any transformation journey. To conclude, in today’s unpredictable business landscape, a well-executed Business Assessment isn’t just a preliminary step, it’s a strategic imperative. By partnering with CloudFront’s for a Business Assessment, you’re not committing to uncertainty; you’re investing in clarity, alignment, and long-term success. If your organization is planning a digital transformation initiative, start with a Business Assessment Engagement and move forward with the confidence of knowing your path is mapped, risks are managed, and success is measurable. Ready to move from uncertainty to clarity?Connect with CloudFront’s at transform@cloudfronts.com to schedule a Business Assessment Engagement and gain a clear, actionable roadmap for your next digital transformation. Contact Us to start your assessment today.

In conversations with Business Central customers, one recurring theme stands out: permissions remain the single biggest operational pain point. For too long, organizations have taken the path of least resistance: The outcome? A fragile balance where security is compromised, efficiency is slowed, and compliance becomes an afterthought. But permissions should not be a roadblock. They should be a strategic enabler. Moving Beyond “Access” to “Enablement” Business Central has quietly matured its security model. The challenge is not capability, but mindset. Organizations must move from access as convenience to permissions as governance. Here are three levers that shift permissions from problem to advantage: Why This Matters for Leaders Strong permissions are not an IT housekeeping task—they are a strategic safeguard: The Leadership Imperative To conclude, Business Central leaders must stop viewing permissions as a technical nuisance. In an era of increasing scrutiny on data security and compliance, permission architecture is leadership architecture. The organizations that invest in this today will not only reduce risk but also unlock smoother onboarding, faster adoption, and a culture of accountability. If you need further assistance or have specific questions about your ERP setup, feel free to reach out for personalized guidance. 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. It’s time to replace the culture of SUPER users with a culture of super governance.

In Microsoft Dynamics 365 Business Central, users frequently need to generate and review Purchase Order (PO) documents. Traditionally, this process involved downloading PDF files locally and then opening them with an external PDF viewer. While functional, this workflow can be inefficient, especially when reviewing multiple purchase orders. With recent enhancements in the AL language and web client capabilities, it is now possible to preview PDF documents directly within the browser, eliminating unnecessary steps and improving user experience. Additionally, Business Central continues to support direct file downloads for scenarios where saving a copy locally is required. This article presents a customization to the Purchase Order List page, allowing users to select multiple purchase orders and either preview or download their PDF documents using AL code. Functional Overview The proposed solution introduces a new action on the Purchase Order List page titled “Preview Selected Purchase Orders”. This action performs the following tasks: Role of Report Selections Report Selections play a vital role in ensuring flexibility and modularity. Instead of hardcoding specific report IDs, the system determines the report to be used for each Purchase Order based on vendor configuration. Example AL Snippet: This method respects configurations made in the Report Selection – Purchase page, allowing different vendors to use different report formats or layouts for the same document type. AL Implementation Below is the complete AL code for the pageextension object: File Handling Options: Preview vs Download Depending on business needs, developers can choose between two methods: 1. File.ViewFromStream 2. File.DownloadFromStream Output This customization provides two ways to handle PDF outputs for Purchase Orders: 1. For a Single Selected Document When a single purchase order is selected and the action is triggered: 2. For Multiple Selected Documents (Merged into One PDF) Business Benefits To Conclude, by leveraging AL capabilities such as Report Selections, Temp Blob, and the File data type methods, developers can significantly enhance document handling processes in Microsoft Dynamics 365 Business Central. Offering both in-browser preview and direct download options provides users with flexibility and improves overall productivity. This customization is a practical example of how small enhancements can deliver substantial value in day-to-day business operations. 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 many businesses, especially those involved in international trade, it’s common to handle both import and export transactions. To keep records clean and compliant, companies often want to assign separate posting number series for exports and imports in Microsoft Dynamics 365 Business Central. In this guide, we’ll walk you through how to configure and automate posting number series selection based on the sales order type Export or Import helping your business maintain accurate and organized documentation. Business Scenario: A customer requires that: When a Sales Order is created for EXPORT, a specific Export Posting No. Series should be applied. When a Sales Order is created for IMPORT, a different Import Posting No. Series should be used. This allows for easy tracking, filtering, and compliance with customs or internal auditing processes. Steps to achieve goal Step 1: Create Two Posting Number SeriesGo to “Number Series”. Create two new series: SO-EXP-2025 → for Export SO-IMP-2025 → for Import Set appropriate starting numbers, prefixes, and increment-by values. And then create another No series for Sales Order relationship S-ORD-R add above no series in relationship in Sales & receivable setup add the new S-ORD-R Step 2: Create a field add field in page extension and table extension of No series Line. Step 3: Add Logic in the Sales Order Page ExtensionIn your Sales Order page extension, implement logic to check if the selected No. Series is tagged as “Export”. If so, automatically assign the corresponding value from the “Posted No. Series Code” to the “Posting No. Series” field on the Sales Order. This ensures that when an Export-related number series is used, the correct posting series is set without manual intervention. To conclude, setting different posting number series based on whether a Sales Order is for Export or Import is a simple yet powerful customization in Business Central. With a small extension or logic-based workflow, you can automate this process to enhance control and compliance. 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.