I've seen Dynamics 365 implementations start with relatively simple requirements and gradually accumulate more users, business groups, data, automation, integrations, customizations, and business rules.

Usually, there isn't one major architectural mistake.

The challenge comes from the combination of many small decisions made over time.

Earlier in my career, when I thought about scalability, I mostly thought about performance and data volume.

Today, I look at it differently.

For me, a scalable CRM platform should be able to absorb growth without constantly forcing the organization to redesign it.

That growth can come from data, users, business groups, automation, integrations, operational complexity, and changing business requirements.

Here are some of the lessons I've learned from working on enterprise Dynamics 365 implementations.

1. Scalability Is More Than Record Count

Most scalability discussions start with:

"How many records will we have?"

That's an important question, but it is only one part of the picture.

I generally think about scalability across several dimensions:

Data — more records and larger datasets
Users — more users and business groups
Logic — more business rules and customizations
Automation — more executions and background processing
Integration — more connected systems
Operations — more monitoring, failures, and support
Change — more requirements over time

A solution may handle a large number of records and still become difficult to maintain because hundreds of Plugins, flows, scripts, integrations, and security rules have accumulated around those records.

So for me:

Scalability is not just about handling more data. It is about handling more complexity without losing control of the platform.

2. Design for Organizational Growth

One pattern I've seen across different implementations is multiple business groups using the same Dynamics 365 environment and common Dataverse tables.

Initially, this is often the right approach.

We don't necessarily want separate tables or applications for every business group.

But the organization changes.

More business groups join. More users are added. More records are created. More business-specific requirements appear.

The questions we need to ask also change:

• How will users access the data?

• Are views and queries designed appropriately?

• How will security scale?

• How much automation is triggered?

• How will integrations consume the data?

• What happens when the data volume increases significantly?

Security is part of scalability as well.

Business units, teams, ownership, security roles, and access levels need to be designed with future growth in mind.

If adding another business group requires significant custom code or a completely new security model, the solution isn't really scaling with the organization.

One question I like to ask early is:

"What will this solution look like three years from now?"

Not just:

"What do we need today?"

3. Control Customization and Automation

Enterprise CRM solutions naturally accumulate customizations.

Plugins.

JavaScript.

Custom APIs.

Power Automate.

Integration components.

Each decision may have been perfectly reasonable when it was introduced.

The problem starts when those decisions accumulate over several years.

I've seen relatively simple requirements gradually become combinations of Plugins, flows, scripts, and other custom components.

The solution still works.

But understanding it becomes difficult.

My approach today is:

Use custom code when it provides clear business or technical value — not simply because the platform can be customized.

This becomes particularly important with Plugins.

A Plugin that executes occasionally is one thing.

A Plugin that executes repeatedly across thousands or millions of transactions is a workload.

I've encountered scenarios involving status changes and other common operations where multiple pieces of logic were triggered by the same business event.

The execution path can gradually become:

Record Update → Plugin → Automation → Additional Update → More Processing

Each component may look reasonable individually.

The combined execution path may not be.

That's why I pay attention to things such as:

Plugin registration and filtering Unnecessary data retrieval Synchronous processing Repeated updates External calls Error handling

One principle I've learned is:

A platform limit is not a performance target.

The same thinking applies to Power Automate.

I've used Power Automate for processes such as approvals where it was a much more practical choice than developing and maintaining custom Plugin code.

At the same time, I've seen flows become difficult to troubleshoot, take longer than expected, or become increasingly complicated as requirements changed.

Data migration is another example.

A flow that works well for a small number of records may not be the right approach for a large migration workload.

So the question isn't simply:

"Can Power Automate do this?"

It is:

"Is Power Automate the right execution model for this workload?"

This is where the decision framework from Enterprise CRM Insights #2 — Plugin vs. Power Automate becomes important.

4. Choose the Right Integration and Data Boundary

Another pattern I've seen repeatedly is the evolution from a few integrations into an ecosystem of integrations.

It may start with:

Dynamics 365 → System A

Then:

Dynamics 365 → System A, B, C

Eventually, multiple applications need to communicate with multiple other applications.

At that point, point-to-point integration can become increasingly difficult to manage.

This is where an Enterprise Integration Platform, messaging, or Service Bus-based architecture can become valuable.

The objective isn't to introduce another layer simply because it is considered a best practice.

It is about capabilities such as:

• Decoupling

• Routing

• Transformation

• Retry

• Monitoring

• Error handling

• Asynchronous processing

One question I ask when reviewing an integration design is:

"What happens when this isn't three integrations anymore, but thirty?"

The same principle applies to data.

I've worked on scenarios where data that wasn't required for day-to-day CRM operations was better suited to an external platform such as SQL.

The important architectural question is:

"Does this data need to live in Dataverse, or does the business process simply need access to this data?"

Those are very different requirements.

Dataverse can be the right platform for operational CRM data.

External storage may be more appropriate for certain large, historical, analytical, or specialized workloads.

The answer isn't that one technology is always better.

The right platform depends on the workload.

5. When Search Becomes an Architecture Problem

Search is an interesting example because it sits between user experience, data access, and architecture.

Dataverse Search has evolved considerably and supports capabilities such as relevance-based results and fuzzy search.

So the question shouldn't be:

"Can Dataverse Search do fuzzy search?"

It can.

The more useful architectural question is:

"Does the search requirement still belong entirely within the CRM search model?"

Imagine the requirement grows from searching customer records in Dataverse to:

• Searching across multiple enterprise data sources

• Combining CRM and external customer repositories

• Applying organization-specific relevance rules

• Ranking results across different sources

• Supporting more sophisticated matching

• Providing a unified search experience

At that point, the challenge isn't simply whether Dataverse can perform a search.

It becomes a question of search architecture.

The search capability may need its own indexing, ranking, ingestion, and synchronization strategy while Dataverse remains the operational CRM system.

This is an important distinction:

The scalability question is not "Can Dataverse search?" It is "Where should enterprise search responsibility live as the search workload grows?"

6. Architecture Debt Usually Arrives One Small Decision at a Time

Most technical debt doesn't arrive as one large architectural mistake.

It usually arrives as a series of reasonable decisions:

"We'll add one more Plugin."

"We'll add one more flow."

"We'll store this data in Dataverse for now."

"We'll add a small JavaScript validation."

"We'll integrate directly; it's only one system."

None of these decisions necessarily looks wrong.

But imagine making hundreds of similar decisions over five years.

Eventually, the organization isn't dealing with one bad architectural decision.

It is dealing with the interaction between hundreds of small decisions.

That's where architecture debt becomes difficult.

This is also why simplicity is an important part of scalability.

We often focus on what we should add:

Azure Functions.

Service Bus.

Additional databases.

Caching.

Search platforms.

Integration layers.

Sometimes those are exactly the right choices.

But every additional component introduces another dependency, operational responsibility, and potential failure point.

So I deliberately ask:

"Can we solve this without introducing another component?"

If yes, that may actually be the better architecture.

Don't under-engineer the solution.

But equally:

Don't over-engineer it simply because we can.

7. Standards, Operations and Testing Matter

Scalability isn't only about runtime performance.

It is also about the people building and operating the platform.

As more developers, teams, vendors, and business groups work on the same CRM platform, standards become increasingly important.

This includes:

• Naming conventions

• Plugin and JavaScript standards

• Power Automate standards

• Solution structure

• Error handling

• Logging

• Security

• ALM

• Code reviews

• Reusable components

The objective isn't bureaucracy.

It is consistency.

Standards allow a platform to grow without every new developer increasing its complexity.

Operations matter as well.

A solution that performs well but is difficult to monitor, troubleshoot, deploy, or recover isn't truly scalable from an organizational perspective.

And finally, we shouldn't assume that an architecture will scale simply because it looks good on a diagram.

Testing is what gives us evidence.

Depending on the solution, that can include:

• Response time

• Throughput

• Data volume

• Concurrent users

• Automation load

• Integration load

• Migration throughput

• Failure and recovery scenarios

Because:

Theoretical scalability and demonstrated scalability are two different things.

My Practical Scalability Checklist

When I review an enterprise Dataverse solution today, I find myself asking:

Data

• What will the data volume look like in three years?

• Are we storing the data in the right platform?

• Are our queries and access patterns appropriate?

Users & Security

• How many business groups will use the platform?

• Can the security model accommodate growth?

Customization

• Do we really need this Plugin?

• Can the platform handle the requirement through configuration?

Automation

• What happens when execution volume increases tenfold?

• Is this the right workload for Power Automate?

Integration

• Is point-to-point integration still appropriate?

• How will retries, failures, and monitoring work?

Search

• Is the requirement still within the CRM search model?

• Do we need to search across multiple enterprise sources?

Operations & Testing

• How will we detect performance degradation?

• Have we tested realistic data volumes and workloads?

• Do we have measurable performance targets?

And finally, one question I keep coming back to:

"What happens when this solution becomes ten times bigger?"

That question alone can reveal a surprising number of architectural weaknesses.

Final Thoughts

Earlier in my career, when I heard the word scalability, I mostly thought about performance and data volume.

Experience has changed that view.

Today, when I hear "scalable CRM," I think about something broader:

Can this platform absorb growth without forcing the organization to constantly redesign it?

More users.

More business groups.

More data.

More integrations.

More automation.

More developers.

More operational responsibility.

More change.

If every increase requires another layer of custom code or another architectural workaround, we haven't really designed for scale.

We have only postponed the problem.

For me, good enterprise architecture is about finding the right balance between capability, simplicity, maintainability, operational excellence, and future growth.

The goal isn't to build the most sophisticated architecture.

It is to build an architecture that can grow with the business without becoming a burden to the business.

Good architecture doesn't eliminate complexity. It keeps complexity from becoming the product.

Next in Enterprise CRM Insights Enterprise CRM Insights #4

Enterprise Integration Patterns for Dynamics 365

Stay tuned.

One question I have come across many times is:

Should this be implemented using a Plugin or Power Automate?

At first, this looks like a technical implementation decision.

In my experience, it is actually an architecture decision.

Over time, my thinking has moved from:

"Can we do this using Power Automate?"

or:

"Can we do this using a Plugin?"

to a more important question:

"What does the business process require, and which execution model is the right fit?"

That change in thinking has helped me make better design decisions.

Plugin and Power Automate — Different Strengths

There is some overlap between Plugins and Power Automate, but they solve different types of problems.

Plugins are particularly useful when we need:

• Transaction-level validation

• Immediate business logic

• Dataverse execution context

• Complex Dataverse-side processing

• Logic that needs to influence the current transaction

Power Automate is particularly useful for:

• Approvals

• Notifications

• Business process automation

• Human interaction

• Multi-step orchestration

• Asynchronous and scheduled processing

The important distinction is that a Power Automate cloud flow does not participate in the original Dataverse transaction in the same way as a synchronous Plugin.

That difference becomes critical when the business requirement depends on the transaction succeeding or failing based on the logic being executed.

A Real Example: Approval Processes

One area where I have deliberately preferred Power Automate over Plugins is approval processing.

Consider a process that requires manager approval.

It may involve:

• Identifying the approver

• Sending an approval request

• Waiting for a response

• Handling approval or rejection

• Sending notifications

• Updating the record

• Supporting escalation or multiple approval levels

Technically, we could implement significant portions of this using custom Plugin code.

But the question is:

Should we?

In my experience, using Plugins for this type of process can introduce unnecessary development and maintenance effort.

Power Automate is naturally aligned with this kind of business process.

If the approval hierarchy changes later, a well-designed flow can generally be easier to understand and modify than a large amount of custom code that requires development, testing, deployment, and regression testing.

This is a good example of an important architectural principle:

The most technically powerful option is not always the best architectural option.

A Real Example: External System Integration

I have also worked on scenarios where Plugins were used to initiate integrations with external systems.

Depending on the enterprise integration architecture, the pattern could look like:

Dynamics 365 → Plugin → Enterprise Integration Platform → External System

Or, for some scenarios:

Dynamics 365 → Plugin → External System API

If an Enterprise Integration Platform is already responsible for routing, transformation, security, monitoring, retry, and communication with downstream systems, the Plugin may simply act as the Dataverse-side trigger.

In other situations, a direct API call may be appropriate.

But I would not stop the discussion at:

"Can a Plugin call an API?"

Yes, it can.

The more important question is:

"Should this API call happen as part of the Dataverse transaction?"

That question can completely change the architecture.

Execution Time Matters

One important consideration when using synchronous Plugins is execution time.

Dataverse has a hard two-minute limit for a message operation, so synchronous logic should be kept short and efficient.

This becomes especially important when external APIs are involved.

Consider:

Dataverse → Plugin → External API

What happens if the external system:

• Takes longer than expected?

• Becomes unavailable?

• Experiences network latency?

• Returns errors?

• Receives a large number of requests simultaneously?

If the API call is part of a synchronous transaction, the external system can directly affect the Dataverse operation.

So I always ask:

Does this integration genuinely need to be synchronous?

If the answer is no, an asynchronous design may provide a much more resilient solution.

Volume Can Change the Architecture

Another factor I always consider is record volume.

A solution that works perfectly with 100 records may behave very differently with 100,000.

Before choosing the implementation approach, I want to understand:

• Expected volume

• Peak volume

• Frequency of execution

• Number of Dataverse operations

• Number of external API calls

• Concurrent processing

• Downstream system limits

• Bulk operations

For example, a flow triggered whenever a record is created may work perfectly during functional testing.

But if an integration starts creating tens of thousands of records, the architecture needs to account for the resulting workload.

The same applies to Plugins.

A Plugin registered on a high-volume event can become expensive if every execution performs complex processing or external calls.

So one of my simple questions is:

"What happens when the volume is 10x what we have today?"

That question often exposes architectural problems before they become production problems.

Maintainability Is Part of Architecture

Another reason I have chosen Power Automate for certain processes is maintainability.

Custom code is powerful, but every line of custom code becomes something the organization needs to understand, test, deploy, monitor, and support.

For an approval process, notification workflow, or straightforward orchestration, custom Plugin code may introduce more technical debt than value.

But there is another side.

I have also seen Power Automate flows become difficult to maintain.

A flow that starts as:

Trigger → Condition → Update

can eventually become:

Trigger → multiple conditions → nested scopes → expressions → child flows → connectors → exception handling → parallel branches

At that point, simply calling it "low-code" does not make it simple.

So my principle is not:

Power Automate is easier.

It is:

Use the technology that keeps the solution understandable as it grows.

Sometimes the Answer Is Both

I don't believe every architecture decision has to be:

Plugin OR Power Automate

Sometimes the better answer is:

Plugin AND Power Automate

For example:

User updates Case

↓

Plugin

Validate critical business rules

↓

Dataverse transaction completes

↓

Power Automate

Handle notification, approval, or downstream processing

This gives each technology a clear responsibility.

The Plugin protects the integrity of the transaction.

Power Automate manages the business process that can happen after the transaction.

This separation can also make future changes easier.

If the approval or notification process changes, we don't necessarily need to modify the transactional business logic.

My Practical Decision Framework

I don't treat this as a rigid rulebook, but these are the questions I normally ask:

These are not absolute rules.

The surrounding architecture and business requirement always matter.

My Rule of Thumb

If I had to simplify the entire discussion into a few questions, I would start here:

Does the logic need to participate in the transaction?

→ Start by evaluating a Plugin.

Does the process involve approvals, notifications, human interaction, or orchestration?

→ Start by evaluating Power Automate.

Does it involve external systems?

→ Evaluate the integration architecture before deciding where the call should happen.

Is the volume significant?

→ Validate throughput and execution behaviour before implementation.

Is the solution becoming complex?

→ Stop and reconsider the design rather than continuing to add more branches and conditions.

And finally:

Can the solution be simpler without compromising the business requirement?

If yes, simplify it.

Final Thoughts

After working on enterprise Dynamics 365 solutions, I have learned that the Plugin versus Power Automate discussion is rarely about which technology is better.

Both have their place.

I have used Power Automate for processes such as approvals where implementing the same process through custom Plugin code would have introduced unnecessary development and maintenance effort.

I have also used Plugins for scenarios involving external integrations, including architectures where the Plugin communicated through an Enterprise Integration Platform or directly with an external API.

The decision was not based simply on which technology was available.

Transaction requirements mattered.

Execution time mattered.

Record volume mattered.

Integration architecture mattered.

Maintainability mattered.

And perhaps most importantly:

What happens after go-live matters.

A solution is not successful simply because we implemented the requirement.

It is successful when the solution continues to perform reliably, remains understandable to the team supporting it, and can evolve as the business changes.

That is why I believe the architect's responsibility is not simply to choose between Plugin and Power Automate.

It is to understand the problem deeply enough to know where each technology belongs—and when neither is the right answer.

The best architecture is not the one that uses the most technology. It is the one that uses the right technology for the problem.

Next in Enterprise CRM Insights

In the next article, we'll move from individual implementation decisions to a broader architectural question:

How do we design Dataverse solutions that remain scalable and maintainable as the business, data volume, integrations, and complexity grow?

Enterprise CRM Insights #3 — Designing Scalable Dataverse Solutions

Stay tuned.

This series is based on real-world experience and is intended for architects, consultants, developers, delivery leaders, and technology professionals who are passionate about building scalable, business-focused CRM solutions.

Who should read this?

This article is intended for:

• Dynamics 365 Solution Architects designing enterprise CRM platforms

• Consultants responsible for implementation decisions

• Developers building scalable CRM customizations

• Delivery leaders managing CRM transformation programs

A Dynamics 365 project going live is often celebrated as a success. But the real measure of success begins after go-live — when the solution starts delivering measurable business value.

In my experience, that's only the beginning.

A truly successful implementation is one that users embrace, business teams trust, and organizations can continue to evolve for years.

After working across multiple enterprise Dynamics 365 implementations in different roles—from developer to consultant, architect, presales, and now delivery leadership—I've learned that success is measured very differently.

Technology is only one part of the solution.

The real success lies in delivering a platform that users trust, business teams adopt, and organizations can continue to evolve for years.

Here are seven principles that have consistently helped me deliver scalable and sustainable Dynamics 365 solutions.

1. Understand the Business Before Designing the Solution One of the biggest mistakes teams make is jumping directly into configuration.

A CRM system should reflect how a business operates—not the other way around.

Before discussing entities, forms, plugins, or Power Automate flows, invest time in understanding:

Business objectives Customer journeys Current pain points Success criteria Future scalability

Technology decisions become much easier when business outcomes are clearly defined.

2. Keep the Solution as Simple as Possible Enterprise solutions naturally become complex.

However, complexity should come from business requirements—not from technical design.

Whenever I review a solution, I ask a simple question:

Can this be simplified without compromising business value?

Simple solutions are easier to maintain, easier to enhance, and significantly less expensive to support.

3. Build for Change Business processes rarely remain the same.

A solution designed only for today's requirements often becomes tomorrow's technical debt.

When designing enterprise solutions, consider:

Future business growth New business units Additional integrations Regulatory changes AI capabilities

Good architecture anticipates change rather than resisting it.

4. Choose the Right Tool for the Right Problem One question that frequently comes up is:

One of the most common architecture decisions in Dynamics 365 projects is choosing between synchronous extensibility (Plugins) and automation frameworks such as Power Automate.

The right choice depends on several factors:

• Performance requirements

• Transaction consistency

• User experience

• Maintainability

• Integration needs

Rather than selecting a technology based on personal preference, every technical decision should align with business objectives and long-term solution architecture.

This topic deserves a deeper discussion, which will be covered in the next article of this series.

5. Governance Is Not Optional As organizations grow, multiple teams begin working on the same Dynamics environment.

Without governance, solutions become inconsistent.

Some governance practices that have proven valuable include:

Solution layering standards Code reviews Naming conventions Environment strategy Release management Security reviews

Strong governance reduces long-term maintenance costs and improves delivery quality.

6. Focus on User Adoption Even the best technical solution has limited value if users avoid using it.

Successful implementations involve users throughout the project by:

Demonstrating prototypes Collecting feedback early Simplifying user experiences Providing effective training

User adoption should be treated as a project objective—not an afterthought.

7. Technology Keeps Changing—Business Value Remains Constant In recent years we've seen rapid advancements in:

Power Platform Microsoft Copilot Generative AI Intelligent automation

These technologies are transforming how organizations interact with customers.

However, one principle remains unchanged:

Technology should always solve a meaningful business problem.

Organizations don't invest in AI because it's new—they invest because it improves customer experience, productivity, or operational efficiency.

Final Thoughts

Enterprise CRM projects succeed when technology, business goals, and people move in the same direction.

The platform is important, but the real value comes from solving business problems in a sustainable way.

Enterprise CRM implementations are not software deployments. They are business transformation initiatives where technology becomes an enabler for better customer experiences, operational efficiency, and sustainable growth.

The most successful implementations I've been part of shared a common characteristic:

Every technical decision was guided by business value.

As technology continues to evolve, I believe architects, consultants, and delivery leaders have an opportunity to focus less on individual features and more on helping organizations achieve measurable business outcomes.

I'd love to hear your perspective.

What's one lesson you've learned from delivering a Dynamics 365 implementation?

Let's continue the conversation in the comments.

Next in Enterprise CRM Insights

Enterprise CRM Insights #2

Plugin vs. Power Automate: A Practical Decision Framework

Stay tuned!