The Three Deployment Types of Dynamics 365 Project Operations
A practical guide for Finance & Operations consultants
Many people still assume Dynamics 365 Project Operations is a single solution that you simply “turn on” across Dynamics apps.
In reality, Microsoft designed it as three different deployment types, each targeting a different operational scenario and architecture.
Choosing the correct deployment model early is one of the most important decisions in a Project Operations implementation—because it determines:
- where project data lives
- where financial transactions are posted
- how invoicing and revenue recognition work
- how Dataverse and Finance interact
Why the deployment choice matters early
One important point that Microsoft emphasizes is that the deployment type should be selected at the beginning of the implementation.
Each deployment option uses a different architecture, data model, and integration pattern between Dataverse and Finance. Because of this, switching from one deployment model to another later in the project can become very complex and costly.
Changing deployment types may require:
- redesigning project processes
- rebuilding integrations
- migrating project data
- reconfiguring financial posting logic
For that reason, the deployment choice should be treated as an architectural decision, not just a functional preference.
Below is a practical explanation of the three official deployment types and what they mean for Dynamics 365 Finance & Operations consultants.
1️⃣ Project Operations Core
Project Operations Core architecture: project delivery fully managed in Dataverse
Project Operations Core is the Dataverse-based deployment.
It focuses primarily on project sales and delivery management, without relying on the Finance ERP engine.
Main capabilities
This model supports:
- Project sales
- Project planning
- Resource management
- Subcontracting
- Time, expense, and material usage
- Project execution
- Budget tracking
- Proforma invoicing
In this deployment, the operational lifecycle effectively ends at the proforma invoice stage.
Financial processes such as:
- invoicing
- revenue recognition
- project accounting
are not handled in Finance & Operations.
Typical scenarios
This model is designed for organizations that primarily need:
- resource planning
- project delivery coordination
- time and expense tracking
- project-based sales
Typical examples include:
- consulting firms
- digital agencies
- professional services companies without complex ERP finance requirements
Implications for F&O consultants
Finance & Operations is generally not part of this architecture.
Most of the solution runs entirely within Dataverse and Dynamics 365 apps, meaning ERP involvement is minimal.
2️⃣ Project Operations Integrated with ERP
Integrated deployment architecture: Dataverse runs project delivery, Finance controls the money.
This deployment combines Dataverse applications with Dynamics 365 Finance.
It is the most common architecture in enterprise implementations.
In this model, responsibilities are split between the two platforms.
Dataverse handles
- Project sales
- Project planning
- Resource management
- Subcontracting
- Time and material usage
- Project execution and budget tracking
- Proforma invoice review
Finance & Operations handles
- Expense processing
- Invoicing
- Revenue recognition
- Project accounting
This creates a natural separation between:
Front-office project delivery (Dataverse) and Back-office financial control (Finance).
Why organizations choose this model
This architecture works well for companies that need:
- full ERP financial governance
- compliant revenue recognition
- integrated project accounting
- strong collaboration between delivery teams and finance teams
Industries where this model is common include:
- IT services
- consulting
- engineering firms
- large professional services organizations
Implications for F&O consultants
This deployment introduces the most architectural complexity.
Key areas that must be designed carefully include:
- data ownership between Dataverse and Finance
- project creation rules
- invoice processing flows
- integration and synchronization between systems
When those boundaries are unclear, projects often run into issues such as:
- duplicate records
- synchronization conflicts
- financial inconsistencies
3️⃣ Project Operations for Manufacturing
ERP-first architecture: project execution and financial control managed directly in Dynamics 365 Finance.
The third deployment type is designed for organizations where projects are closely tied to operational execution or manufacturing activities.
In this configuration, the solution is largely centered in Finance & Operations.
Main capabilities
- Project sales
- Project planning
- Resource management
- Time entry
- Expense management
- Invoicing
- Revenue recognition
- Project accounting
Compared with the integrated model, many of these capabilities are handled directly inside Finance & Operations, reducing cross-platform dependencies.
Typical scenarios
This model is commonly used when projects are closely linked to operational delivery, such as:
- manufacturing organizations delivering project-based work
- equipment installation projects
- industrial services tied to production operations
Implications for F&O consultants
For ERP teams, this deployment often feels the most familiar because:
- project management and financial transactions live primarily in Finance
- the architecture involves fewer cross-platform integrations
The Real Architectural Decision
The key message from Microsoft is that Project Operations is not just a product—it is an architectural model.
Each deployment type determines where responsibility sits.
Project Operations isn't just a product - it is an architecture decision
Selecting the correct deployment early impacts:
- solution architecture
- data ownership
- integration complexity
- licensing
- implementation risk
Switching deployment models later can require significant redesign of processes and integrations.
Advice for ERP Architects
Before starting a Project Operations implementation, align stakeholders around a few fundamental questions:
1️⃣ Where are projects created and managed?
2️⃣ Where are financial transactions posted?
3️⃣ Where are invoices generated?
4️⃣ Which system owns revenue recognition?
5️⃣ How will project data synchronize between platforms?
Clear answers to these questions dramatically reduce implementation risk.
Deployment models can differ between legal entities
Another detail that is often overlooked is that the deployment type does not have to be the same for every legal entity.
Large organizations sometimes run different Project Operations footprints in different entities, depending on their operational model.
For example:
- a consulting subsidiary may use Project Operations Core
- a services organization may use Project Operations Integrated with ERP
- a manufacturing business unit may use Project Operations for Manufacturing
This flexibility allows companies to align the solution with how each business unit actually operates, while still staying within the overall Dynamics ecosystem.
For solution architects, this means deployment decisions should be evaluated per legal entity and per operating model, rather than assuming a single configuration for the entire organization.
Final Thought
Microsoft’s Project Operations strategy reflects a broader trend in the Dynamics ecosystem:
Operational workflows increasingly live in Dataverse experiences, while financial governance remains in ERP.
Understanding how these two worlds interact is becoming a core skill for Dynamics architects.
For Finance & Operations consultants, the most impactful deployments will usually be:
- Project Operations Integrated with ERP
- Project Operations for Manufacturing
Because this is where project delivery meets financial control.
And as anyone who has worked on ERP implementations knows:
the hardest part is never the technology.
It is deciding which system owns the truth.