Wednesday, December 31, 2025
Arindam's AX World: LCS to PPAC: Transitioning Dynamics 365 Finance &...
Arindam's AX World: LCS to PPAC: Transitioning Dynamics 365 Finance &...: LCS to PPAC: Transitioning Dynamics 365 Finance & Operations Administration Arindam Chakravorty Project Management | Technical Projec...
LCS to PPAC: Transitioning Dynamics 365 Finance & Operations Administration
For years, Lifecycle Services (LCS) has been the home base for Dynamics 365 Finance & Operations, but Microsoft is modernizing the administration and lifecycle management experience. Microsoft is moving key support and administration capabilities into the Power Platform Admin Center (PPAC). A key part of this evolution is the transition from Lifecycle Services (LCS) to the Power Platform Admin Center (PPAC) as the primary operational and administrative hub. This shift is more than a UI change; it is a step toward a unified admin experience across Dynamics 365, Power Apps, and the wider Power Platform.
Lifecycle Services (LCS) has historically been the central portal for:
- Environment lifecycle management (deploy, maintain, retire)
- Diagnostics and issue search
- Monitoring and telemetry
- Service requests and support tickets
- Asset libraries and implementation methodologies
While powerful, LCS was tightly coupled to F&O and operated as a separate administrative experience from the broader Power Platform ecosystem.
Why Microsoft is moving from LCS to PPAC
The move to PPAC is driven by the need to simplify administration across the Microsoft business applications stack. Instead of juggling multiple portals, organizations can manage environments, capacity, and some support and monitoring functions in a single place.
Key reasons for the transition:
- Unified admin experience across Power Platform, Dynamics 365 apps, and Dataverse, improving consistency for IT teams.
- Better alignment with modern application lifecycle management (ALM) patterns using Azure DevOps and Power Platform tools.
- Future feature investments are focused on PPAC, meaning new monitoring, governance, and AI capabilities will be introduced there first.
- Deeper integration with Azure, Fabric, and Copilot.
What Has Already Moved (or Is Moving) to PPAC
As of recent platform updates, the following capabilities are available or transitioning into PPAC:
Environment Management
- View and manage F&O environments
- Environment details (tier, region, version)
- Environment lifecycle operations (start/stop, maintenance visibility)
Deployment & Updates
- Platform update orchestration visibility
- One-click servicing operations (progressively replacing LCS flows)
Monitoring & Health
- Environmental health status
- Service availability and incidents (integrated with Microsoft 365 admin experiences)
Security & Governance
- Environment-level access management
- Integration with Azure AD / Entra ID
- Alignment with Power Platform environment governance policies
LCS is not disappearing overnight. Certain advanced diagnostics, methodology assets, and issue search capabilities may continue to exist during the transition period.
What Still Remains in LCS (for Now)
Some capabilities are still LCS-dependent or only partially surfaced in PPAC:
- Issue Search and Diagnostics (SQL traces, performance tools)
- BPM libraries and implementation methodology
- Legacy asset libraries
- Some support workflows
Microsoft has indicated that these will either be:
- Migrated into PPAC, or
- Replaced by modern equivalents integrated with Azure and Power Platform tooling
Impact to Partners and ISVs
For ISVs and implementation partners, this shift has several implications:
- Operational readiness: Teams must become fluent in PPAC operations
- ALM and CI/CD: Deployment pipelines increasingly align with Power Platform and Azure DevOps standards
- Support models: Customer admin experiences are changing, requiring updated documentation and training
- Fabric & Analytics alignment: PPAC becomes the gateway for analytics-enabled architectures (Synapse Link, Fabric, Copilot)
ISVs should update installation guides, runbooks, and support processes to reflect PPAC-based administration.
Impact to Customers
For System Administrators
- F&O environments now appear alongside Power Platform environments
- Reduced need to switch between portals
- Improved visibility across integrated solutions (F&O + CE + Power Apps)
For IT & Governance Teams
- Centralized compliance, DLP, and access policies
- Better alignment with enterprise cloud governance models
- Simplified audit and monitoring posture
How this benefits your long‑term roadmap
While the transition introduces short‑term change, it positions organizations for a more integrated and future‑proof Dynamics 365 landscape. By embracing PPAC early, teams can standardize governance, unlock new platform features, and simplify cross‑app administration.
Long‑term advantages include:
- Stronger governance and monitoring across all Power Platform and Dynamics apps in one portal.
- Easier adoption of new add‑ins, AI features, and unified ALM capabilities that assume PPAC‑based management.
- Reduced operational complexity as LCS is de‑emphasized and PPAC becomes the strategic home for administration.
LCS vs PPAC Feature Parity – Dynamics 365 Finance & Operations.
LCS has served the F&O community well for many years. PPAC represents the next evolution—one that aligns ERP, low-code, analytics, and AI under a single administrative umbrella.
Understanding and preparing for this transition is no longer optional; it is a key part of operating D365 Finance & Operations in Microsoft’s modern cloud ecosystem.
Reference : https://learn.microsoft.com/en-us/power-platform/admin/unified-experience/finance-operations-apps-overview
#D365 #dynamics365 #MicrosoftDynamics #FinanceandOperation #LCS #PPAC #PowerPlatform #ERP #ISV #ALM #D365FO #MicrosoftEcosystem #CloudGovernance
Tuesday, March 6, 2018
Integration framework of Dynamics 365 for Operations
Integration framework: In D365 the integration framework is a framework that enables data flow between different application. It starts with Data Entity. Data Entity is a new concept in Microsoft Dynamics 365 for Finance and Operations. A major part of the integrations is based on Data entity that is deeply embedded at the kernel level.
Data Entities: According to the MSDN, Data entities provide conceptual abstraction and encapsulation of underlying table schema that represents data concepts and functionalities.
Data Entities are updatable views. They have replaced previous concepts in Microsoft Dynamics AX, including AXD, the Data/Import Export Framework (DIXF), and aggregate queries. Data Entities provide a single pack of records that capture business logic and enables scenarios like import and export, integration and programmability. It can also be exposed as OData services for some other third-party integration.
In D365, when we create a new customer through a Customer Form we not only provide basic information about the customer, but also other important additional information, like addresses, credit limit, tax details etc. All the records internally don’t get stored in a single table. It is scattered among a small set of related tables (LogisticPostalAddress, LogisticElectronicAddress, DirParty etc.). During a customer record creation from an external application we must take care of all the mandatory fields across all those related tables. A data entity encapsulates all these tables and exposes the fields that we want to update. The customer data entity is an updatable view in which each row contains all the data from the customer table and its related tables.
There are few highlights of Data Entities -
- Microsoft shipped 1800+ out of the box Data entities and counting.
- Customer/ISVs can extend all out of the box existing entities or add new entities based on their business requirement.
-- Out of the box Sales Order entities can be used and consumed from any third party application for further processing.
-- ISVs can create new Data entities and use those across their integration.
For example, an ISV is developing an interface or add-ins where separate configuration and master tables need to be updated from other .NET based application. In this scenario the ISV needs to create new Data Entity as per the requirement
- Composite entity is another useful and interesting feature of D365 that I mentioned above.
For example, a Sales Order document consists of several tables in D365. In this process, there are some mandatory fields and some optional fields. A composite entity takes care of that. A composite entity contains only the fields that you want to update from an outside application. If you are using Data Entities then missing on a mandatory field will not return any run time error. It will be handled internally by D365.
There are a couple of ways Data entities can be created.
a. Using out of the box Wizard
b. Programmatically using API
Data entities are exposed to the outer world through Data Management Platform and OData Services. For an Asynchronous Integration Data Management Platform is used and Synchronous integration uses OData service.
Data Management Platform:
Data Management Platform is a platform that facilitates data exchange between systems. Any data that goes through Data Management Platform goes through staging tables.
This platform is used for File-based integration and Application lifecycle management.
The data management framework allows us to:
· Move data between two similar systems. For example, between D365FO Development and Production.
· Maintain a reusable library of data templates and datasets.
· Use data packages to create incremental data entities. Data entities can be sequenced inside the packages. You can name data packages, which can be easily identifiable during import or export. When building data packages, data entities can be mapped to staging tables in grids or by using a visual mapping tool.
· Validate and compare view data during imports.
File based Integration – Like any other ERP applications, a file import and export are an important feature in D365. This feature can be used for various purposes. For example, any hourly machine rate updates, sales tax rate updates, exchange rate update etc. There are generally two types of integration.
a. File Import/export - This is an interactive and attendant integration. A rate table, sales update, employee timesheet are some typical examples of that. Initial data migration, copy configuration are some examples of it.
b. Recurring integration – This is an unattended asynchronous integration, end of the day kind of batch process. Daily export of sales data, weekly GL export in a file and folder are some examples.
Application lifecycle management – In an implementation, we often need to copy the master data and other configurations related to settings. Also, data migration between UAT environment and production environment. Application lifecycle management takes care of all these.
a. Copy integration – Data Migration Framework can be used to copy configurations data across companies or environments. It also can configure processes or modules using Microsoft Dynamics Lifecycle Services (LCS).
b. Data migration between systems – This is a data migration or initial data load scenario. After a successful UAT testing of D365, the environment will need to roll over to the production.
Microsoft Dynamics Lifecycle Services (LCS) is used for both the above scenarios.
OData Service : OData is a standard protocol for creating and consuming data. OData uses web technologies such as HTTP and JSON to provide access to information from various mobile or third-party programs. A Data entity is automatically exposed as OData service. Once done Office integration and mobile integration can talk with D365 through OData REST based endpoints. This is a synchronized integration between D365 and any real-time mobile or office apps.
OData also worked with Power BI. Power BI Desktop connects to the OData feed and accesses the available tables and other data elements.
Custom Service : The last bit of integration is the custom services from the old flavor of AX 2012. Custom service features are still supported in D365. Out of the box or custom X++classes can be exposed as custom service to cater with any custom integration requirement. These custom services are consumed from outside applications to read and update D365 tables based on custom business scenarios. In D365 while creating a custom service and exposing it, it automatically creates two service endpoints.
· JASON/REST endpoint
· SOAP/XML endpoint
Custom services are used to integrate with third-party applications and add-ons. In a specific business scenario where an integration is needed with other ERP systems like SAP, custom services are generally used for handshaking. Based on business needs and technology preference D365 integration is possible across the environments.
Subscribe to:
Comments (Atom)