Hire Microsoft Dynamics 365 experts
Hire Microsoft Dynamics 365 solution architects
In short
MS Dynamics Guys provides Microsoft Dynamics 365 solution architects who guide your team's design without taking over its backlog. The architect records design decisions with their tradeoffs, drafts measurable nonfunctional requirements, draws integration boundaries and reviews the security model. Your design authority approves each decision, and your developers, consultants or partner build it. We agree the product scope, the architect's time and the review rules in writing before work starts.
When a solution architect from MS Dynamics Guys fits
A solution architect suits a team that keeps delivery in its own hands but has no owner for how the parts fit together. The architect proposes and records design decisions. Your design authority, the person or group on your side who accepts or rejects them, is named before the architect starts.
Team situations that call for an architect
- Your partner builds, and every design needs a review first. Your implementation partner proposes designs throughout the project, and nobody on your side can judge them before the build starts.
- Several apps, and no owner for record decisions. Customer, item or price data lives in more than one app, and each team treats its own copy as the master.
- Nobody wrote down volumes and response times. Your team cannot say how many orders, users or messages the system must handle at peak, or how fast a key screen must open.
- Customizations reach production without a design review. Changes go live before anyone checks their effect on other apps, integrations or security.
- A Solution Blueprint Review is near. Microsoft's Success by Design guidance tells project teams to make this review mandatory. The review begins in the Discover phase, before design decisions become costly to reverse. The architect prepares the decisions, requirements and integration map that the review examines.
When another role or service fits better
- Most open questions concern business processes, not structure. Start with a functional consultant who works with your process owners.
- The design is settled, and only building or configuring remains. That work belongs to a developer or consultant for your product, such as a developer for customer relationship management (CRM) apps, a Business Central developer or a Power Platform developer.
- Interfaces fail in production, and nobody owns alerts, replays and reconciliation. That is daily work for an integration engineer, not an architect.
- The work is moving data out of an old system: profiling, mappings, trial loads and reconciliation. A data migration engineer owns that workstream. An architect joins in only where a migration choice outlives go-live, such as which system owns each record.
- You need one review of one design or partner proposal, with written findings, not a person in your team. An independent assessment fits better.
- Releases slip, and nobody trusts the plan. Recover the plan first, for example through a project rescue.
- Nobody on your side can approve a design decision. An architect can propose and record decisions, but cannot make them for your business.
Can an architect from MS Dynamics Guys guide our team without owning every implementation task?
Yes. The architect owns decisions and reviews, not backlog items. Your developers, consultants or partner keep building, on decisions that your design authority has accepted.
Microsoft's guidance on organizing a project team asks that the solution architect can assert their expertise and influence the design and its implementation. In this model, that influence comes from three written rules, not from owning tasks:
- A design authority that decides. The architect sets out the options and the reasons. Your design authority accepts or rejects each proposal in writing.
- Review gates. The agreement names the changes that need a design review before anyone builds them: for example, a new integration, security role or app.
- Decision rights. The agreement lists the small decisions the architect may take alone, such as naming rules. Larger decisions go to your design authority.
Access follows the same split. The architect reads the environments, repository, backlog and logs in scope, and writes only the decision log and design documents. Production change rights come only with assigned implementation work.
| Area | Architect from MS Dynamics Guys | Your design authority | Your builders or partner |
|---|---|---|---|
| Record ownership | Proposes which system owns each record, with options and tradeoffs | Decides | Report the constraints of their systems |
| Nonfunctional requirements | Drafts targets against documented platform limits | Approves the targets | Design and test against them |
| Integration boundaries | Proposes the system of record, timing and failure owner of each interface | Approves them | Build, monitor and report failures |
| Security model | Designs access and reviews each change to it | Approves the access policy | Implement it, then test it with ordinary user accounts |
| Implementation tasks | Reviews designs at the agreed gates; owns no tasks unless the agreement assigns them | Decides which changes need a review; your product owner orders the backlog | Build and test |
Disagreements go into the decision log, not into email threads. When the architect and your partner's team disagree, one record sets out both options and their tradeoffs, and your design authority decides. A short proof of concept can test a risky option as a separate, agreed task.
If the agreement gives the architect build tasks, someone else reviews that work, so nobody approves their own design. The same Microsoft guidance lists unclear authority as a common leadership problem: several roles share it, or nobody holds it. The table gives each area one owner on your side.
Deliverables the architect owns
Every deliverable is written down, so your team can check it and keep it. Each one lives in your repository or wiki from the first day.
- Decision log. Microsoft's Azure Well-Architected guidance calls this log an architecture decision record (ADR) and treats it as append-only. The log holds one record for each choice that shapes the solution or is hard to reverse. Every record follows one template, shown in the demonstration further down: context, options, decision and tradeoffs, confidence, status, consequences and a review trigger. Nobody edits an accepted record. A changed decision gets a new record that links to the one it supersedes, and both stay in the log.
- Nonfunctional requirements. Targets for data volumes, peak load, response times, availability, recovery and data retention. Each line has a number, or the name of the person who will supply it.
- Integration boundary map. For every interface: the system of record, the direction, the timing (a scheduled copy or a live call) and the person who owns a failure. Each line is the input for a flow specification, in which an integration engineer or your developers add the matching keys, retries, alerts and replay steps.
- Security review. The access model, the data that needs extra protection and the place where credentials are kept. Microsoft's implementation guidance says that hiding fields with custom code is not security. Users with the right security role can still reach the data in other ways. The guidance also advises storing no credentials in the system; Azure Key Vault can hold them instead.
- Risk register. Technical risks ranked by impact, each with an owner and a next step.
- Review gates. The changes that need a design review, what the reviewer checks and how your team asks for a review.
Before a decision record recommends custom code, it weighs a standard feature, configuration and existing apps, for example from Microsoft Marketplace.
Not owned by the architect: your backlog and its priorities, business outcomes and the acceptance of finished work. Routine configuration stays with your consultants or partner, and the architect sees it only at the agreed gates.
What the architect designs in each product track
Architecture questions differ by product, and no single architect covers every Microsoft Dynamics 365 app. We assess and offer each architect for named product tracks, and the fit review states which tracks apply to your role.
| Product track | Design questions the architect works on | Platform facts the design must respect |
|---|---|---|
| Customer relationship management (CRM) apps on Microsoft Dataverse, such as Microsoft Dynamics 365 Sales and Customer Service | Whether the customizations live in one solution or in a base solution with app solutions on top, all under your one publisher. The structure of the access model: business units, team types and column security. CRM consultants then map each job role to it and test it. How integrations and bulk jobs stay within service protection limits. CRM developers build to these decisions. | Managed solutions stack in layers, and each one installed later sits above the earlier ones. Unmanaged customizations sit above all managed layers and decide how a component behaves. Microsoft advises one publisher for all your solutions, because a component's publisher cannot change after a managed solution introduces it. Microsoft's documented defaults allow each user 6,000 requests and 20 minutes of execution time in a five-minute sliding window. Each web server applies these limits on its own. |
| Microsoft Dynamics 365 Business Central | For each requirement: a standard feature, a Microsoft Marketplace app or your own extension. How your extensions split, and which may depend on which. How integrations stay within the Open Data Protocol (OData) limits. Which tests must pass in an updated sandbox before each major update reaches production. Business Central developers build to these decisions and do the update work. | Microsoft ships two major updates a year, in April and October, plus monthly minor updates. The documented OData limit is 6,000 requests per user in a five-minute sliding window. Each user can have five requests processed at the same time, and further requests wait in a queue of limited size. |
| Microsoft Power Platform | Which environments the solution passes through on its way to production, within your tenant's environment strategy. Which connectors the design depends on, checked against your data policies before anyone builds. Reviews against the five pillars of Power Platform Well-Architected. Power Platform developers build to these decisions. Setting a tenant-wide environment strategy and data policies is a Power Platform consulting project. | Outside the development environment, solutions are deployed as managed solutions. Data policies control which connectors can be used together. Managed environments add premium governance features. |
| Microsoft Dynamics 365 Sales together with Business Central | For each record type the two apps share: the owning app, which mappings run in both directions, and which screens need live data instead of the scheduled copy. A technical consultant then configures the standard integration to match. A live read that needs custom code goes to an integration engineer or a CRM developer, and the decision record names which. | The standard integration couples records through Dataverse, and scheduled job queue entries copy changes, by default every 30 minutes. Microsoft notes that this scheduled synchronization does not ensure real-time consistency between the two apps. For real-time data, it points to Business Central virtual tables or APIs (application programming interfaces). |
Microsoft states that the Dataverse figures are defaults that can change and vary between environments.
Before your team sets its targets, the architect checks the current limits in Microsoft's documentation and records the date of that check.
How MS Dynamics Guys assesses a solution architect
The exercise is a design critique, not a build task. The candidate reviews a reference design for the role's product track and finds its flaws. In a walkthrough, a reviewer from that track tests the tradeoffs behind each finding.
We write the reference design for each track. Some designs adapt one of Microsoft's published reference architectures, and we add the volumes, constraints and planted flaws. The summary names the design that was used.
For Dataverse and Power Platform roles, the starting point can be the Power Platform and Copilot Studio Architecture Center that Microsoft publishes. Each of its reference architectures includes an architecture diagram, a step-by-step workflow, key components and design considerations.
| Skill | How the reviewer checks it | Evidence you receive |
|---|---|---|
| Decisions | The candidate compares two options for one integration or security decision in the design, then writes the decision record in the template shown in the demonstration below | The decision record with the reviewer's notes |
| Requirements | The candidate turns a vague request, such as a system that must be fast, into measurable targets that fit the documented platform limits | A target table with a number or a named supplier on every line |
| Boundaries | The candidate marks every interface in the design with its system of record, direction, timing and failure owner. The reviewer checks that each record type has exactly one owning system. | An interface map with a named failure owner on every line |
| Security | The candidate finds data hidden only by custom code and a credential stored in configuration, then proposes supported fixes | Findings ranked by risk, each with its fix |
| Governance | The candidate follows a change from development to production and marks where a design review belongs | A review-gate checklist that a team could adopt |
During the walkthrough, the reviewer changes one assumption, for example the peak volume or the state of an interface. The candidate then names the decision records that the change reopens and explains how the design must change.
Example first work package: baseline an inherited solution
Ways to engage an architect
The options differ in who approves design decisions and when each one fits.
| Option | Who approves design decisions | Choose it when |
|---|---|---|
| An architect in your team | Your design authority. Your program lead sets the architect's priorities. | Decisions keep arising while your own developers, consultants or partner build |
| An independent assessment | Your team, using written findings and a roadmap that MS Dynamics Guys delivers and you keep | One decision is open, such as a product choice or a partner's proposal, and you want an outside view |
Staff augmentation versus project delivery shows what a change of priorities costs in each model, for example when your design authority reorders the open decisions.
How work with an architect starts
Decision rights are written down before the architect gets access. No step has a fixed length, and no start date is set before your interview and the signed agreement.
Your role brief
Name the product and version, the integrations, the open decisions and the partner that builds. Say who your design authority is and how much architect time you expect.
Fit review
We confirm in writing whether the gap needs an architect, which product track applies and whether we can staff the role. If an assessment, another role or another provider fits better, we say so.
Assessed candidates
Each profile names the product tracks the candidate passed and includes the decision record from the critique, with the reviewer's notes. A profile reaches you only when the candidate passed and agreed to share it.
Critique walkthrough
In your interview, your design authority asks the candidate to defend one decision from the critique. You can also describe a past decision of yours, with sensitive details removed, and ask how the candidate would have recorded it. You decide who joins your team.
Written decision rights
The agreement lists the decisions the architect may take alone and the changes that need a design review. It also sets allocation, overlap hours, notice and the ownership of work products.
Read access first
After the agreement is signed, your administrators issue named accounts with read access. The rest follows your usual onboarding steps for external specialists.
First accepted decisions
The first decision records reach your design authority. Its written ruling on them is the first acceptance of the engagement.
After that, the work follows our delivery model for every engagement. Decisions are made in writing, work stays in your systems, and the engagement ends with a handover.
How to check an architect's judgment before you commit
No client names, testimonials or case studies appear on this page. Judge the architect's work instead:
- The written summary of each candidate's critique exercise.
- Your own interview, run as the critique walkthrough in the steps above.
- The first decision records, accepted or rejected by your design authority.
- The demonstration below, which shows the format of one decision record.
Our page on technical screening explains who reviews the critique and what any assessment leaves untested.
| Field | Entry in the demonstration |
|---|---|
| Title and status | Record 14: how sales staff see stock levels on quotes. Status: accepted. It supersedes record 6, which copied stock levels once a night. |
| Context | Sales staff quote delivery dates in the customer relationship management (CRM) app. Stock is kept in the enterprise resource planning (ERP) app. The nightly copy can be a day old, so some quotes promised stock that was already sold. |
| Options considered | A: copy stock levels to the CRM app every 30 minutes. B: read stock live from the ERP app when a user opens a quote. C: show no stock in the CRM app, so sales staff check the ERP app. |
| Decision | Option B for quotes, because a quote needs the current figure. Lists and reports keep a scheduled copy, which now runs every 30 minutes. |
| Tradeoffs | Quotes now depend on the ERP app being available, and each opened quote adds calls that count against its request limits. When the ERP app does not answer, the quote shows the last copied figure and its time. |
| Confidence | Medium. Quote volume at month end has not been measured, so the extra load is still an estimate. |
| Consequences | The integration map gets a new live interface with a failure owner. A new requirement sets how fast a quote must show stock. |
| Review trigger | Revisit the decision if the month-end load test misses the agreed response time. |
This is an original demonstration. It describes no client system and no candidate's answer. In a real engagement, records like this live in your repository, and your design authority accepts or rejects each one.
Questions about hiring a solution architect
How much architect time does our team need, and can it be part-time?
Architect time follows decisions, not tickets. It is highest while the design takes shape: at the start of a project, before a Solution Blueprint Review and before large changes. While your team builds on accepted decisions, reviews at the agreed gates are often enough.
Some buyers call a part-time architect a fractional architect. Whether MS Dynamics Guys can staff the role part-time, and with what allocation, is agreed in writing per engagement. To size the role, count the open decisions and review gates in your next release, and put both in the role brief.
Working-hour overlap is also agreed in writing per engagement. Plan it around the moments when decisions are made, such as design authority meetings and gate reviews. Writing and reviewing decision records can happen outside those hours.
Which Microsoft Dynamics 365 products does the architect cover?
An architect's decisions often cross products, for example when Microsoft Dynamics 365 Sales and Business Central share customers and orders. The architect then needs a passed assessment in every product track those decisions touch. Each candidate's written summary lists the tracks they passed. Name every product in the role brief. Before any introduction, we tell you in writing whether one architect covers all of them, or whether part of the scope needs another role.
The product track table on this page shows the design questions in each track.
How can we judge an architect's decision records?
Read the record from the candidate's critique exercise first. A strong record shows four signs:
- It names the options that were really considered, including a standard feature or no change.
- It states what the decision costs, not only what it gains.
- It gives a confidence level and the evidence that would change the decision.
- It stays short, and links to longer design notes instead of becoming a design guide.
A weak record describes only the chosen option, or leaves out its consequences. To compare candidates from several providers on the same criteria, use a buyer scorecard for Microsoft Dynamics 365 specialists.
Can the architect prepare us for a Solution Blueprint Review?
Yes. In Microsoft's Success by Design framework, the review checks whether the planned solution and the project approach follow recommended practices. It records findings of three types: assertions about what the team does well, risks and issues. Those findings lead to deeper Implementation Reviews of areas such as the data model, security and integration.
The architect prepares what the review examines: the decision log, the nonfunctional requirements, the integration map and the security model. Afterwards, the architect turns the findings into decision records and backlog items for your team. Your implementation partner or Microsoft's FastTrack program provides the Success by Design tooling that tracks success measures.
Who keeps the decision log and the review gates running after the architect leaves?
Your design authority, with one named person on your side who maintains the log. Nothing has to move, because everything the architect wrote sits in your repository or wiki from the first day. That includes the decision log with its superseded records, the requirements table, the integration boundary map, the security review, the risk register and the review-gate rules. The written agreement sets the ownership of these work products. Before a planned exit, every open decision gets a named owner on your side, and the architect walks that person through the log. Notice and any replacement follow the terms agreed in writing per engagement.
Can we pay per decision or per review instead of by time?
Paying per decision is hard to plan. Nobody knows in advance how many decisions a release will raise, or how large each one will be. Review time is easier to predict once the agreement names the review gates. MS Dynamics Guys agrees the pricing basis with you in writing per engagement, and this page quotes no rates. The allocation, the hours to cover, the product tracks and the number of apps and partners in scope move the price most.
To compare rate bases across providers, use the questions in the cost guide for Microsoft Dynamics 365 developers; they apply to an architect's time too. Your organization buys Microsoft licenses separately, for example through its licensing partner.
Discuss architecture capacity
Tell us the product and version, the decisions that are open, who approves designs on your side, how much architect time you expect and your time zone. Our first reply asks questions or proposes a role brief; introductions come later.
Product documentation referenced on this page
- Maintain an architecture decision record (ADR) Microsoft Learn, checked October 4, 2026
- Introduction to the Success by Design framework Microsoft Learn, checked October 4, 2026
- Organize your Microsoft Dynamics 365 project team Microsoft Learn, checked October 4, 2026
- Secure your Microsoft Dynamics 365 data and apps Microsoft Learn, checked October 4, 2026
- Power Platform Well-Architected Microsoft Learn, checked October 4, 2026
- Overview of Power Platform and Copilot Studio reference architectures Microsoft Learn, checked October 4, 2026
- Manage Microsoft Dynamics 365 apps that run on Microsoft Dataverse Microsoft Learn, checked October 2, 2026
- Service protection API limits (Microsoft Dataverse) Microsoft Learn, checked October 4, 2026
- Solution layers and merge behavior in Power Platform Microsoft Learn, checked October 4, 2026
- Solution layers in Power Platform Microsoft Learn, checked October 4, 2026
- Solution concepts with Power Platform Microsoft Learn, checked October 4, 2026
- Organize your solutions in Power Platform Microsoft Learn, checked October 4, 2026
- Security roles and privileges Microsoft Learn, checked October 2, 2026
- Operational limits for Business Central online Microsoft Learn, checked October 4, 2026
- Extension types and scope in Business Central Microsoft Learn, checked October 2, 2026
- Business Central update rollout timeline Microsoft Learn, checked October 2, 2026
- Integrating Business Central with Microsoft Dynamics 365 Sales Microsoft Learn, checked October 4, 2026
- Synchronization and data integration in Business Central Microsoft Learn, checked October 4, 2026
- Environment strategy for Power Platform adoption Microsoft Learn, checked October 2, 2026
- Data policies Microsoft Learn, checked October 2, 2026
- Connector classification Microsoft Learn, checked October 4, 2026
- Managed environments overview Microsoft Learn, checked October 4, 2026
- Extensibility home page for finance and operations apps Microsoft Learn, checked October 4, 2026