Sending Dynamics 365 Emails from JavaScript with the Dataverse Web API | CloudFronts Summary Most Dynamics 365 emails are generated by workflows, Power Automate flows, or plugins reacting to a record change. But some notifications are triggered by a user action inside a custom UI, where the browser already holds all the context and the user needs to know immediately whether the email went out. In this implementation, we generated and sent Dynamics 365 email activities directly from JavaScript running in an HTML web resource, using only the Dataverse Web API. The email is created with sender and recipient activity parties, linked to a related record through the Regarding lookup, and sent through the SendEmail bound action for delivery by server-side synchronization. This article covers the problem, the use case, how an email is structured in Dataverse, and a step-by-step walkthrough of the JavaScript implementation, including the pitfalls we hit along the way. Table of Contents Problem Statement The Use Case Why Send Emails from JavaScript? Anatomy of an Email in Dataverse Solution Overview Step 1 — A Reusable Web API Helper Step 2 — Identifying the Sender Step 3 — Resolving the Recipient Dynamically Step 4 — Creating the Record the Email Will Be Regarding Step 5 — Composing the Subject and HTML Body Step 6 — Building the Activity Parties Step 7 — Binding the Regarding Lookup Step 8 — Creating the Email Record Step 9 — Sending the Email with SendEmail Understanding the Email Lifecycle The Complete Email Function Error Handling Testing and Validation Security and Production Considerations Key Implementation Lessons Conclusion Frequently Asked Questions This Blog Explains When a user action, rather than a record change, should be the trigger for an email. How an email activity, its activity parties, and its Regarding lookup fit together in Dataverse. How to create an email with From and To recipients through the Web API. The Regarding navigation property naming that commonly causes silent failures. The difference between creating an email and sending it. Why sent emails show as Pending Send, and what has to be configured for delivery. Read more about our Journey with this Customer over here: View Case Study  |  Refer my previous blog on the associated topic for more context Problem Statement Dynamics 365 offers several ways to send email automatically, and nearly all of them are record-driven: something is created or updated, and a workflow, flow, or plugin reacts to it. That model breaks down when the event worth notifying about is not a simple record change but an action a user performs in a custom interface, such as an HTML web resource or a custom page. In those cases: The trigger is a button click, and the relevant context (who acted, what changed, what the previous value was) lives in the browser. The email must only be sent once a multi-step operation has fully succeeded, not when it starts. The user expects immediate confirmation that the notification went out, or a clear message if it did not. The email should be a proper Dynamics 365 activity, visible on a related record’s timeline, not an untracked message sent from outside CRM. An asynchronous flow cannot give the user that immediate feedback, and a plugin would need to reconstruct context the UI already has. The question became: Can we create, link, and send a fully tracked Dynamics 365 email directly from the JavaScript that handles the user’s action, using only the Dataverse Web API? The Use Case The scenario was a custom Dataverse Choice (Option Set) Manager, an HTML web resource that lets authorized users add or relabel picklist values (for example, Lead Source) from within Dynamics 365.Building Self-Service Dataverse Choice Picklist values feed reports, business rules, flows, and integrations, so the Operations Lead needed to be informed every time one changed. The notification rules were: Rule Implication for the email Notify only after the change is published The email is generated as the final step, after PublishXml succeeds Send from the user who made the change The sender activity party is the signed-in user Send to whoever currently holds the Operations Lead role The recipient is resolved at runtime, not hard-coded Keep the email traceable The email is set Regarding a Picklist Changes Audit Log record Include full change details The HTML body lists action, time, user, entity, field, option name, value, and old label The picklist change itself is the trigger. Everything that follows in this article is about the email. Why Send Emails from JavaScript? Approach Fit for a user-action trigger Power Automate Runs asynchronously, so the user cannot be told in the same interaction whether the email was sent Classic workflow Record-driven and deprecated in favour of Power Automate for new development Plugin Needs a compiled, registered assembly and must reconstruct context the UI already holds JavaScript + Web API Runs in the same interaction, has full context, and reports success or failure to the user immediately Because the web resource runs inside Dynamics 365, each Web API call executes as the signed-in user. Their security roles still decide whether they can create an email, set its recipients, and send it. Anatomy of an Email in Dataverse Before writing any code, it helps to understand that an email in Dynamics 365 is not a single record with To and From text fields. It is an activity made up of several related pieces. email (activity) ├── subject ├── description → HTML body ├── directioncode → true = outgoing ├── statecode / statuscode │ ├── email_activity_parties (collection) │ ├── participationtypemask = 1 → From │ ├── participationtypemask = 2 → To │ ├── participationtypemask = 3 → CC │ └── participationtypemask = 4 → BCC │ └── partyid → systemuser / contact / account / lead … │ └── regardingobjectid → any activity-enabled table Piece What it does Email record Holds the subject, body, direction, and status Activity parties Separate records linking the email to each sender and recipient Regarding Polymorphic lookup … Continue reading D365 CRM – Generating Emails using JavaScript via user actions for US based Azure & AI services company →

​ Summary An Australian commercial laundry and linen company already sent its quotes from Dynamics 365, with Approve and Reject buttons in the email. It worked, but the links never expired and could be clicked again and again, so a forwarded or months old email could still change a quote. We made every link single use and valid for 30 days. Customers still answer with one click, and the sales team can now trust the decision they see on the quote. In This Blog Why a reusable approval link is a quiet business risk What the customer sees, from email to confirmation What the sales team sees in Dynamics 365 How we went live without breaking quotes already sent When this approach is the right fit Table of Contents Summary→ Business Challenges→ What We Built→ How It Works→ Going Live Safely→ Impact→ Is This Right for You?→ Conclusion→ FAQ→ Get in Touch→ Business Challenges The quoting process itself was in good shape. Sales built the quote in Dynamics 365, generated the PDF and emailed it with two buttons. The customer clicked Approve or Reject and the answer landed on the quote. Nobody had to chase a reply or retype it. The weak spot was the link behind those buttons. It never changed and never expired, and anyone holding the email could use it. In practice that meant: A customer could approve a quote, then click Reject on the same email weeks later and quietly overwrite the decision. An email forwarded inside the customer’s business could be answered by someone who was never meant to decide. Quotes that had been revised and resent still had live buttons in the older emails. For a business that moves straight from an approved quote to a contract, the decision on the record has to be the real one. Before Links worked forever Any click could change the answer Old emails stayed live after a resend After Each link works once, for 30 days The first decision is final Only the newest email is live What We Built For the customer, almost nothing changed, which was the point. The email looks the same, with the quote attached and the two buttons underneath. There is still no login, no portal and no password to remember. The quote email with the PDF attached and one click Approve and Reject buttons. Captured from a test quote, names changed. One click records the decision and shows a short confirmation. When the quote is approved, the page tells the customer the contract is on its way. The confirmation the customer sees after approving. Captured from a test quote. What changed is everything after that first click. If a button is clicked again, the customer is told the quote is already approved and nothing on the record moves. If the link is older than 30 days, or a newer quote email has replaced it, a clear page asks them to contact their sales representative for a fresh link. Clicking the same link again changes nothing and says so plainly. Captured from a test quote. An expired or replaced link points the customer back to their sales contact. Inside Dynamics 365, the customer.s decision is saved straight onto the quote, along with when the link expires. That decision is what starts the contract process, so it now carries real weight. The test quote in Dynamics 365. The timeline confirms the quote document was sent for review and approval. Names changed. How It Works Everything runs on Dynamics 365 and Power Automate, which the client already had. No new apps and no new licences. Step oneSales sends the quoteFrom the quote, as before Step twoA unique link is issuedOne per email, valid for 30 days Step threeThe customer clicksThe link is checked before anything is saved Step fourDecision saved, link closedAny later click is politely turned away How a quote link moves from sent, to used or expired. Each time a quote is sent, Dynamics 365 stores a new private code and an expiry date on the quote, and that code is built into both buttons. When the customer clicks, the flow compares the code in the link with the one on the quote. Only a match within 30 days is accepted. Once the decision is saved, the code is marked as used, so the same link cannot be accepted again. Worth knowing before you start Resending a quote replaces the link, so customers should always act on the newest email. Agree the expiry period with sales up front: 30 days suited this client’s quoting cycle, but yours may be shorter. And make sure the expired page names someone the customer can actually contact. Going Live Safely The tricky part was not the new links. It was the quotes already sitting in customers’ inboxes, sent under the old process without a private code. Switching them off overnight would have turned a security improvement into a stream of confused customers. So those older emails keep working until each quote receives its first answer, and from then on the same single use rules apply. We built and tested in the client’s test environment first, then went live in production with test quotes sent only to our own team before any customer saw the change. Impact A decision you can trust. The answer on the quote is the customer’s first and final one, so contracts start from solid ground. No extra effort for customers. Still one click, still no login, on any phone or laptop. Old emails retire themselves. Revised quotes no longer leave live buttons behind. No new cost. Built on the Dynamics 365 and Power Automate licences the client already owned. Is This Right for You? There is more than one way to collect a customer’s yes. This is how we usually compare them with clients. This projectOne time email link Customer portal Electronic signature Customer effort One click, no login Sign in, then respond Open, review and sign Extra licences None Portal … Continue reading How an Australian Linen Company Made Quote Approvals Secure with One Time Links in Dynamics 365 →

Summary An Emirates-based marine services firm running Microsoft Dynamics 365 Business Central found that an approved purchase order had disappeared, along with every record of who approved it. We confirmed the order had been deleted rather than archived, showed why Business Central removes approval entries together with the document, and identified the likely approvers from the approval chain. We then explained how a point-in-time restore of Production into a sandbox recovers the actual approval history, set up the change log so future deletions are recorded in full, and recommended controls that stop approved documents from being deleted at all. Table of Contents Introduction Understanding the Issue Deleted or Archived? How We Confirmed It Why the Approval Entries Disappeared Reconstructing the Likely Approvers Recovering the Evidence with a Point-in-Time Restore Making Future Deletions Traceable Preventing Approved Documents from Being Deleted Business Impact Frequently Asked Questions Conclusion Introduction Approval workflows in Microsoft Dynamics 365 Business Central give finance teams confidence that every purchase order was reviewed before it went to a vendor. That confidence depends on one assumption: the approval history will still be there when someone needs it. For an Emirates-based marine services firm we work with, that assumption broke. The finance team went looking for a released purchase order and could not find it. When they checked Approval Entries, there was nothing there either. A few days later, two purchase invoices were deleted as well, and the change log had no record of them. 1 Approved purchase order missing 0 Approval entries left for it 28 Days available to recover the evidence This post walks through how we investigated the issue, what Business Central does behind the scenes when a document is deleted, and the setup that makes every future deletion traceable. The Lesson In Business Central, deleting a document also deletes its approval history. Audit trails have to be set up before they are needed, not after. Understanding the Issue The finance team came to us with three questions. Each needed a clear, evidence-based answer. 01 Was It Deleted or Archived? The order was in Purchase Order Archives, so it looked as if someone had simply archived it by hand. 02 Who Approved It? The order had been released through an approval workflow, but Approval Entries showed nothing for it. 03 Why Was Nothing Logged? The change log had just been switched on, yet the invoices deleted afterwards left no trace in it. Deleted or Archived? How We Confirmed It Archiving and deleting both leave a copy in Purchase Order Archives, so the archive alone does not tell you what happened. The difference is what remains in the live system. Archived Archive Document A copy is saved to Purchase Order Archives, but the original order stays in the Purchase Orders list, together with its approval entries. Deleted Delete The order leaves the Purchase Orders list. If Purchases & Payables Setup is set to archive orders, Business Central saves an archive copy automatically at the moment of deletion. We worked through the possibilities one at a time: How we ruled out each possibility Not in Purchase Orders → No Receipts, Invoices or G/L Entries → Only in Archives → Version No. 1 → Deleted The Version section of the archived order settled it: Version No. 1: only one archived version existed, so the order had never been archived by hand. This version was created when the order was deleted. Archived By: the user ID that deleted the order. Date and Time Archived: the exact moment of deletion. Figure 1: The archive version details show who deleted the order and when. Why the Approval Entries Disappeared Approval entries are linked to the document they belong to. When the document is deleted, Business Central deletes its approval entries too. The archive keeps the order’s header and lines, but not its approval history. To show this to the client with evidence rather than theory, we reproduced it on a copy of Production using an older released order: 1 Released Order We picked a purchase order that had been released through the approval workflow. 2 Approvals Recorded Its Approval Entries showed three approvals from three different approvers. 3 Order Deleted After the order was deleted, Approval Entries showed nothing for it. 4 Archive Copy Remains The order was still available in Purchase Order Archives, without its approvals. Figure 2: Before deletion, the test order carries its full approval history. Figure 3: After deletion, the approval entries are gone, even though an archive copy exists. Key Insight Purchase Order Archives answer what the order looked like. They do not answer who approved it. Once a document is deleted, that question can only be answered from a backup. Reconstructing the Likely Approvers With the approval entries gone, we looked at the next purchase order raised by the same user. Approvals follow the approver chain set up in Approval User Setup, so an order from the same requester with a similar amount follows the same route. Step Role What Happens 1 Requester Raises the purchase order and sends it for approval 2 First approver Next user in the requester’s approver chain 3 Second approver Next user in the chain, based on the approval limits A Reconstruction, Not a Record This identifies the most likely approvers, but it is not proof. It assumes the approval setup has not changed since, and that the deleted order’s amount did not cross a limit that would have added another approver. Recovering the Evidence with a Point-in-Time Restore Business Central Online lets you restore an environment to any point in time within the last 28 days. A Production environment can be restored as a new sandbox, which leaves Production untouched. In that copy, the deleted order still exists with all its approval entries. Steps We Recommended In the Business Central Admin Center, open the Production environment and choose Restore. Pick a point in time a few minutes before the deletion. Convert the archive’s timestamp to the time zone the Admin Center … Continue reading Recovering Lost Approval History After a Purchase Order Deletion in Business Central →

Summary For Emirates Consortium, an Abu Dhabi-based diversified holding company already using Microsoft Dynamics 365 Business Central across multiple legal entities, intercompany accounting is a relevant process area. This article explores how standard intercompany functionality can simplify transactions between related companies. It covers intercompany partner relationships, customer and vendor links, and G/L account and dimension mappings. Using practical scenarios, we walk through a sales invoice raised in one company and received as a purchase invoice in another, as well as journal-based allocation of partial expenses. The walkthrough also shows how the Intercompany Outbox and Inbox support transaction review before posting, and highlights key reconciliation controls and limitations. Table of Contents Introduction The Business Problem The Solution Implementation and Process Walkthrough Limitations and Key Considerations Business Impact Frequently Asked Questions Conclusion Introduction Organizations operating through multiple legal entities often share resources, incur costs centrally, and recharge expenses to the company that actually benefits from them. Although these entities belong to the same business group, each company maintains its own accounting records, receivables, payables, and financial reporting. Emirates Consortium LLC is an Abu Dhabi-based diversified holding company with businesses across the UAE and Maldives. As highlighted in the Emirates Consortium customer success story, CloudFronts deployed Dynamics 365 Business Central across five legal entities to support core business processes. For organizations operating across several companies, intercompany recharges and cost allocation are important areas to assess when looking to reduce duplicate finance work. To explore these capabilities, consider two related companies, Gulf Aquaculture (GA) and Gulf Aquaculture Alliance (GAA). The walkthrough covers two practical routes: an intercompany sales invoice for a formal recharge and an intercompany general journal for direct cost allocation. It explains the setup, accounting impact, and important control points involved in both processes. Route A Intercompany Sales Invoice A formal recharge from GA, received in GAA as a purchase invoice. Route B Intercompany General Journal A direct allocation of part of a cost already recorded in GA. The Business Problem The finance team managed transactions for separate group companies, but some costs, such as consultancy, administration, payroll-related expenditure, and project-related operating expenses, were initially incurred or recorded in GA even when they partly or entirely related to GAA. For example, GA might receive an external vendor invoice for AED 10,000, of which AED 4,000 is attributable to GAA. Without a standard cross-company workflow, staff must determine the chargeable amount, prepare a corresponding transaction in the second company, and verify that the two sets of books agree. 10,000 AED external vendor invoice recorded in GA 4,000 AED attributable to GAA 6,000 AED that remains GA’s own cost Handling this manually created five gaps: 01 Manual Re-Entry Re-entering transactions increased the risk of inconsistent amounts, descriptions, or account classifications between companies. 02 Hidden Costs The receiving company needed visibility into its own project and operating expenses rather than having those costs remain embedded in GA. 03 Limited Control Finance required control over which transactions were sent, accepted, and posted, particularly for higher-value recharges. 04 Different Account Structures The chart of accounts and dimensions needed to translate correctly when the two companies used different codes or reporting structures. 05 Month-End Reconciliation Intercompany balances needed to be traceable and reconcilable at month-end. Business Objective Record the charge once in the initiating company, communicate it through Business Central, and let the receiving company review and post the corresponding entry in its own books. The Solution The proposed approach used standard Business Central intercompany functionality rather than a separate custom integration. Both companies were configured as intercompany partners, with mapped accounts and dimensions to support the exchange of transactions. 1. Establishing the Intercompany Relationship Each participating Business Central company needs its own Intercompany Setup and a unique IC Partner Code. The other company is then added as an intercompany partner with an appropriate transfer method. For a partnership inside the same Business Central environment, direct company-to-company transfer can be used where supported by the configured environment. 2. Connecting Customers and Vendors In GA, GAA is represented by an intercompany customer for billing. In GAA, GA is represented by an intercompany vendor for recording the payable. Assigning the relevant IC Partner Code on the customer and vendor records connects the commercial documents to the receiving company. In GA Customer card GAA as an Intercompany Customer Used to bill GAA. The IC Partner Code links the invoice to GAA. In GAA Vendor card GA as an Intercompany Vendor Used to record the payable to GA. The IC Partner Code links it back to GA. 3. Mapping the Intercompany Chart of Accounts Business Central uses a shared intercompany chart of accounts as the language between companies. Each company maps its own G/L accounts to the intercompany accounts and maps incoming intercompany accounts back to its local G/L accounts. When account numbering differs between companies, these mappings are essential. During the walkthrough, the team reviewed how a sales invoice line could carry an IC Partner Reference so that the receiving company would recognize the appropriate expense account. Account mapping in both directions was especially important: an account existing in one company does not guarantee that the other company can post it. 4. Preserving Dimensions and Project Context Intercompany dimensions can transmit reporting context such as Department, Project, or Cost Centre when corresponding dimension codes and values are set up and mapped. The accounting team should confirm that the receiving company’s dimension values accurately represent the destination project or department. 5. Choosing the Appropriate Transaction Route Business Requirement Recommended Standard Route Formal charge for services or reimbursable costs GA intercompany Sales Invoice → GAA Purchase Invoice Partial allocation of an expense already recorded in GA Intercompany General Journal → corresponding journal in GAA Direct allocation while registering an external vendor invoice Purchase Invoice cost-allocation fields for IC Partner, where applicable and tested Correction of an earlier intercompany charge Appropriate credit memo or reversing journal, reviewed in both companies The following walkthrough focuses on the first two routes: intercompany invoices and intercompany … Continue reading How an Abu Dhabi-Based Diversified Holding Company Simplified Intercompany Transactions in Dynamics 365 Business Central →

Summary Connecting Dynamics 365 Project Operations with Business Central creates a continuous data journey from project planning and execution to financial visibility. Project and task information, planning lines, time, materials, expenses, billable values, and invoices must retain their identity and meaning as they move between systems. This implementation focuses on preserving those relationships so that Budget, Actual, Billable, and Invoiced values remain traceable and meaningful throughout the project lifecycle. The result is an integration that does more than synchronize records: it creates a reliable data story that supports project operations, ERP processes, financial analysis, and decision-making. Table of Contents Why Project Data Needs a Journey The Data Journey Entity-to-Entity Mapping Planning Lines Budget vs. Actual vs. Billable vs. Invoiced Execution and Project Journals From Activity to Invoice The Analytics View Implementation Lessons Conclusion The Project Does Not Live in One System Project Operations is where teams plan and manage project work. Business Central is where the project becomes part of an ERP financial workflow. The interesting part is the space between them. When the same customer, project, task, resource, or transaction crosses that boundary, the integration has to preserve more than a name. It has to preserve relationships and translate the source record into the target system’s business model. The Engineering Question “Did the record sync?” is only the first question. “Does the record still mean the same thing?” is the engineering question. CRM Project Operations Where the Project Is Planned Customer, project, tasks, resources, estimates, time, and project activity are planned and managed here. ERP Business Central Where the Project Becomes Financial Project tasks, planning lines, journals, invoices, and financial visibility form the ERP financial structure. CRM side Figure 1: A Project Operations project with stages, customer, dates, estimates, and project context. ERP side Figure 2: The corresponding project structure in Business Central. A Different Way to Look at the Integration Think of It as a Data Pipeline Source entities become mapped entities, mapped entities become ERP records, and ERP records eventually become transactions and financial metrics. How a record moves between the two systems Project Operations projects · tasks · resources → Mapping Layer identity · transformation → Business Central projects · planning lines 01 Plan Estimates, tasks, resources, and planned quantities describe what the project is expected to consume. 02 Execute Time, materials, and expenses create operational evidence of what happened. 03 Bill Billable value moves toward invoicing, turning project activity into commercial output. Entity-to-Entity Mapping Is Where Meaning Gets Preserved One of the most important parts of a Project Operations to Business Central integration is deciding what a source entity becomes in Business Central. The mapping is effectively a semantic contract. Project Operations Business Central Why It Matters Account (Customer) Customer Customer identity must remain consistent across systems Project msdyn_project Project / Job The project becomes the parent financial structure Project Task msdyn_projecttask Project Task / Job Task Task identity is required for planning and transaction attribution Estimate msdyn_estimateline Job Planning Line Planning becomes a structured Business Central financial planning record Time Entry msdyn_timeentry Project Journal Recorded effort can become project usage Figure 3: Account data flowing into Business Central as a customer, carrying its identity across the boundary. Planning Lines Are the Semantic Bridge Planning lines sit at the point where a project plan starts becoming an ERP financial model. In Business Central, planning lines can represent planned cost, billable value, or both, depending on how they are configured. That makes them especially important when explaining the transition from “what we intend to do” to “what the ERP expects this project to cost or generate.” Quantity How much work, material, or resource usage is expected? Unit Cost / Price What cost or commercial rate is associated with the planned quantity? Total Cost / Price The planning line turns quantity and rates into project-level financial expectations. CRM side Figure 4: The work breakdown structure decomposes project work into manageable tasks. ERP side Figure 5: Resource assignments become structured planning lines in Business Central. The Four Numbers People Confuse Most These values answer different questions. Treating them as interchangeable is one of the fastest ways to misread a project dashboard. 01 Budget: What Did We Expect to Spend? Budget represents planned cost. It is a planning value, not proof that the cost has already occurred. 02 Actual: What Cost Was Recorded? Actual (usage) cost is tied to execution and recorded project usage. A blank actual does not mean the budget disappeared; it means no actual usage has been recorded in that context. 03 Billable: What Value Can Be Charged? Billable represents chargeable project value according to the project’s planning and billing configuration. 04 Invoiced: What Has Actually Been Billed? Invoiced is downstream of billable value. A project can have billable value before the corresponding amount has been invoiced. The Simplest Mental Model Budget → Actual answers the cost question. Billable → Invoiced answers the revenue and billing question. Figure 6: Project budgeting concepts in Project Operations (source: Microsoft Learn). Execution Creates the Evidence Once the project moves from planning into execution, operational records begin to tell the story of what actually happened. Time entries, material usage, and expenses are examples of records that contribute to project actuals and downstream ERP transactions. What feeds the project journal Time hours worked + Materials items consumed + Expenses project spend → Project Journal CRM side Figure 7: Time entries recorded against projects and tasks. ERP side Figure 8: Approved time entries represented in the Business Central project journal. Figure 9: Material usage follows the same project-to-ERP transaction path. Engineering Insight An integration should be traceable backwards. If a number appears in an ERP report, you should be able to explain which transaction produced it and which project and task it belongs to. From Project Activity to Invoice The final part of the journey is commercial. Billable project data eventually feeds invoicing, creating a visible chain from planned work to customer-facing financial output. 01 Project Activity Time, materials, expenses, and … Continue reading From Project Operations to Business Central: Following the Data Behind Project Financials →

Summary For a Maldives-based marine services firm running Microsoft Dynamics 365 Business Central across multiple operating sites, item journals are used to record consumption and disposal of inventory such as diving and water sports equipment, consumables, and spares. The standard item journal does not stop a user from consuming or disposing more than is physically available at the selected location, because the item lookup and the Inventory figure reflect stock across all locations. In this implementation, we restricted item visibility and quantity validation to the location selected on the journal line. Users must select the location first, the item lookup shows only items with stock at that location, and the quantity is validated both when the line is entered and again at posting. We also carried the location onto the Item Journal Batch so that approval workflows can be routed per location. Table of Contents Introduction Understanding the Business Requirement The Challenge with Standard Item Journals Filtering the Lookup vs. Validating the Line Designing the Solution Filtering the Item Lookup by Location Validating Quantity at Entry and Posting Routing Approvals by Location Implementation Approach Business Impact Frequently Asked Questions Conclusion Introduction Many organizations running Microsoft Dynamics 365 Business Central hold the same items across several locations: properties, stores, warehouses, or project sites. Day-to-day consumption and disposal of that stock is usually recorded through item journals. Consider a storekeeper who opens the item journal to record the use of cleaning supplies. Business Central tells her one thing; her storeroom tells her another. 200 Units shown in Business Central 60 Units on her own shelf 140 Units at other locations Without additional controls, nothing prevents her from posting 100 units from her location. The journal accepts it, the location goes negative, and the difference only surfaces during stock counts or month-end reconciliation. This was the challenge for a Maldives-based marine services firm we worked with. Its sites are spread across separate islands, so equipment and consumables held at one site cannot simply be used at another. We addressed this with one rule enforced at every step: The Rule A user can only consume or dispose of what is physically available at the location they selected. Understanding the Business Requirement Before writing any code, we agreed the expected behavior with the client as concrete scenarios. Each scenario later became a test case for user acceptance testing. Scenario 1 Item Stocked Across All Locations Cleaning concentrate. User selects Location A. Location A60 Other locations140 Company total200 Shows 60 available. Entering 100 is blocked. Scenario 2 Item Available at Several Locations Snorkel mask. User selects Location A. Location A30 Location B5 Location C21 Location D10 Shows 30 available. Other locations are ignored. Scenario 3 No Stock at the Selected Location Kids’ snorkel set. User selects Location D. Location A10 Location B0 Location C0 Location D0 Not available. Consumption and disposal are blocked. From these scenarios, we derived three key requirements: Show only the items and quantities available at the selected location. Prevent any consumption or disposal quantity greater than the location’s available stock. Route approvals to the person responsible for that location. The Challenge with Standard Item Journals Standard Business Central treats the item journal as a general-purpose adjustment tool, and it trusts the user. For businesses with stock spread across sites, three gaps follow from that. 01 Lookup Shows Company-Wide Stock The Inventory figure on the Item List is the total across all locations unless a location filter is applied. A user sees 200 when only 60 is on their shelf. 02 Location Is Just Another Field Users can select the item first and the location later, or leave it blank, so the system has no location context when the item is chosen. 03 Quantity Isn’t Checked by Location Prevent Negative Inventory is often switched off, only triggers at posting, and gives a storekeeper little guidance. Figure 1: The standard item lookup shows total inventory across all locations, not the stock at the user’s location. Key Design Consideration Location needed to be the starting point of every consumption and disposal line, not an optional detail added afterwards. Filtering the Lookup vs. Validating the Line The first instinct is to filter the item lookup by location. That is useful, but it is not a control on its own. Guides Lookup Filtering Points the user to the right items. It does nothing when someone types an item number directly, pastes lines, or uses Edit in Excel. Enforces Validation Runs whenever the field changes, however the value arrives. Every rule shown in the lookup needs a matching check in table validation and at posting. How a consumption or disposal line moves through the checks Select Location → Item Lookup at Location → Entry Check → Posting Check → Line Posts Designing the Solution We reduced the requirement to four rules that apply to every consumption and disposal line. 1 Location First The user must select the Usage Location Code before the Item No. field becomes editable. The location carries over to the next new line. 2 Show Only What Is There The item lookup lists only items with stock above zero at the selected location, with that location’s quantity. 3 Never More Than Is There The quantity cannot exceed available stock at the location, after subtracting other unposted lines for the same item. 4 Check Again at Posting Stock can change between entering and posting a line, so the same rule runs again just before each line posts. Figure 2: Usage Location Code must be selected before the Item No. field becomes editable. Together, these rules form three layers of control: Layer 1 · Lookup Guides the user to items in stock at the selected location. Layer 2 · Entry Check Blocks over-consumption as soon as the line is entered. Layer 3 · Posting Check Confirms availability against live stock before posting. Filtering the Item Lookup by Location Business Central already calculates stock per location. The Inventory field on the Item table is a FlowField that … Continue reading Location-Based Item Based Visibility in Business Central for a Maldives-Based Marine Services Firm →

Summary Project-based organizations often manage project delivery in Microsoft Dynamics 365 Project Operations while relying on Microsoft Dynamics 365 Business Central for finance, purchasing, inventory, and accounting. Without a connected process, project teams and finance teams can end up working with different versions of the same information. CloudFronts built an integration between Project Operations and Business Central using Dataverse plugins. Instead of relying on users to manually recreate records, the integration responds to important Project Operations events and sends the relevant data to Business Central through web services. It covers customers, projects, timesheets, expenses, invoices, and inventory availability, writes the Business Central identifier back to the originating Project Operations record, and captures failed transactions in an Error Log for troubleshooting. Table of Contents The Project Integration Challenge Our Integration Architecture Keeping Project Customers in Sync Connecting Projects to Business Central Synchronizing Timesheets Moving Project Expenses into Finance Connecting Project Invoices End-to-End Project Integration Flow Business Benefits Key Implementation Considerations Frequently Asked Questions Conclusion About the Example in This Post To show how the integration behaves end to end, the screenshots use a sample customer, Westview Ltd, and its project, Westview-Project-003. These are sandbox records used purely to demonstrate the data flow between Project Operations and Business Central. The Project Integration Challenge Project-based businesses have a unique challenge: the people delivering the project and the people managing its financial impact often work in different systems. Project Operations can be the place where project teams manage customers, projects, resources, tasks, time, expenses, and project billing. Business Central, meanwhile, can be responsible for financial management, purchasing, inventory, and other ERP processes. When these systems are not connected, the same project information may have to be entered more than once. A project manager may record time in Project Operations while finance needs the same information in Business Central. A project invoice may be created in one system while the corresponding financial information needs to be reflected in another. The Core Problem Project teams need to work in the system designed for project delivery, while finance needs accurate and timely information in the ERP. Manual re-entry creates extra effort, delays, and opportunities for data inconsistency. The objective of the integration was therefore not simply to move records between two applications. It was to connect the project lifecycle with the corresponding Business Central processes. Our Integration Architecture The integration uses Dataverse plugins as the event-driven layer connecting Project Operations with Business Central. A Dataverse plugin is a piece of C# code that runs when a Dataverse record is created, updated, or otherwise processed. This provides an opportunity to respond to project-related events and send the relevant information to Business Central. High-Level Flow A user creates or updates a project-related record in Project Operations. The corresponding Dataverse event triggers the plugin. The plugin reads the required information from Dataverse. The data is transformed into the structure required by Business Central. The plugin calls the relevant Business Central web service. Business Central creates or updates the corresponding record. The Business Central identifier is written back to the Project Operations record where required. If the request fails, the integration captures the error and the data involved in an Error Log. Why an Event-Driven Approach? The integration reacts when project information changes, instead of depending on users to remember when and where the same information must be entered. Figure 1: High-level architecture of the Project Operations to Business Central integration. Keeping Project Customers in Sync Customers are a fundamental dependency for project processes. Before project transactions can be represented correctly in Business Central, the corresponding customer needs to exist there. When a customer is created or processed in Project Operations, the integration sends the relevant customer information to Business Central. What the Integration Achieves 01 Create or Sync Creates or synchronizes the customer in Business Central. 02 Map the Fields Uses the appropriate source-to-target field mapping. 03 Capture the Number Captures the Business Central customer number. 04 Write It Back Writes the Business Central identifier back to the originating record where required. This creates an important link between the two systems. The Project Operations record retains the Business Central number, so users do not have to search manually for the corresponding ERP record. In our example, Westview Ltd is created as an account in Project Operations. The integration synchronizes it to Business Central and writes the resulting Business Central customer number (C00280) back onto the Project Operations record. Figure 2: Westview Ltd in Project Operations, with the Business Central customer number (C00280) written back to the int_sourceid field. Figure 3: The corresponding Westview Ltd customer record (C00280) synchronized into Business Central. Connecting Projects to Business Central Customer synchronization is only the beginning. The central object in a project-based integration is the project itself. When a project is created or prepared for synchronization, the integration retrieves the project information required by Business Central and creates the corresponding project record. It then maintains the relationship between the Project Operations project and the Business Central project using the relevant identifiers. Why Project Identifiers Matter A Project Operations record may contain Dataverse identifiers and lookup references, while Business Central works with its own project numbers. These identifiers cannot simply be assumed to be interchangeable. The integration needs to resolve the correct project identifier and use it when subsequent project-related transactions are sent to Business Central. Project Integration Principle Synchronizing a project is not only about copying project fields. It establishes the reference that later transactions, such as time, expenses, materials, and billing, use to reach the correct Business Central project. Continuing the example, Westview-Project-003 is created under Westview Ltd in Project Operations. The integration creates the matching project in Business Central and writes the Business Central project number (PR00340) back to the int_sourceid field on the Project Operations record. Figure 4: Westview-Project-003 in Project Operations, with the Business Central project number (PR00340) written back to int_sourceid. Figure 5: The corresponding Project Card (PR00340) for Westview-Project-003 in Business Central. Synchronizing Timesheets Time is one … Continue reading How to Integrate Dynamics 365 Project Operations with Business Central Using Dataverse →

MRP Batch Trigger Service Summary Planning Optimization (what most F&O teams still call MRP out of habit) normally runs on a fixed recurrence: nightly, or every few hours. That’s fine until an upstream event lands between runs and the plan needs to reflect it before the next window opens. Rather than reconstructing the entire Planning Optimization call from scratch, this post covers a smaller, safer pattern: a custom X++ service that finds the existing, already-configured batch job and flips its status to Waiting, so the batch framework picks it up on its next poll. Same job, same configuration, just triggered early. The example is drawn from an engagement with a North American truck manufacturer, where an upstream integration needed to nudge Master Planning immediately after a data load rather than wait out the scheduled recurrence. On this page 01The business trigger 02Why reuse the batch job, not rebuild the call 03Where the batch job’s RecId comes from 04The service class 05Exposing it as a callable service 06Gotchas worth knowing 07FAQs 08Conclusion The business trigger Planning Optimization is normally left alone once it’s configured: coverage groups, item coverage, and a batch recurrence tell it when to run, and most days that schedule is all anyone needs. The gap shows up when a trigger for a fresh plan doesn’t come from the calendar; it comes from another system. A large sales order import lands late, an engineering change lands mid-afternoon, or an upstream integration finishes a nightly sync on its own schedule, and the planning team needs the recalculated plan before the next window opens, not after. Manually opening Master Planning parameters and clicking “Run now” doesn’t scale when the trigger has to come from outside the ERP entirely. Why reuse the batch job, not rebuild the call Planning Optimization isn’t a simple in-process function call. The batch task hands off to an Azure-hosted optimization engine, carrying policy and configuration that already lives in Master Planning setup: coverage groups, item coverage codes, the plan itself. Reconstructing that entire call from a custom service would mean duplicating configuration the system already tracks, and keeping two copies of it in sync forever. The simpler move: find the batch job the system already runs on its recurrence, and change its status so the batch framework picks it up on the next poll instead of waiting for the scheduled time. Same job, same configuration, just triggered early. Where the batch job’s RecId comes from The service doesn’t look the batch job up by caption at runtime; captions get renamed, retranslated, or duplicated, which makes name-matching fragile. Instead, the correct job’s RecId is captured once, during setup, and stored on a custom parameters table (here, a field on ReqParameters). The trigger call then becomes a single indexed select instead of a caption search. Ops note: because the pointer is a raw RecId, it breaks silently if the batch job is ever deleted and recreated. An LCS environment refresh or a redeploy of the batch setup is enough to do it. Re-capture and re-save the RecId as part of any environment refresh checklist. The service class The method is deliberately thin: find the configured batch job, flip its status inside a transaction, and report back what happened. CFMRPOptimizationBatchTriggerService.xpp internal final class CFMRPOptimizationBatchTriggerService { public CFMRPOptBatchTriggerServiceResponseContract triggerMRPOptBatchJob() { CFMRPOptBatchTriggerServiceResponseContract response = new CFMRPOptBatchTriggerServiceResponseContract(); try { BatchJob batchJob; select firstOnly forUpdate batchJob where batchJob.RecId == ReqParameters::find().MRPOptBatchJobRefRecId; if (!batchJob.RecId) { response.parmMessage(“Planning Optimization batch job was not found.”); } else if (batchJob) { ttsbegin; batchJob.selectForUpdate(true); batchJob.Status = BatchStatus::Waiting; batchJob.update(); ttscommit; response.parmMessage(strFmt( “Planning optimization batch job found and triggered. ID: %1, Description: %2, Status: %3”, batchJob.RecId, batchJob.Caption, enum2Str(batchJob.Status))); } } catch (Exception::Error) { response.parmMessage(“Trigger failed”); } return response; } } Three things worth calling out in that order of execution: The initial select firstOnly forUpdate locates the job and prepares it for a later update, but it sits outside any transaction at that point. The real lock happens with the selectForUpdate(true) call just before ttsbegin, which is what actually matters for correctness under concurrent triggers. Flipping Status to Waiting is the entire “trigger.” Nothing here talks to the Planning Optimization engine directly; that’s the batch framework’s job once it sees a waiting task. The response contract carries a single human-readable message, which is enough for a calling system to log success or failure without needing to parse the batch job’s internal state itself. Exposing it as a callable service The class itself is just X++. Making it callable from outside the ERP is a standard AOT step: 1Add an AOT Service node referencing this class and the triggerMRPOptBatchJob method. 2Add the service to a Service Group and deploy. F&O exposes it over the standard integration endpoint once deployed, callable from an integration platform or middleware without any custom endpoint code. 3Have the calling system read parmMessage to confirm the job was actually found and flipped, rather than treating a successful call as proof that MRP ran. The trigger is fire-and-forget from the batch engine’s side. Gotchas worth knowing “Waiting” is not “running now.” The status change queues the job for the batch server’s next poll, typically seconds to a couple of minutes later depending on batch server load, not a synchronous MRP run. Don’t build a caller that blocks waiting for a result. The catch block swallows the real error. catch (Exception::Error) returns a flat “Trigger failed” with no diagnostic detail retained. That’s fine for a demo; in production it means the caller, and whoever gets paged, has no idea why it failed. Worth extending to log the actual exception before returning the generic message. Retriggering a running job is harmless, but a symptom. Flipping an already-Executing job back to Waiting doesn’t start a second concurrent run. If a caller is doing that repeatedly in a tight retry loop, though, it’s usually a sign the caller isn’t checking the response message before retrying. “A trigger service doesn’t need to reimplement what Master Planning already knows how to run. It only needs to … Continue reading How a Leading North American Commercial Vehicle Manufacturer Triggers MRP On Demand Using a Custom X++ Service in Dynamics 365 Finance & Operations →

Summary A Houston based cybersecurity company came to us with a familiar complaint. Their sales leaders had everything they needed sitting in Dynamics 365, yet every Monday review still started in Excel. They asked for two things: their reports laid out the way they actually think about the business, and an assistant they could simply ask questions. We delivered both in one app, built with Power Apps Code Apps on top of the CRM data they already had. In This Blog What was slowing the sales team down What we built for them, screen by screen The AI agent we added so leaders can just ask What changed for the business How to tell if this approach fits your team Table of Contents Summary→ Business Challenges→ What We Built→ The AI Agent→ How It Works→ Impact→ Is This Right for You?→ Conclusion→ FAQ→ Get in Touch→ Business Challenges Nothing was broken. The data was good and the team was using the CRM. The trouble was getting answers out of it quickly. A standard view shows you a list of records, which is great when you are working a lead. It is far less helpful when the sales director wants to know how many leads turned into real opportunities this quarter, and who brought them in. So the weekly routine looked like this: Open one view, then another, then a third, to piece the funnel together. Export everything to Excel and rebuild the same pivot table as last week. Walk into the meeting with numbers that were already a few days old. What the team really wanted was simple: better looking reports they could read at a glance, and an AI agent alongside them to answer the questions the reports did not cover. Before Several views to see one picture Weekly exports and pivot tables Numbers out of date by meeting time After Key numbers on the first screen One set of filters for everything Answers by simply asking What We Built Power Apps Code Apps let us design the screens completely from scratch while still reading the same Dynamics 365 data, live. Think of it as a new front door to the CRM, arranged around the questions the leadership team asks every week. Nothing was copied or moved anywhere else. The app has four pages, and they all work the same way, so people only learn it once: LeadsWhere new interest comes from and how much of it qualifies. OpportunitiesThe live pipeline, in the order leadership reviews it. SalesWhat has closed and how the team is tracking. ProjectsWhat happens after the deal is won, from Project Operations. Each page opens with the headline numbers, such as total leads, open leads, qualified leads and the qualification rate. Below that sits a single filter bar for owner, status, account, dates and search. Change one filter and every number, chart and list on the page updates with it. The summary page: headline numbers, a trend over time, and breakdowns by customer, source and owner. Shown with demo data. When a chart raises a question, the detail page shows the actual records behind it, already filtered the same way. The detail page, using the same filters as the charts. Shown with demo data. The AI Agent The second half of the request was an assistant. Code Apps do not include one, so we built our own AI agent and placed it in a side panel inside the app. Leaders type a question the way they would ask a colleague, and the agent answers from the live CRM data. Questions like which lead came in most recently, which owner has the best qualification rate this quarter, or which accounts have open deals but no new leads. Things that used to need an export now take a few seconds. In practice this is the feature people mention first when they talk about the app. Want to see how the agent itself was built? We covered that in our earlier post on how we connected an Azure AI Foundry agent to Dynamics 365 for the same client. The AI agent answering a question about the most recent active lead. Shown with demo data. How It Works You do not need to be technical to follow this. There are really only four moving parts. Step oneSign in as usualSame Microsoft account, nothing new to remember Step twoPower Apps opens the appInside the platform you already use Step threeYour custom screensNumbers, charts and lists in your layout Step fourLive CRM dataAlways current, never copied How the pieces fit together, including the AI agent. A few things matter here for the business. People only see the records they were already allowed to see in Dynamics 365. There is no separate portal to pay for or look after. And because the app sits inside a normal Dynamics 365 solution, moving it from testing to live was as routine as any other release. Worth knowing before you start Users cannot save their own personal views in this kind of app, so the filters need to be planned with the team up front. Very heavy reporting may still be better in Power BI. And it is built by a developer rather than configured, so plan for someone to own small changes after go live. Impact One place for the whole story. Leads, pipeline, sales and delivery sit side by side instead of in four corners of the CRM. Questions get answered on the spot. The AI agent handles the ones nobody built a chart for. No new licences or logins. It runs on what the client already owned, under the security they already manage. Is This Right for You? Code Apps are not a replacement for everything in Dynamics 365. This is how we usually explain the choice to clients. This projectCode App Standard Dynamics 365 app Power Pages Who it is for Your own team, when they need a view built around their role Your own team, for everyday record work … Continue reading How a U.S. Industrial Cybersecurity Company Built a Custom Sales Portal with Power Apps Code Apps →

Please find this CloudFronts Product at – Integration Module between Dynamics 365 Project Operations and Finance & Operations | Microsoft Marketplace Summary Manually creating custom fields in Dynamics 365 Project Operations across multiple environments is time-consuming, error-prone, and blocks automation. This challenge can be addressed by using Dataverse Metadata OData APIs to programmatically create, update, and publish custom attributes during deployment. The process involves authenticating with Azure AD, calling Metadata API endpoints to create attributes, and publishing the changes with the PublishXml action, all through a fully automated approach. As a result, organizations achieve zero manual intervention, environment consistency, integrations, reduced human error, and a reusable framework that can be applied across all field types. Please find this CloudFronts Product at – CloudFronts – PO-FO Connector Table of Contents Introduction Business Challenge Why OData Metadata APIs? Implementation Procedure End-to-End Working Why This Approach Works Real-World Use Cases Conclusion Introduction When integrating external business applications with Microsoft Dynamics 365 Project Operations, it is common to discover that every customer requires additional fields to store information originating from ERP systems, manufacturing platforms, pricing engines, or product lifecycle management systems. For one of our internal projects & Prospect PoC implementing product-centric integrations, we needed a way to provision these custom fields automatically during deployment. Traditionally, creating new columns involves opening the Power Apps Maker Portal, adding fields manually, publishing the table, exporting a solution, and repeating the same process across multiple environments. While this approach works for occasional changes, it quickly becomes a bottleneck for automated deployments and CI/CD pipelines. The Solution: CloudFronts implemented a fully automated approach using the Dataverse Metadata OData APIs, enabling integration deployments to create and publish new Project Operations attributes programmatically. Business Challenge The customer’s integration platform exchanged large volumes of product and financial information with Dynamics 365 Project Operations. Each deployment required several custom attributes such as: Product identifiers ERP reference numbers Financial synchronization IDs External integration keys Processing status fields Creating these fields manually across Development, Test, UAT, and Production introduced several challenges: Manual configuration effort (time-intensive) Human errors (typos, misconfigurations) Environment inconsistencies (field variations across environments) Longer deployment windows Difficult CI/CD automation The Objective: Allow the deployment process itself to provision any missing attributes before importing data, eliminating manual touchpoints entirely. Why OData Metadata APIs? Most developers use the Dataverse Web API for CRUD operations on business records. However, Dataverse also exposes Metadata APIs, allowing developers to programmatically manage the schema itself—including tables, columns, relationships, and option sets. Microsoft documents creating attribute metadata by posting to the Attributes navigation property of an entity definition. This means integrations can: Create new columns dynamically Update existing metadata Publish customizations instantly Eliminate manual portal work Scale across multiple environments consistently Unlike traditional manual solutions, the Metadata API approach is fully programmable, auditable, and repeatable. Implementation Procedure Step 1 – Authenticate with Dataverse The integration first authenticates against Azure Active Directory using an application registration and retrieves an OAuth Bearer Token. That token is then supplied with every Metadata API request. Authentication Flow: Register application in Azure AD Configure permissions for Dataverse access Obtain OAuth 2.0 Bearer Token Include token in Authorization header for all API calls Step 2 – Creating a Custom Attribute The Dataverse Metadata API exposes the following endpoint for creating new attributes: POST /api/data/v9.2/EntityDefinitions(LogicalName=’msdyn_contractlineinvoiceschedule’)/Attributes Instead of creating business records, this endpoint creates metadata at the schema level. For this implementation, we created a new string attribute with the following properties: Schema Name: int_fnoid Display Name: FNO ID Data Type: String Maximum Length: 100 The request body uses the Microsoft.Dynamics.CRM.StringAttributeMetadata type together with standard metadata properties such as SchemaName, DisplayName, RequiredLevel, and MaxLength. Supported Metadata Types: Microsoft supports multiple metadata types through the same endpoint including String, Decimal, Boolean, Picklist, DateTime, Lookup, Currency, and more. Step 3 – Publishing the Metadata Creating an attribute does not immediately make it available. Like changes made through the Power Apps Maker Portal, metadata created through the Web API must also be published. This is accomplished using the PublishXml action. POST /api/data/v9.2/PublishXml The request specifies the entity to publish. After publishing completes successfully, the new attribute immediately becomes available throughout Dynamics 365. End-to-End Working The complete deployment process follows these steps: Integration authenticates with Azure AD. Dataverse access token is generated. Metadata API checks whether the required attribute exists. Missing attributes are created automatically. PublishXml is executed. New attributes become available. Product synchronization begins. External systems start populating the new fields immediately. Integration Points: This Attribute creation setup can be utilized across Logic Apps, Plugins, Azure Functions, and other Custom Workflows. Why This Approach Works ✓ Fully Automated Deployments No manual intervention is required when new integration fields are introduced. ✓ Environment Consistency Development, Test, UAT, and Production remain synchronized because every environment provisions the same metadata through code. ✓ CI/CD Friendly Metadata creation can be incorporated directly into Azure DevOps or GitHub deployment pipelines. ✓ Reusable Framework The same framework can create String, Decimal, Currency, Lookup, Date, Option Sets, and Boolean fields. ✓ Reduced Human Error Eliminates mistakes caused by manual customization and inconsistent naming conventions. ✓ Prevented Duplication Eliminates duplication of records, preventing system garbage in the database. Real-World Use Cases Use Case 1: PO-FO Integration (Project Operations to Finance Operations) For enterprises running integrated Project Operations and Finance Operations modules, this approach ensures that: ERP reference numbers sync automatically across all linked tables Financial synchronization IDs are created before data import External integration keys propagate consistently Processing status tracking fields exist in all dependent entities No manual re-entry of attribute definitions across environments Impact: Reduces deployment time from hours to minutes, eliminates sync mismatches between PO and FO modules, and enables real-time data reconciliation. Conclusion For an internal project and prospect PoC implementing product-centric integrations, automating metadata creation transforms what was previously a manual administrative task into a repeatable deployment process. Rather than relying on solution imports or manual customization through the Power Apps Maker Portal, integrations can now provision required Project Operations attributes on demand … Continue reading Automating Attribute creation in D365 Project Operations, Using Dataverse OData Metadata APIs for an Internal Project Operations–Finance & Operations Integration →