How a Leading Professional Services Organization Eliminated Invoice Posting Blind Spots Between D365 Project Operations and Finance Using Custom Business Events Summary In a D365 Project Operations and Finance integrated setup, invoices are created in Project Operations but posted in Finance. Once the accountant posts the invoice in F&O, the project team in PO has no real-time signal that it happened — so they wait for an email, check a report the next day, or chase finance with “has my invoice been posted yet?” CloudFronts solved this with a custom business event in D365 Finance that fires the moment a project invoice proposal is posted. The event triggers an Azure Logic App, which sends the posted status straight back into D365 Project Operations. The project manager sees the update instantly — no emails, no waiting, no manual follow-up. This article walks through the end-to-end flow, the custom business event, the exact JSON payload, what the Logic App receives, and the related scenarios where the same pattern applies. Table of Contents 01 About the Scenario 02 Why This Matters 03 Why We’re Writing This 04 How D365 F&O Business Events Work 05 The Problem 06 The Fix 07 The Payload 08 The Logic App 09 Other Scenarios 10 Conclusion 11 Your Next Step 01 — Context About the Scenario A Familiar PO–FO Integration Gap In a D365 Project Operations and Finance integrated environment, the billing lifecycle is split across two systems. Project invoices originate as invoice proposals in Project Operations, then get reviewed and posted by the accountant in D365 Finance. The posting creates the general ledger entry, records tax and subledger postings, and finalizes the financial transaction. For growing organizations running this dual-system setup, real-time visibility is non-negotiable. As invoice volume climbs and project teams depend on accurate billing status to communicate with clients and forecast cash flow, even a small gap in how posting status is communicated can quietly erode trust between delivery and finance. One of the most common and most overlooked gaps in a PO–FO integration is surprisingly simple: the project team never finds out, in real time, that their invoice was posted in Finance. Have you ever posted a project invoice in F&O, then spent the rest of the day answering “has invoice AC-000051 been posted yet?” messages from project managers? If you’re nodding, this article is for you. Consider this: in most PO–FO implementations, the only way the project team learns an invoice is posted is through a manual email from finance, a next-day report, or a direct follow-up. Multiply that across dozens of invoices every month, and the overhead — and the risk of a missed update — adds up fast. The cumulative effect on billing visibility, client communication, and finance–delivery trust is significant. By the end of this article, you will understand exactly why this happens, how D365 F&O’s Business Events framework can close the gap, and the single pattern that eliminates the problem entirely. 02 — Impact Why This Matters No Real-Time Posting Visibility Creates Real Business Risk When the project team in PO has no real-time way of knowing that their invoice has been financially posted in Finance, it isn’t just an inconvenience. It leads to delayed client communication that chips away at trust, manual follow-ups that clog up both delivery and finance, and worst of all, project managers who stop trusting the system and start maintaining their own spreadsheets of “what’s been posted.” Once that happens, the entire value of a unified PO–FO integration is gone. Dynamics 365 Finance — Custom Business Event Dynamics 365 Finance — Project Invoice Proposal Posting 03 — Our Perspective Why We’re Writing This A Pattern We See Across D365 PO–FO Integrations At CloudFronts, we’ve implemented and supported Dynamics 365 Project Operations and Finance integrations across professional services, engineering, and project-based organizations. This specific issue — the project team being left blind to invoice posting in Finance — has come up in nearly every engagement where invoices originate in PO and are posted in F&O. We’ve seen the pattern, diagnosed the root cause repeatedly, and built the automation to prevent it. This article distils that experience into something actionable. 04 — The Flow How D365 F&O Business Events Work The Flow: F&O → Business Event → Logic App → Project Operations The integration is straightforward. Four things happen in sequence: Step What Happens Detail 1 Invoice is Posted in D365 Finance The project invoice proposal — which originates from D365 Project Operations — is reviewed and posted by the accountant in D365 Finance. The posting creates the GL entry, records tax and subledger postings, and finalizes the financial transaction. 2 Custom Business Event Fires The moment the posting completes, our custom business event (CFProjectInvoiceProposalUpdatedBusinessEvent) fires automatically. It sends a lightweight JSON payload containing the ProposalId, ProjectContractId, Currency, Company, and event timestamp to the configured endpoint. 3 Logic App Receives and Processes The Azure Logic App (FO-PO-Integration-Invoice-Confirmation) is triggered instantly. It receives the payload, extracts the relevant fields, and executes the configured workflow — updating the invoice status in Project Operations and notifying stakeholders. 4 Status Updated in D365 PO The Logic App calls back into D365 Project Operations and updates the invoice record with the “Posted” status. The project manager sees this immediately in PO without any manual intervention. The entire sequence — from the accountant clicking Post in Finance to the status appearing in Project Operations — takes less than a second. 05 — The Gap The Problem The Project Team Is Left in the Dark Here’s how the issue plays out. A project invoice proposal is created and sent from D365 Project Operations to Finance for posting. The accountant reviews and posts it in D365 F&O. The financial transaction is complete — GL, tax, and subledger all finalized. But in Project Operations, the invoice record still looks unposted. The project manager has no automated signal that the posting happened. Root Cause There is no event-driven bridge between the two systems for this … Continue reading How to Eliminate Invoice Posting Blind Spots Between D365 Project Operations and Finance Using Custom Business Events →

What happens when a global manufacturing giant needs to modernize its operations without grinding critical business processes to a halt? The answer is not a rip-and-replace approach – it is a carefully engineered integration strategy that lets modern and legacy systems co-exist, communicate, and complement each other. Are you planning an ERP upgrade but worried about what happens to the legacy systems your operations depend on? If so, this is for you. One of North America’s leading commercial vehicle manufacturers faced exactly this dilemma. With decades of investment in legacy financial and warehouse management systems, a hard cutover to a new ERP was not an option. Yet the need for a modern, scalable platform was undeniable. Their solution? Introduce Microsoft Dynamics 365 Finance & Operations (D365 F&O) as the new operational backbone – while keeping their legacy systems in play for financial control – and build robust, bi-directional integrations to bridge both worlds. At CloudFronts, we had the privilege of architecting and implementing those integrations. This blog walks you through three core data flows: Spot Purchase Orders, Advance Shipment Notices (ASN), and Goods Receipt Notes (GRN) – and what it really takes to make a modern ERP talk to a legacy system without missing a beat. Why Replace When You Can Integrate? Legacy systems in large manufacturers are not just old software. They carry years of financial logic, vendor relationships, and compliance configurations that are too risky to discard overnight. Replacing them introduces enormous operational and compliance risk. Doing nothing, however, is not an option either. The approach our client took – and one we increasingly recommend for manufacturers, distributors, and large enterprises – is a co-existence model: This means the business gets the agility of a modern ERP on day one, without putting financial operations at risk. The three integrations do the heavy lifting. Architecture at a Glance Before diving into each integration, it helps to understand the overall data flow pattern and the Azure services involved: Component Role D365 F&O System of record for purchasing and receiving operations Legacy System Retains financial control, inventory management authority Azure Logic Apps Parent-child middleware: orchestrates, transforms, and routes data Azure Blob Storage Checkpoint management for reliable incremental processing Azure Table Storage Full execution logs for traceability, audit, and failure replay The three integrations work in concert: Integration 1: Spot Purchase Orders — D365 F&O to Legacy Business Problem A Spot Purchase Order is an ad-hoc purchase order raised outside of long-term contracts — often for urgent material procurement. Spot POs are created and managed in D365 F&O by procurement teams. However, the legacy system is the system of financial record, meaning every Spot PO created in D365 must be reflected in the legacy system for financial commitment tracking and vendor payment processing. Without integration, this would require manual re-entry – a process prone to error, delay, and duplication. How the Integration Works Parent Logic App – Spot PO Orchestrator The primary Logic App runs on a scheduled recurrence and uses a checkpoint mechanism stored in Azure Blob Storage to fetch only incremental changes – purchase orders created or modified since the last successful run. This ensures efficiency and prevents reprocessing of already-handled records. The workflow determines the operation type required for each PO: For each scenario, the Logic App fetches enriched data from multiple D365 F&O OData entities and constructs a structured JSON payload tailored for the legacy system’s API. ⚙ Tech Note: OData Entities Used PurchaseOrderHeaders, PurchaseOrderLinesV2, PurchaseLineDataEntities, WHSPurchLines, StatusCustomDatas Child Logic App – SendRequest (Reusable) Rather than embedding API communication logic directly in the orchestrator, we separated it into a reusable child Logic App. This child app receives the constructed payload, retrieves an OAuth 2.0 Bearer token, and executes the HTTP POST call to the legacy system’s API endpoint. This modular design pays dividends during maintenance: any change to authentication logic or API communication is made once in the child app and automatically applies to all parent integrations. Failed Record Handler Every enterprise integration needs robust failure recovery. When an API call fails: Sample Payload – Spot PO Create Sample JSON Payload: {   “userId”: “JSMITH”,   “order”: “456789”,   // Last 6 digits of D365 PO number   “vendor”: “VEND001”,   “receiptLoc”: “SITE01”,   “vendorOvrdCd”: “14”,   “lineItems”: [{     “orderLine”: “001”,     “item”: “ITEM001”,     “openQty”: 10,     “deliveryDate”: “061526”,  // MMddyy format for legacy compatibility     “comment”: “MPSSYS order – JSMITH” }] } } ✓ Business Impact: Zero manual re-entry of purchase orders between systems. Every Spot PO created or changed in D365 F&O is automatically reflected in the legacy system within minutes. Integration 2: Advance Shipment Notices — Legacy to D365 F&O Business Problem An Advance Shipment Notice (ASN) is a notification sent by the legacy WMS to the receiving system, informing it of an incoming shipment before it physically arrives. D365 F&O needs to receive ASNs to create Inbound Load Headers and Load Lines – enabling warehouse teams to prepare for receiving. Without this integration, receiving teams in D365 would be blind to incoming shipments until trucks arrived at the dock – eliminating any opportunity for advance dock scheduling, labor planning, or inventory pre-positioning. The Hybrid Integration Approach This integration presented an interesting technical challenge: the standard D365 F&O Inbound ASN V5 API supports a well-defined XML format, but the business required additional fields beyond what the standard API supports. The solution was a two-step Hybrid ASN Integration approach: ⚙ Tech Note: API Endpoint Pattern Insert:  POST {{BASE_URL}}/api/connector/enqueue/{{ACTIVITY_ID}}?entity=Inbound ASN V5 Enrich:  PATCH on InboundLoadHeaders and WHSASNWorkData Smart Insert vs. Update Determination To handle scenarios where an ASN might be re-sent for corrections or resynchronization, the integration includes a check before processing: This idempotent design prevents duplicate inbound loads from being created when the legacy system re-sends an ASN. One nuance worth noting: in D365’s standard ASN structure, the LoadId, ShipmentId, and LicensePlateNumber must carry the same value. The legacy system’s outbound ASN payload is configured to honour this requirement – ensuring clean data entry … Continue reading How a Top North American Commercial Vehicle Manufacturer Connected D365 F&O with Legacy Systems Without Disrupting Operations →

Summary Many project-based organizations evaluating Microsoft solutions often ask the same question: If Microsoft Dynamics 365 Business Central already includes a project module, why do companies also use Microsoft Dynamics 365 Project Operations? This article explains the difference between the two systems, why both exist in the Microsoft ecosystem, and how integrating Project Operations with Business Central helps organizations manage project delivery and financial performance more effectively. Table of Contents 1. Why This Question Comes Up 2. Business Central: Built for Project Accounting 3. Project Operations: Built for Project Delivery 4. Why Companies Use Both 5. The Value of Integration The Outcome Why This Question Comes Up Many organizations assume Microsoft Dynamics 365 Business Central can manage all aspects of project operations because it includes the Jobs module. The Jobs module supports project budgeting, costing, and invoicing, which works well for organizations focused mainly on financial tracking. However, as projects grow more complex, involving multiple resources, time tracking, delivery planning, and client reporting, companies begin to experience limitations. This is when the difference between project accounting and project delivery becomes important. One system manages project finances. The other manages how projects are executed. Business Central: Built for Project Accounting Microsoft Dynamics 365 Business Central is an ERP system designed primarily for financial management. Its Jobs module helps finance teams track the financial performance of projects. Using Business Central, organizations can: Track project budgets and costs Manage purchase orders and project expenses Generate project invoices Monitor project profitability Handle revenue recognition and financial reporting For finance teams, this provides strong control over costs, billing, and compliance. However, financial visibility alone does not guarantee successful project delivery. Project Operations: Built for Project Delivery Microsoft Dynamics 365 Project Operations focuses on how projects are planned and executed. It provides tools specifically designed for project managers and delivery teams. Project Operations enables organizations to: Plan projects and manage tasks Schedule resources and manage capacity Track time and expenses Monitor project progress Collaborate across teams These capabilities help project managers manage people, timelines, and delivery commitments. However, Project Operations is not designed to replace an ERP system for financial management. Why Companies Use Both In most project-based organizations, different teams depend on different systems. Team Focus System Project Managers Planning and project delivery Project Operations Finance Teams Cost control, billing, accounting Business Central Trying to manage everything in a single system often creates operational friction. Project teams struggle with financial processes, while finance teams lack visibility into project execution. The Value of Integration When Microsoft Dynamics 365 Project Operations integrates with Microsoft Dynamics 365 Business Central, organizations gain the best of both systems. A typical workflow looks like this: Opportunities and project quotes are created Projects are planned and executed in Project Operations Time, expenses, and resource usage are captured Billing data flows to Business Central Finance manages invoicing and accounting This integration connects project execution with financial performance. Project managers gain operational visibility, while finance teams maintain control over billing and reporting. The Outcome Projects are delivered more efficiently Financial reporting remains accurate and compliant Manual work and duplicate data entry are reduced Project managers and finance teams work from connected data This creates a unified platform where project delivery and financial performance remain aligned. Final Thought The question is not whether Business Central can manage projects — it can. The real question is whether one system should manage both delivery and financial operations. For many organizations, combining Microsoft Dynamics 365 Project Operations with Microsoft Dynamics 365 Business Central provides the ideal balance between operational execution and financial governance. At CloudFronts Technologies, we help organizations connect Project Operations with Business Central through our PO-BC integration solution. For more information: PO-BC Integration Solution on Microsoft AppSource If you would like to discuss how this integration can support your organization, feel free to reach out to us at transform@cloudfronts.com.

Project Operations and Business Central are designed to work together, one managing project execution, the other ensuring financial accuracy. When integrated thoughtfully, they create a clean and reliable flow from project activity to financial reporting. Clear Ownership of Responsibilities In a PO–BC integration: This separation allows project teams to focus on delivery while finance maintains full control over accounting outcomes. Smooth Cost Flow from Projects to Finance Costs captured in Project Operations- time, expenses, and materials – are transferred to Business Central as project journals. Business Central then: This ensures project activity is reflected accurately in financial statements. Consistent Project, Task, and Dimension Mapping A well-designed mapping between: ensures costs and revenue are visible: This makes both project reviews and financial reporting easier and more reliable. Period Control and Financial Accuracy Project Operations captures real-world project activity. Business Central applies: Together, they ensure project data flows into the correct accounting periods without compromising financial governance. Strong Visibility into Commitments and Actuals With the right setup: This combination provides management with a clear view of: To conclude, Project Operations tells the story of the project. Business Central tells the story of the business. When aligned, both stories match, and decision-making becomes easier. Final Thought Project Operations and Business Central integration works best when designed as a financial process, not just a system connection. With the right structure, it delivers clarity for project teams and confidence for finance. We have packaged our Project Operations-Business Central integration to help organizations achieve this alignment with minimal complexity You can explore our PO–BC integration on Microsoft AppSource here: PO-BC Integration 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.

In today’s data-driven business landscape, organizations strive to enhance visibility into their project operations to make informed decisions. Microsoft’s Project Operations (PO) provides a robust solution for managing projects, finances, and resources. However, to unlock its full potential, integrating PO with Power BI allows businesses to gain deeper insights through real-time analytics and visualization. This blog is specifically designed for Team Leads, CTOs, and CEOs who need to streamline project tracking, financial oversight, and resource allocation. By integrating PO with Power BI, decision-makers can reduce manual reporting efforts, gain actionable insights, and drive operational efficiency. Why Integration Matters Project Operations (PO) enables organizations to streamline project management, resource planning, and financial tracking. However, without effective reporting, extracting meaningful insights from this data can be challenging. Power BI bridges this gap by offering advanced visualization tools, predictive analytics, and customizable dashboards. Benefits of Integrating PO with Power BI Steps to Integrate PO with Power BI Use Cases of PO & Power BI Integration What’s Next? This blog is the first in a series on leveraging data for business growth. Stay tuned for upcoming blogs on: To conclude, Integrating Project Operations with Power BI empowers businesses with real-time, data-driven insights that enhance decision-making and operational efficiency. By leveraging advanced analytics and visualization, organizations can proactively manage projects, optimize resource allocation, and drive profitability. By embracing this integration, businesses can unlock the full potential of their project data and stay competitive in today’s digital economy. Stay tuned for the next blog in this series! We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com

Power BI is a great tool for turning data into clear, interactive reports and the best part?  It works smoothly with Business Central, right out of the box.  You just need to set it up, and you can start viewing powerful reports right inside within Business Central dashboard.  Microsoft provides several ready-made reports, grouped into different apps, so you can pick and install only what you need.  Once set up, these reports help you track key business insights without switching between systems.  In this blog, we’ll walk you through how to set up and use Power BI reports in Business Central to make smarter decisions. References Introduction to Business Central and Power BI Install Power BI apps for Business Central Configuration Open your Business Central and search for “Assisted Setup”. Click on “Connect to Power BI” Once the set up page opens, click on Next. Fiscal: A 12-month calendar that begins in any month and ends 12 months after. Standard: A 12-month calendar that begins on January 1 and ends on December 31. Weekly: A calendar that supports 445, 454, or 544 week groupings.The first and last day of the year might not correspond to a first and last day of a month, respectively. Specify the time zone. Specify the working days. Here, it asks for configuring individual apps for Power BI. You can skip this for now as we’ll be back at this later. In the next screen, specify the environment name and the company name. Now, we’ll install the “D365 Business Central – Sales” app in Power BI. Go to your Power BI dashboard and click on Apps.  Search for Business Central Open the relevant one and click on “Get it now” Then click on “Install” Wait for a few seconds till the installation is complete. Now, when you open the report for the first time, it’ll show the report with sample data. To view it with your own data, we need to connect the data to Business Central. Enter the company and environment name. Specify the authentication method to OAuth 2.0 and click on “Sign in and connect” After a few minutes, the refresh will be completed and you’ll see your data. Once this is done, search for “Power BI Connector Setup” In the relevant tab, Sales Report for this example, click on “Power BI Sales” field’s drill down. Select the app that you installed. Now go back to your Business Central dashboard and scroll down to the “Power BI” section. Click on the “Get Started with Power BI” and keep clicking on Next till the end of the setup. If there are any selected reports, you will see the relevant report. If not, you’ll see the following-  In either case, click on the drop-down next to Power BI or click on the “Select reports” Scroll down to find the appropriate report and click on “Enable” and then click on Ok. You will see your Power BI report on the dashboard. You can enable multiple reports and cycle through them by clicking on the “Next” and “Previous” buttons. You can also expand the report to see it as a full page within Business Central by clicking on the “Expand” page. You can further view it in Fullscreen as well. If you want to see multiple reports on the same page, we can create a custom role center and add multiple reports to them. For example, I’ve created a “Power BI dashboard” role center. In this way, we can have n number of reports on our dashboard. Source Code – BCApps-PowerBIDashboard Setting up Power BI in Business Central is a simple way to bring your data to life.  With just a few steps, you can connect your reports, see real-time insights, and make better business decisions all without leaving Business Central.  Whether you need sales trends, financial reports, or custom dashboards, Power BI makes it easy to track what matters most. If you need further assistance or have specific questions about your Business Central and Power BI Integration, 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@cloudfonts.com.

Introduction The integration of Shopify with Dynamics 365 Finance and Operations (FnO) starts by creating a secure link.The initial step in this process involves generating an API token within Shopify, serving as the credential for verified communication between both systems.In this blog I will walk you through the steps to create the API token, facilitating a seamless beginning for your integration. Pre-requisites Access to the Shopify Admin account with appropriate permissions to create private apps or access custom apps.API access enabled in your Shopify store.A basic understanding of API concepts and authentication methods. [Available in Reference]The URL or endpoint details where the API calls will be directed. [Available in Reference] References Shopify – How to generate API token ResfulAPI.net – Basics of REST APIsShopify.dev – REST API Documentation Configuration Step 1: Access the Shopify Admin Portal Log in to your Shopify store’s Admin account. Navigate to Apps from the main menu. Step 2: Create a Custom App Click on Develop Apps (available under Apps). Select Create an App and provide a name (e.g., “Dynamics365_Integration”). Assign a developer or admin as the app owner. Step 3: Configure API Scopes After creating the app, click on it to open the configuration page. Under the Configuration section, define the API scopes required for integration based on your requirements. You can change these later if required. For example: Click on Save to save the changes. Step 4: Generate the API Token Once scopes are set, click on the API credentials tab. Click Install App to generate the credentials. A unique Access Token will be displayed.  Copy and securely store this token, as it will not be shown again. If you scroll down, you’ll also see the API Key and API Secret; store these values as well. Step 5: Test the Token Use a tool like Postman to test the API token. Set up a GET request to an API endpoint (e.g., https://<API KEY>:<API Secret>@<Store Name>.myshopify.com/admin/api/2023-07/products.json). Include the token in the header as X-Shopify-Access-Token. Verify the response to confirm the token is working correctly. Or simply (https://<Store Name>.myshopify.com/admin/api/2023-07/products.json) Conclusion The API token is your gateway to integrating Shopify with Dynamics 365 Finance and Operations.  By following this guide, you’ve taken the first critical step toward seamless data flow between your e-commerce platform and back-office operations.  In the next blog, we’ll explore how to configure Dynamics 365 Finance and Operations to connect with Shopify and start synchronizing data. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Introduction: While using Business Central Web Services or APIs, we often use POSTMAN for testing the request and the responses. Today we’ll see how we can automate this testing to a certain extent using the inbuilt features of POSTMAN. We can have testing logic that runs before every request, after every request or logic that tests on particular request. In the below demonstration, we’ll write automated test to check for GET, PUT, POST and DELETE operations for a single record on a custom API. Postman itself provides a bunch of standard procedures or boiler plate code which we can modify as per our requirements. As this uses Javascript we can also use additional JS features here. Pre-requisites: Postman Business Central OnCloud or OnPremise References: Writing tests | Postman Learning Center Announcing Postman for the Web, Now in Open Beta | Postman Blog Configuration: Post Request – So first we are going to be creating a record in the Customer Table with the following fields. One of the common things to be testing with Custom APIs is to verify whether the request is being created successfully (1) and what we are sending and what is being stored in the record are the same(2). As we are using Javascript, the response is stored in the jsonData variable and we can access any of the fields of the response as a property on the jsonData variable.  As the rest of our automated tests are doing to be performed on this same record, we need to store the Identifier for this record inside some variable which exists outside the scope of this request, here we are using a variable with the Collection scope. If you want to use the same variable outside of this collection, you can also define Global variables.  GET Request – In a simple GET request, the only thing we are concerned with here, is whether the request is executed successfully or not. For this we are simply going to be checking the Status Code. PUT Request – In a PUT request, we are going to be modifying the record that we previously created, here I’m going to update the name of the record. A common test-case for PUT requests would be to ensure that (a) the request is completed successfully and (b) what is being sent in the request is what is updated on the record and is available in the response. DELETE Request – In a simple DELETE request, the only thing we are concerned with is whether the requested is executed successfully and here we will be simply checking the Status Code returned. Once all the Automated Tests are written, you can either execute them from the Collection Level or from a folder level. Here we will be executing our tests from the folder level.  We can also define the Run Order for the requests.  Once the Tests have run, we can get a summary of the results as well as detailed version of the results.  Conclusion: Thus we saw how to use Automated Testing in POSTMAN to reduce re-work and increase efficiency while testing. A bonus tip – you can now use POSTMAN Web Version to create requests instead of download the POSTMAN app and the entire blog above was written using the Web App of POSTMAN. Do note that not everything that can be done on the Windows App can be done on the Web App. Happy Coding!

Introduction: In this blog, we will see how to get response from Rest Api through GET call Solution:  Consisting of basic authentication, we will pass username and password in byteStr and for the endpoint we will put it in url in below code. class CFSJSTestRestAPI { public static void main(Args _args) { int find; str url,aosUri,activeDirectoryTenant; str activeDirectoryClientAppId; str activeDirectoryClientAppSecret; str postData,activeDirectoryResource; str aadClientAppSecret,oAuthHeader; str returnValue,jsonString,jsondszstr; System.Net.HttpWebRequest request; System.Net.HttpWebResponse response; System.Byte[] byteArray; System.IO.Stream dataStream; System.IO.StreamReader streamRead; System.IO.StreamWriter streamWrite; System.Net.ServicePoint servicePoint; System.Net.ServicePointManager servicePointmgr; System.Net.HttpVersion version; CLRObject clrObj; Newtonsoft.Json.JsonReader reader; System.Text.Encoding utf8; Counter countCounter; Object obj; Map data; System.Byte[] byteArraynew; System.Net.WebHeaderCollection headers = new System.Net.WebHeaderCollection(); new InteropPermission(InteropKind::ClrInterop).assert(); str byteStr = strfmt(‘%1:%2’, “USERNAME”, “PASSWORD”); headers = new System.Net.WebHeaderCollection(); url = “http://dummy.restapiexample.com/api/v1/employees”; clrObj = System.Net.WebRequest::Create(url); request = clrObj; request.set_Method(“GET”); request.set_KeepAlive(true); request.set_ContentType(“application/json”); utf8 = System.Text.Encoding::get_UTF8(); byteArraynew = utf8.GetBytes(byteStr); byteStr = System.Convert::ToBase64String(byteArraynew); headers.Add(“Authorization”, ‘Basic ‘ + byteStr); request.set_Headers(headers); servicePoint = request.get_ServicePoint(); System.Net.ServicePointManager::set_Expect100Continue(false); System.Net.ServicePointManager::set_SecurityProtocol(System.Net.SecurityProtocolType::Tls12); response = request.GetResponse(); dataStream = response.GetResponseStream(); streamRead = new System.IO.StreamReader(dataStream); jsonString = streamRead.ReadToEnd(); info(strFmt(“RESPONSE: %1”,jsonString)); dataStream.Close(); response.Close(); } } Thanks for reading !!!

Introduction: While migrating Cases, the migration of activities of type ‘Case Resolution’ is necessary. However, the complexity in migrating this increases due to the fact that when the status of a case is updated, a blank case resolution activity is created automatically by the system. This system-generated case resolution needs to be deleted as this would result in each case having two case resolution activities after migration – one system-generated and one with the correct migrated data from the source. Solution: To tackle this issue, one must follow the following steps during migration: 1. Send all Cases (no matter what the status in the source environment) to the target with their status as ‘Open’. 2. Send all related activities to the target environment. 3. Update the case status in the target environment to its status as in the source environment. 4. For cases with status ‘Resolved’, a system-generated case resolution activity will be created. 5. In your case resolution migration map, first add a step to delete the existing case resolution in the target and then insert the case resolution from the source environment. 6. Now your case with status ‘Resolved’ will have only one case resolution and that will be the one migrated from the source environment with the correct data. Conclusion: Above steps shed some light on how to preserve the integrity of case resolution activity data in your target environment during data migration.