Introduction

Completed100 XP
 7 minutes

FastTrack for Microsoft Dynamics 365 (such as Dynamics 365 Sales, Dynamics 365
Customer Service, or Unified Operations apps) is Microsoft's customer success
service. It's designed to help customers and partners achieve a successful deployment
of Microsoft Power Platform and Dynamics 365. To deliver this service, FastTrack
solution architects use Success by Design. FastTrack team engagement is available to
customer projects that meet the FastTrack eligibility requirements. Because not all
projects will qualify, Microsoft is making a tailored version of Success by Design
available for partners and customers to use on their own. The Use Success by Design
for Dynamics 365 apps solutions learning path examines this version and how
partners and customers can use Success by Design to achieve a successful
deployment of Microsoft Power Platform or Dynamics 365.

Success by Design is the prescriptive guidance (approaches and best practices) for
designing, building, and deploying a Dynamics 365 solution. Success by Design is
based on Microsoft's experience in providing engineering oversight across thousands
of deployments with hundreds of partners through the FastTrack program over the
years. Its fundamentals are good solution architecture and design, technical
capabilities of the Dynamics 365 product line, and proven approaches to design and
implementation challenges that arise during a business process transformation and
implementation.

Solution architects on projects have a unique role in a customer implementation and

are responsible for the success of the deployment and timely onboarding process for
users. The guidance is designed to help the solution architect achieve that goal. This
guidance works best when it is run by a qualified solution architect who isn't part of
the implementation team. If that isn't possible for an implementation, then the
project's solution architect can perform the role.
Success by Design includes several project workshops. These workshops are mixtures
of interactive meetings, TechTalks, and follow-up communication and tasks. These
workshop topics include:

 Solution blueprint
 Test strategy
 Data model
 BI and analytics design
 Gap solution design
 Data migration
 Security
 Integration design
 Dual-write implementation
 Solution performance
 Cutover strategy
 Post go-live strategy

This learning path outlines how you can use these techniques on your own project,
even if your project isn't actively being engaged with by the Microsoft FastTrack
team. This first module is Success by Design, which provides an overview of the
guidance. Other modules in the series will provide in-depth detail about individual
topics.

Value for partners and customers

The Success by Design guidance establishes a methodology-agnostic series of
checkpoints to help move Dynamics 365 projects toward success. The guidance is
designed to promote candid discussions between the project teams to review
progress on the project against numerous identified best practices. This approach
allows partners and customers to take advantage of the broader community of
Dynamics 365 projects that are being implemented and their lessons learned. The
guidance isn't designed to measure the partner or customers individually; it's meant
to bring them together as a team to guide their project toward a successful
onboarding process for users.

The purpose of this module and learning path is to provide an introduction on how
to use the Success by Design guidance. This path is intended for the person or
department that is responsible for the deployment of Dynamics 365, including
functional, technical, and business resources who are responsible for the deployment
and adoption of the system.

Overview of Success by Design

Completed100 XP

 10 minutes

With Success by Design, the solution architect can engage with project teams
through strategic workshops that are aligned to key project stages with clear goals,
actions, and deliverables. Each workshop has been designed with specific goals and
maps to relevant success measures for the project. A workshop is essentially an
alignment exercise that allows the solution architect to assess if best practices are
being followed and identify and highlight issues or potential risks that can derail the
project. While Success by Design offers prescriptive guidance for success, be
prepared to make minor adjustments to the stages and details that are relevant to
your specific projects.

Success by Design offers solution architects a framework for effective engagement

with customers in support of their specific goals and outcomes. This guidance
provides a model for proactive engagement with customers to have a greater impact
on success rather than only handling reactive escalations.

Additionally, Success by Design reduces the amount of reactive issue escalation by

using active course correction throughout the project. Frequent knowledge transfer
enables cross-pollination of ideas, learning, and best practices across projects. This
feature will ensure that business goals are strategically aligned with product
capabilities to maximize the value that your customers will receive from the platform.
Solution architects can use Success by Design prescriptive guidance to help increase
user adoption of the system by monitoring usage of new features and evangelizing
the latest capabilities that are relevant to your customer's business process and pain
points. Timely guidance and architectural inputs will be provided to ensure that the
delivered solution performs well and is scalable, that it not only meets current needs,
but also meets the future demands of the customer's business.

Essentially, Success by Design brings the learning and experiences from thousands of
customer cloud deployments to your project to help make the journey to the cloud
smoother, faster, and more successful.

Summary of workshops
As previously discussed, Success by Design has several workshops. Each workshop is
a module within this learning path. The following sections summarize some of those
key workshops. Templates are available for each workshop, and you can download
examples of the templates that you need.

The workshops are not in a prescribed order; you can return to a topic more than
once for any given project. For example, integrations should be designed, built,
tested, and supported. You might find overlap in topics, and even if no specific
overlap exists, a general awareness of the other aspects is a vital part of success. This
module will go into much greater detail of each workshop, but the following sections
provide a summary of what to expect for each. The subsequent sections list the
workshop topics in this learning path and in the order in which they can be
implemented in a typical project.

Solution blueprint

The goal of the Success by Design framework is to ensure a successful customer

outcome for each implementation. By starting with the Solution blueprint review, the
team can review the overall solution plan and help offer suggestions and course
corrections early. The purposes for the Solution blueprint review are to:

 Drive communication and understanding – The Solution blueprint

review is designed to drive a conversation about the solution that
promotes general understanding across the implementation team
regarding the goals, scope, architecture, and approach to implementing
the solution.

 Identify risks and issues – By taking a broad but high-level look at the
solution, it is possible to identify issues and risks with the solution design
or implementation approach that will negatively impact the outcome.
  Establish a baseline of subsequent reviews – Based on establishing a
general understanding of the solution, the FastTrack solution architect
who is involved can build a plan for follow-up workshop activities to
investigate aspects of the solution where additional guidance might
provide benefits.

Test strategy

An effective test strategy will allow for a holistic view of the proposed solutions.
Testing will happen in several different phases of development, but you should define
the strategy early. The purposes of the test strategy review are to:

 Drive communication and understanding – The Test strategy review is

designed to drive a conversation about the test strategy that promotes
general understanding across the implementation team regarding the
testing objectives, test types, test coverage and planning, and approach
to validating the solution.

 Identify risks and issues – By taking a broad but high-level look at the
test strategy, it is possible to identify issues and risks with the approach
that would negatively impact the outcome.

 Provide recommendations – Based on the identified risks, Microsoft will

provide recommendations to help you best manage and mitigate the
risks.

Data model

The Data model workshop is dedicated to reviewing the envisioned data model for
the customer project. The data model usually reflects the functional scope of the
project. It also reveals its potential complexity if it contains numerous tables, complex
relationships, impact on security, or use or misuse of standard objects, large number
of custom tables, and so on.

BI and analytics design

The goal of the BI and analytics design workshop is to ensure that the BI and analytics
solution design is well understood, planned, and that it is appropriate for the solution
strategies and technologies that are used. You should be collecting insights on the
implementation activities, reviewing the current planned solution design, and raising
recommendations/risks/issues that are related to the plan and solution strategies.

The purposes of the BI and analytics design workshop are to:

  Drive communication and understanding – The BI and analytics design
workshop drives a conversation about the business intelligence and
reporting requirements of the project that promotes general
understanding across the implementation team regarding the reporting
goals, scope, architecture, and approach to implementing the reporting
solution.

 Identify risks and issues – By taking a broad but high-level look at the
BI solution and strategy, it is possible to identify issues and risks with the
solution design or implementation approach that will negatively impact
the outcome.

Gap solution design

The Gap solution design workshop is designed to ensure that the gap solution design
provides a good approach and plan to deliver a well-defined, well-tested, reliable,
and safe solution. You can complete this approach by collecting insights on the
implementation activities, reviewing the current gap solution blueprint, and raising
recommendations/risks/issues that are related to the planned customizations.

Data migration

The Data migration workshop offers advice and guidance when you are doing data
migration with Dynamics 365. The workshop provides best practices to help you
avoid data migration performance issues, gain a proper understanding of business
goals, and develop awareness on realistic throughput.

Security model

The Security model workshop delves into the customer-designed security model in
Dynamics 365 to help you understand the unique needs of organization security
requirements and review granularity of access control, administrative ease, and
impact on scalability. This workshop helps the solution architect collect the correct
information from customers by asking the right questions through assessing needs
and looking at different aspects of their designed security model.

Integration design

One strength of Dynamics 365 and Microsoft Power Platform is the offering of many
integration opportunities. For successful integration between systems, you need to
ensure that the design has purpose and review. The purposes of the integration
design review are to:
  Drive communication and understanding – The review is designed to
drive a conversation about overall plan for integrations and design
aspects of specific interfaces by going through overall integration
strategy, integration patterns, and middleware selection (if a middleware
is used), and by thoroughly investigating specific business critical
integration scenarios, monitoring and alerting approach, and any
Microsoft 365 integrations.

 Identify risks and issues – By taking a broad but high-level look at the
integration aspect of the solution, it is possible to identify issues and risks
with the integration design or implementation approach that will
negatively impact the outcome.

Dual-write implementation

The purposes of the Dual-write implementation workshop are to:

 Drive understanding on how dual-write will be used in the customer

scenario – The Dual-write implementation workshop is designed to drive
a conversation about how different apps will integrate by using dual-
write.

 Identify risks and issues– By taking a broad, but high-level look at the
solution, it is possible to identify issues and risks with the solution design
or implementation approach that will negatively impact the outcome.

 Identify or discuss gaps – Identify areas where dual-write might not be

fit for the purpose, and discuss identified gaps and alignment with the
dual-write roadmap.

Solution performance

The Solution performance workshop provides guidance and best practices for
solution design in respect to performance. The workshop will increase awareness of
the impact that certain types of configuration and/or customization have on the
overall performance and user experience. This workshop will also emphasize the
importance of having defined performance goals and having the right focus on
performance and performance testing during the entire project life cycle.

The purposes of the Solution performance workshop are to:

 Evaluate planning and readiness activities for conducting meaningful

performance testing.
  Collect requirements and design for the project that might ultimately
impact performance or areas that are already identified as problem areas.

 Identify targeted sections of the solution. Enterprise solutions tend to be

broad. The intent is not to cover every feature of your solution but to
target the areas that will create the most impact for users.

 Define clear goals and objectives and use the appropriate tools and
processes for implementing performance testing.

Cutover strategy

The Cutover strategy workshop is designed to ensure that the cutover strategy
provides a good approach and plan to deliver a well-defined, well-tested, reliable,
and safe transition from current systems to the new production systems.

The goals of the Cutover strategy review are to:

 Drive communication and understanding – The review is designed to

drive a conversation about the multiple aspects of cutover across the
various business and technical teams. The cutover has significant
components that the business teams need to own and drive beyond the
technical data migration tasks, and the workshop helps to ensure that the
goals, planning, and approach are aligned and well-understood from the
beginning.

 Identify risks and issues – By starting with a review of the overall

cutover vision and strategy at an early stage, you can identify risks early.
The cutover reviews during the implement phase are designed to identify
risks to keeping the cutover milestones on track and ready for final go-
live cutover.

Post go-live strategy

The goal of the overall Success by Design framework is to ensure a successful

customer outcome for each implementation.

The purposes of the Post go-live workshop are to:

 Review project goals and lessons learned – Following the go-live

event, reviewing the project goals achievement against success measures
will help you determine if project adjustments are necessary, and the
reflection on the lessons learned will prevent past issues from
reoccurring.
  Provide feedback on Dynamics 365 and the FastTrack program –
Providing candid feedback will allow the solution and the FastTrack
program to be improved.

 Deliver insights on the next implementation phases – Sharing what’s

next for the project/program after go live will allow a global
understanding of where the digital transformation is heading.

 Review support plans – Having a clear escalation path with the

appropriate support plan for post go-live issues will allow an optimal
time-to-resolution for all future incidents.

 Review the customer advocacy program – Joining the customer

advocacy program will ensure a strong connection with the Microsoft
Dynamics 365 product team and the Dynamics 365 community.

 Wrap up with a FastTrack graduation – The Post go-live workshop

wraps up the FastTrack engagement.

Next unit: Reasons to use Success by Design

Reasons to use Success by Design

Completed100 XP
 7 minutes

When your team decides to follow Success by Design, you are on a good path to a
successful implementation. The guidance relies on all participants to be actively
engaged and actively sharing information. The guidance works best when enough
information is shared to help ensure informed decision making.

Success by Design has been created to achieve five key goals on Dynamics 365
projects, as shown in the following diagram.
Product direction strategic alignment
Dynamics 365 and Microsoft Power Platform are rapidly evolving, and the way that
you customize or design solutions on the platform today is different from how they
were done a few years ago. A large part of a solution architect's role is making sure
that customer and partner teams are aware and aligned with the product direction.
Whether it's to do with using a Microsoft Power Automate flow instead of traditional
workflows, or embedding canvas apps instead of using dialogs, these inputs are
critical to a customer program and will help you save time and effort by avoiding
rework later. Success by Design workshops give the project team critical insights into
the customer program and an opportunity to provide timely recommendations to
ensure alignment with Microsoft product strategy and roadmap.

Innovation evangelism
Dynamics 365 and Microsoft Power Platform enable digital transformation within
customer organizations. The promise of a cloud-based digital transformation
platform should allow organizations to innovate at a faster pace and have a
competitive business advantage. One way to develop this competitive edge is
adoption of the latest production innovations. It's important for you to determine if
your customer's Dynamics Service Management system is using omnichannel
capabilities and if they're using customer insights for AI. Success by Design provides
you with an opportunity to influence the key project stakeholders through targeted
feature recommendations during the workshops and help customers define their
internal solution roadmap.

Best practices and knowledge sharing

Success by Design recommendations rely heavily on the learning and knowledge
from working with different customers and actively sharing these insights with the
solution architect community. Over time, the individual atomic Success by Design
recommendations have been distilled into best practices to take the form of collateral
that can be shared with those who are using the guidance.

Execution excellence
As individual contributors, solution architects are responsible for the success of their
customers. Success by Design brings the necessary structure to drive greater
consistency in the way that they can engage with their customers and in the way that
they measure and report on their success. Success by Design also helps boost
productivity and effectiveness through the following features:

 A ready-made workshop template deck

 Use of an on-demand TechTalk for standardized guidance
 List of checkpoint questions to drive conversation
 Reuse of recommendations across customers

Escalation management
Solution architects and project teams are familiar with reactive situations that can
potentially derail a project and cause go-live delays. Implementation or performance
issues could come from a bad design, from not following best practices, or due to
product regression or bugs that are not fixed in time. While Success by Design should
help minimize implementation-related escalations through proactive workshops and
review checkpoints, you might still find yourself in escalation situations that will
involve leadership and executives. A large part of escalation management is
articulating the business impact and situation in the context of the customer. Success
by Design can help provide the necessary context and historical perspective in the
form of the workshop findings and recommendations, success measures, follow-up
actions, and so on.

Next unit: Success by Design phases

Success by Design phases
Completed100 XP
 9 minutes

Success by Design has been created so that a solution architect can engage with
customers regardless of their delivery methodology. With agile projects, the phases
and workshops will likely be repeated in some capacity throughout the life of the
project. This guidance will map the Dynamic 365 implementation life cycle into four
methodology-agnostic phases:

 Initiate
 Implement
 Prepare
 Operate

Initiate
In the initiate phase, the project team is in discovery mode, where they are gathering
and validating business requirements, finalizing the high-level solution approach,
making inroads to define all in-scope workstreams, and revising the project plan to
reflect these updates. When the project team has produced the high-level solution
design, and when the related project workstreams are mostly defined, Success by
Design begins with the Solution blueprint review.

The initiate phase is one of the most important parts of the project because many
decisions that are made in this phase will impact the success of the deployment.
Occasionally, it might be tempting to rush through this phase so that you can begin
building the system, but it's important to have a plan and design before you start
building.

 In the initiate phase, the project is typically in a discovery mode, where

you are gathering business requirements, finalizing the high-level
solution approach, and planning the scope of work.
 Ideally, the solution architect will engage in this phase and introduce
Success by Design, the workshops involved, key success measures, and so
on. The solution architect will also propose and schedule the Solution
blueprint workshop.
 While in the discovery mindset, the project teams might respond with
specific questions that are related to service, tenant management,
product fit, and so on. The solution architect can address these questions.
 When the team has produced a high-level solution approach, the key
integrations are identified, and a high-level project plan is ready, the
Solution blueprint workshop should be planned and implemented.
 The Solution blueprint workshop review should also help highlight areas
with higher complexity (such as complex data models, large data
migrations, and integrations) so that the respective implementation
workshops can also be planned.
 Regardless of the project stage and progress, the Solution blueprint
workshop is an important exercise and should be done for all
engagements.

Implement
In the implement phase, the project team is focused on building the solution
according to the agreed-upon solution design and scope. Implementation reviews
are introduced in this phase, having been informed by the findings and
recommendations of the Solution blueprint review. Implementation reviews are used
to thoroughly address questions that are related to the specific aspects of the
solution design (data model, security, integration) and implementation practices
(ALM and testing strategy). Implementation reviews fully address the risks that are
identified during or after the Solution blueprint review but before the solution build is
too far along in the process.

 Regardless of the delivery methodology, whether waterfall or iterative,

the solution architect should schedule the implementation workshops
that are planned during the Solution blueprint workshop. However, while
the precise methodology is up to each project owner, Dynamics 365
implementations are best suited for iterative and/or agile delivery
methods.
  The implementation workshops should be planned before you finalize
the detailed design of the component.
 Some implementation workshops won't be relevant to or targeted at
components that are considered low risk, in which case, the
corresponding implementation workshop can be skipped.
 During the implementation phase, you can expect questions that are
related to the design of specific components, technology choices,
upcoming changes, and roadmap, deprecations, application lifecycle
management (ALM), and build.
 Make sure that you proactively work with customers to ensure that the
developed solution is in accordance with best practices and is
strategically aligned to the product roadmap.

Prepare
By the prepare phase, the solution has been built and tested, and the project team is
preparing for the final round of user acceptance testing (UAT) and training.
Additionally, all necessary customer approvals have been granted, information
security reviews are completed, the cutover plan is defined (including go/no-go
criteria), mock go-live events are scheduled, the support model is ready, and the
deployment runbook is completed with tasks, owners, durations, and defined
dependencies. At this point, the project team will use the Success by Design go-live
readiness review to identify remaining gaps or issues.

 You're also validating the non-functional requirements of the system (like

the form load times, search performance, and integration performance
under the realistic production load).
 The customer or partner has gone through all internal approvals,
information security reviews, penetration testing, and so on, to ensure
the production readiness of the system.
 The support model post go live is defined and agreed with the business.
 The cut-over plan, the go-live date, and go/no-go criteria are agreed on
with the business, and the production deployment plan has been created
with all tasks, owners, start time, duration, and rollback plan.
 The solution architect conducts the Go-live readiness workshop to review
the plan and highlight gaps and issues.
 The solution architect also ensures that the proactive performance checks
and the solution checker are implemented.

Operate
You've now planned, developed, and deployed the application, but you're not
finished yet. The goal of this phase is to validate the success of the deployment,
review lessons learned from the project, and plan for the transition to the next phase
or provide transitional support to the maintenance team.

 After the customer is live, the solution architect should perform a post
go-live review.
 Discuss the transition plan and share the same with the maintenance
team.

Next unit: Implement Success by Design

Implement Success by Design

Completed100 XP

 15 minutes

This unit describes how the Success by Design process should be implemented, from
using the template to presenting the findings and recommendations. Success by
Design is designed to be flexible; you can adapt it to your delivery style. However, the
structure of your delivery should be clear enough for anyone to follow.

Align expectations
Success By Design is intended to help the solution architect be more proactive during
their engagement with the project teams, discover the customer's goals, understand
what was designed in terms of architecture, and identify and avoid areas where
project teams often run into issues during projects.

The solution architect should be considered a trusted advisor who uses the
knowledge and experience from working on other projects and shares that
experience and best practices to help avoid issues. Accordingly, the solution architect
can help ensure that the customer can go live confidently and successfully.

In an engagement, the solution architect needs to make sure that stakeholders

understand the goals of the workshop deliverables and why they're important.

In the Solution blueprint workshop, you can expect to gain insights that you can use
in the project (plan, milestones, goals, scope, and so on.). This workshop is beneficial
for the project team during implementation because it helps them create a plan for
what will be built (integrations, interfaces, solutions, and so on.), determine at what
stage the project will be delivered, and ensure that the project plan is aligned with all
stakeholders and project scope.

The goal of the Implementation workshop is to be proactive by thoroughly examining

areas where the most common issues can affect project plans and milestones, and
then identify and raise awareness of risks and functionality gaps. By identifying these
risks and gaps, you can create a plan to mitigate risks and avoid common
deployment problems.

In the Go-live readiness workshop, the goal is to understand and help shape the
customer's go-live strategy and compare this strategy with best practices. With this
approach, you can help avoid surprises during go live, the most critical phase of the
project.

Workshop outcome

After each workshop, the solution architect will prepare a list of findings and
recommendations based on what was learned during the workshop. A follow-up
meeting should be scheduled to discuss recommendations as needed.

While the solution architect will be thorough in the workshops, it's not expected that
every possible concern about the project will be raised and that all project issues will
be avoided. The solution architect will only be reviewing the information that is
shared by the customer and partner teams, and if any piece of information is not
shared (or not shared to a sufficient level of detail), that information won't be
included in the review.

The reviews are performed by comparing best practices and experiences from other
engagements with your project and business processes. Though you can’t assure
attendees that issues won’t arise during a project, you can emphasize the importance
of understanding the information that is and isn't assessed during the review.

Considerations that you should be aware of regarding the workshop outcome

include:

 Quality of the code that the developers have written isn't validated by
Success by Design. While ways of checking the code exist, those
validations won't confirm code logic.

 Solution architecture is reviewed at a high level, but granular details

about how it's been built will not be reviewed. For example, if you have a
Power Automate flow that was built for a specific purpose, don't review
the design of the flow. If the flow uses 10 steps to do what could have
been done in only two steps, it is out of the review scope.
  The architecture, integrations, interfaces, and design are checked at a
high-level view to determine if the solution is best aligned with available
options, best practices, and Microsoft roadmap. An example of this
situation is if you decide not to use an on-premises virtual machine
because it might be in a Microsoft Azure location that is in the same data
center as the customer's Dynamics 365 environment.

Prepare
After the customer and partner teams understand why the workshops are needed,
you can send them the workshop templates, which are short and simple and provide
notes that explain the goals of the questions that are asked in each slide. The short
templates help minimize potential resistance that the customer and partner teams
might have in providing the information that you are requesting.

The solution architect should send the PowerPoint template to the customer and
partner teams at least one week before the workshop is scheduled, which will give
them time to receive it and add requested information. Adjust this time
recommendation depending on the complexity of the deployment or if new features
have been added that you want to investigate first.

When you receive the revised PowerPoint file from the customer, schedule time on
your calendar to review the information that they provided in the file and then start
preparing the delivery of the workshop.

Workshop preparation starts by knowing the audience. The solution architect should
work with the project teams to identify who should attend, which will vary by topic of
the workshop.

If the audience is large, and a mixture of many different roles and departments,
consider splitting the workshop into multiple sessions. The risk of overrun is high
when the audience is too large or diverse.

Prepare and send an agenda to the attendees in advance of the workshop. Include
session times and named resources in the agenda. This preparation will allow
attendees to provide feedback if they think that more time will be needed and help
keep to the agreed-to time for each topic during the workshop.

Deliver
During the workshop, content should be presented by the customer and/or partner
as appropriate. While the customer and/or partner deliver the content, you should
take notes. A good practice is not to interrupt the presentation and wait until the end
of each slide before asking questions or waiting for the presenter to pause.

The workshop delivery should sound like a conversation and not an inquiry. Keep the
questions short and relevant. The workshop delivery should always start with the
agenda and takeaways and then finish with the next steps. You need to help ensure
that everyone understands what will happen next.

After the workshop, review your notes and update them while the information is fresh
in your mind. Verify that your notes are complete because they will be the basis of
your findings and recommendations.

General guidance for a successful workshop

The following guidelines will help you conduct a successful workshop:

 Each meeting might include people who were not in previous sessions, so
you should always start a workshop session by introducing yourself and
by being prepared to include your background and experience with
Dynamics 365 or Microsoft Power Platform.

 Make sure that someone takes notes during every session. You might not
always be the note taker (especially during face-to-face meetings), but
always verify that someone is taking detailed notes, and then get a copy
of the notes following the session.

 Be confident in your experience and knowledge and share that with the
team.

 Read the audience to help understand their technical level. Keep to the
agreed technical level of the workshop. For example, a solution blueprint
review will be high level, and you should stop if it's too in-depth. It's
better to schedule a follow-up session than overrun or be tight on time in
the current session.

 In business sessions, do not focus on the how; you need to understand

the why.

 In technical sessions, don't forget the why, even if focus is on the how.

 Capture all actions and open topics as you go through the session.
However, ensure that you have 5-10 minutes at the end of the workshop
to summarize the actions.
Follow-up
After workshop delivery, the solution architect should prepare findings and
recommendations. This preparation can be time-consuming, so be sure to give
yourself enough time when scheduling the follow-up discussion. Meeting notes and
agreed-on follow-up actions should be sent to participants and needed stakeholders
within 24 hours after the session. Follow-up actions should include the responsible
party and deadline. If no deadline has been agreed to, use TBD. In the meeting notes,
share issues and risks.

Workshop steps
The workshop involves three key steps:

 Information capture
 Run the workshop
 Create recommendations and findings

The project solution architect, or someone who's not on the project daily, can
conduct the workshop. The benefit of having a non-project assigned solution
architect conduct the workshop is that it will be similar to how FastTrack projects run.
Often, this approach offers a project team additional insights that come from a
project outsider.

Information capture

While all projects do have some level of documentation, the level of documentation
and format can vary depending on the stakeholders, project scope, and project
methodology. The workshop template is designed to collect the information that is
relevant to the project's success measures and document them in a structured
fashion. Frequently, the project teams have this information handy and they can copy
from existing project documents. However, it's not uncommon for information to
exist in multiple places and be difficult to consume and share with the teams. As a
part of this step, the solution architect can share the workshop template with the
customer and ask them to fill out the information and return it at least five days
before the workshop is scheduled to happen. This step will allow sufficient time for
review.

Tip

Work with your stakeholders closely on information capture. Provide them with the
necessary help to fill out the template, and you can prefill the information that you
already know. In some cases, stakeholders might also share the complete document,
which might require additional time to review and filter out relevant information. The
quality of information that is exchanged will impact the quality of recommendation
and will set a precedence for other workshops.

Run the workshop

The workshop can be conducted on site or by using an online meeting. Typically, the
decision to conduct the workshop on site or online will be based on the complexity of
the project, risks, and customer size. As part of this preparation, the solution architect
should review the completed templates and prepare additional questions and
comments for further clarity.

 Schedule the workshop to ensure that the key stakeholders have

accepted. The completed template will be the primary workshop artifact.

 Adjust or customize the deck for customer or project-specific topics and

questions.

 During the workshop, review each topic with the customer and share
your understanding.

 Ask questions to gain further clarity as needed. Review the questions that
you captured for each topic while reviewing the workshop template for
each topic. The intent isn't to share these questions directly with a
customer but to use them during the workshop to drive the conversation
and assess the client's readiness on the related topic/success metric.

Create recommendations and findings

After the solution architect has gained an understanding of the client, project scope,
and solution, they should be able to highlight the good practices and deployment
patterns that should be followed. They should raise visibility for potential risks, such
as potential scalability or performance issues. You should document your findings
and categorize them as risks or recommendations.

 Risks - Require follow-up actions, such as not planning for adequate

failure testing of key integrations. Often, risks will also be discovered as
review and discussions happen during the workshop.

 Recommendations - Include areas that need to be reviewed to make the

solution more consistent and reliable and help move the project to a
successful completion. For example, frequently, you might discover that
adequate configuration isn't available to allow testing integrations in
 multiple environments. Make sure that your recommendations are
actionable and clear.

Next unit: Track Success by Design activities and

progress

Track Success by Design activities and

progress
Completed100 XP
 5 minutes

The FastTrack team has tools that they use for tracking activities, progress, and plans
throughout an engagement. As you continue through your projects, it's a good idea
to have your own plans to do this as well.

Workshop success measures

When evaluating each workshop, you will have many named measures of success.
Your team should make an assessment for risk and preparedness for each that
applies. Having a repeatable and straightforward unit of measure is important to the
success of the project. Consider each measure listed in the following table, and then
adapt the precise wording to suite your own team.

Expand table
Status Meaning
Empty Waiting for assessment
Red Finding uncovered critical changes that need to be implemented in the project
Yellow Finding uncovered changes that should be implemented in the project
Green No relevant findings

You can use the Success by Design workshops to guide you toward each success
measure. The following table is an example of a matrix that tracks workshops and
their relevance to different aspects of a project. A solution architect can use a matrix
like this one to track progress with relevance. As you continue through the project,
make sure that you keep a list of relevance and an overall assessment and risk
analysis for each workshop by using the color coding that is mentioned in the
previous table. Consider sharing the status with all stakeholders as often as possible
to avoid surprises and potential delays.

Expand table
Category Group Category Solution Blueprint Cutover Solution performance
review readiness workshop
Architecture Application extension X X
Architecture Business intelligence X X
Architecture Data migration X X
Architecture Data model X X
Architecture Functional X X
Architecture Instance strategy X
Architecture Integration X X
Architecture ISV X X
Architecture Performance X X X
Architecture Security X X
Architecture User experience X X
Competency Customer X
Competency Partner X X X
Fit for purpose Presales X
Fit for purpose Product/solution fit X
Fit for purpose Under-licensed projects X
Implementation Application lifecycle X
management
Implementation Business continuance X X
planning
Implementation Change management X X
Implementation Continuous update X X
Implementation Cutover X X
Implementation Fit-gap analysis X
Implementation Rollout approach X X
Implementation Testing X X X
Other External factors X X
Product Feature deprecation X X
Product Feature gaps X X
Product Product bugs X
Product Product performance X X X
Product Product reliability X X X
Project General governance X
governance approach
Project Schedule X
governance
Support Support X X

When you start working on the project, and after you have conducted a workshop,
you should immediately update the relevant success measures, particularly if any
concerns arise. Also, make sure that you update and complete the appointment with
time/attendees/status and any other notes.

Next unit: Check your knowledge

Check your knowledge

Completed200 XP
 6 minutes

Answer the following questions to see what you've

learned.
1.

Which of the following selections is not a Success by Design workshop?

Data model
Success by Design includes several workshops, including Solution blueprint,
Data model, User experience, Data migration, Test strategy, Security, Solution
performance, and Go-live readiness. User training isn't a workshop that is
included in Success by Design.
Test strategy
Solution performance
User training
Success by Design includes several workshops, including Solution blueprint,
Data model, User experience, Data migration, Test strategy, Security, Solution
performance, and Go-live readiness. User training isn't a workshop that is
included in Success by Design.
2.

Success by Design has been created to achieve which of the following five key
goals on Dynamics 365 projects?

Microsoft Power Platform strategy, innovation evangelism, best practice and

knowledge sharing, Azure data management, and escalation management
The five key goals of Success by Design are product direction strategic
alignment, innovation evangelism, best practice and knowledge sharing,
execution excellence, and escalation management.
Product direction strategic alignment, innovation evangelism, best practice and
knowledge sharing, execution excellence, and escalation management
The five key goals of Success by Design are product direction strategic
alignment, innovation evangelism, best practice and knowledge sharing,
execution excellence, and escalation management.
Product direction strategic alignment, design functionality, best practice and
knowledge sharing, Azure data management, and escalation management
Microsoft Power Platform strategy, design functionality, best practice and knowledge
sharing, execution excellence, and escalation management
3.

In which phase of a project framework are you preparing for UAT (user
acceptance testing)?

Initiate
In the prepare phase, most of the functionality has been built and you're
preparing for user acceptance testing and training.
Implement
Prepare
In the prepare phase, most of the functionality has been built and you're
preparing for user acceptance testing and training.
Operate

Summary
Completed100 XP
 2 minutes

Success by Design can help guide the success for your solutions. By following the
prescribed guidance, your projects can have the same success as those projects that
are implemented by the FastTrack team, even if the specific project doesn't qualify for
FastTrack directly.

Create a solution blueprint for

Dynamics 365 solutions
 1 godz. 4 min
 Module
 8 Units
Feedback
Advanced
Solution Architect
Functional Consultant
Dynamics 365
Sales
Customer Insights - Journeys
Customer Service
Field Service
Finance
Supply Chain Management
Project Operations
Commerce
Human Resources

The Solution blueprint workshop is part of Success by Design. This module focuses
on creating the blueprint, and conducting the workshop to create it.

Learning objectives
In this module, you will:
 Learn how to identify project goals
 Learn about the project's tenant strategy
 Consider any non-functional requirements
 Learn how to prepare, and conduct the Solution blueprint workshop
Dodaj

Prerequisites
 Familiarity with the Success by Design process
 Previous experience as a Solution Architect on a project is helpful
 Download an example of the template for this workshop from GitHub
location

Introduction
Completed100 pkt.
 8 minutes

Having a reliable solution blueprint is essential to the success of implementation. The

blueprint provides a foundation for the architecture of the solution and the approach
to implementing it. Without having that foundation in place, any subsequent
activities are at risk of not fully supporting the goals and ultimate success of the
solution. As such, we recommend that you conduct the Solution blueprint review as
close to the beginning of the implementation as possible. Conducting the review
early will allow you to minimize the impact of issues that are found and identify risks
before they become issues.

The Solution blueprint review also forms the basis of the solution architect’s
understanding of the planned solution, and it provides an overall context in which to
provide guidance. Without context, it is difficult to ensure that recommendations will
be effective for the overall architecture. For that reason, the Solution blueprint review
is the first major activity within the Success by Design framework following the
kickoff. The solution architect should not engage in other in-depth activities without
first understanding the broader solution blueprint.

The following questions and answers are typically discussed during the Solution
blueprint review workshop.

 Question - How can you review a solution blueprint before

implementation has completed requirements gathering and an initial
design?
 Answer - Most implementations begin with a planned timeline, or at
least a target go-live date, and defined budget. These factors should be
based, at a minimum, on a conceptual solution and approach. That
conceptual design and approach are all that is needed for the Solution
blueprint review. If deficiencies occur in these areas, the Solution
blueprint review will help identify them early so that they can be
addressed.
 Question - You want the Solution blueprint review to cover the entire
solutioning and you don’t want to miss the review on solution aspects
that aren’t yet ready in the early project phases. Can you postpone the
workshop until a later stage of the project to cover more scope?
 Answer - If needed, the Solution blueprint review can be implemented as
an iterative process. If over the course of the implementation, aspects of
the solution change, you can review deltas in subsequent iterations of the
workshop or through in-depth workshops. This module will later cover
subsequent solution blueprint reviews. As such, the initial workshop
should be delivered as early as possible in the project.

Solution blueprint review workshop

overview
Completed100 pkt.
 15 minutes
The Solution blueprint review is a workshop that can be conducted in person, in
which case, it is typically ran as single workshop that covers all required topics. The
workshop can also be conducted remotely. When the workshop is done remotely, it is
typical to divide the review into several sessions over several days.

The following sections cover the top-level topics of the Solution blueprint review and
provide a sampling of the types of questions that are covered in each section.

Program strategy
Program strategy covers the process and structures that will guide the
implementation. It also reviews the approach that will be used to capture, validate,
and manage requirements, and the plan and schedule for creation and adoption of
the solution. This topic focuses on answering questions such as:

 What are the goals of the implementation, and are they documented,
well understood, and can they be measured?
 What is the methodology being used to guide the implementation, and is
it well understood by the entire implementation team?
 What is the structure that is in place for the team that will conduct the
implementation?
 Are roles and responsibilities of all project roles documented and
understood?
 What is the process to manage scope and changes to scope, status, risks,
and issues?
 What is the plan and timeline for the implementation?
 What is the approach to managing work within the plan?
 What are the external dependencies and how are they considered in the
project plan?
 What are the timelines for planned rollout?
 What is the approach to change management and adoption?
 What is the process for gathering, validating, and approving
requirements?
 How and where will requirements be tracked and managed?
 What is the approach for traceability between requirements and other
aspects of the implementation (such as testing, training, and so on)?
 What is the process for assessing fits and gaps?

Test strategy
Test strategy covers the various aspects of the implementation that deal with
validating that the implemented solution works as defined and will meet the business
need. This topic focuses on answering questions such as:

 What are the phases of testing and how do they build on each other to
ensure validation of the solution?
 Who is responsible for defining, building, implementing, and managing
testing?
 What is the plan to test performance?
 What is the plan to test security?
 What is the plan to test the cutover process?
 Has a regression testing approach been planned that will allow for
efficient uptake of updates?

Business process strategy

Business process strategy considers the underlying business processes (the
functionality) that will be implemented on the Microsoft Dynamics 365 platform as
part of the solution and how these processes will be used to drive the overall solution
design. This topic focuses on answering questions such as:

 What are the top processes that are in scope for the implementation?
 What is currently known about the general fit for the processes within the
Dynamics 365 application set?
o How are processes being managed within the implementation
and how do they relate to subsequent areas of the solution
such as user stories, requirements, test cases, and training?
o Is the business process implementation schedule documented
and understood?
o Are requirements established for offline implementation of
business processes?

Based on the processes that are in scope, the solution architect who is conducting the
review might ask a series of feature-related questions to gauge complexity or
understand potential risks or opportunities to optimize the solution based on the
future product roadmap.

Application strategy
Application strategy considers the various apps, services, and platforms that will make
up the overall solution. This topic focuses on answering questions such as:
  Which Dynamics 365 applications or services will be deployed as part of
the solution?
 Which Microsoft Azure capabilities or services will be deployed as part of
the solution?
 What if new external application components or services will be deployed
as part of the solution?
 What if legacy application components or services will be deployed as
part of the solution?
 What extensions to the Dynamics 365 applications and platform are
planned?

Data strategy
Data strategy considers the design of the data within the solution and the design for
how legacy data will be migrated to the solution. This topic focuses on answering
questions such as:

 What are the plans for key data design issues like legal entity structure
and data localization?
 What is the scope and planned flow of key master data entities?
 What is the scope and planned flow of key transactional data entities?
 What is the scope of data migration?
 What is the overall data migration strategy and approach?
 What are the overall volumes of data to be managed within the solution?
 What are the steps that will be taken to optimize data migration
performance?

Integration strategy
Integration strategy considers the design of communication and connectivity
between the various components of the solution. This strategy includes the
application interfaces, middleware, and the processes that are required to manage
the operation of the integrations. This topic focuses on answering questions such as:

 What is the scope of the integration design at an interface/interchange

level?
 What are the known non-functional requirements, like transaction
volumes and connection modes, for each interface?
 What are the design patterns that have been identified for use in
implementing interfaces?
 What are the design patterns that have been identified for managing
integrations?
  What middleware components are planned to be used within the
solution?

Business intelligence strategy

Business intelligence strategy considers the design of the business intelligence
features of the solution. This strategy includes traditional reporting and analytics. It
includes the use of reporting and analytics features within the Dynamics 365
components and external components that will connect to Dynamics 365 data. This
topic focuses on answering questions such as:

 What are the processes within the solution that depend on reporting and
analytics capabilities?
 What are the sources of data in the solution that will drive reporting and
analytics?
 What are the capabilities and constraints of these data sources?
 What are the requirements for data movement across solution
components to facilitate analytics and reporting?
 What solution components have been identified to support reporting
and analytics requirements?
 What are the requirements to combine enterprise data from multiple
systems/sources, and what does that strategy look like?

Security strategy
Security strategy considers the design of security within the Dynamics 365
components of the solution and the other Microsoft Azure and external solution
components. This topic focuses on answering questions such as:

 What is the overall authentication strategy for the solution? Does it

comply with the constraints of the Dynamics 365 platform?
 What is the design of the tenant and directory structures within Azure?
 Do unusual authentication needs exist, and what are the design patterns
that will be used to solve them?
 Do extraordinary encryption needs exist, and what are the design
patterns that will be used to solve them?
 Are data privacy or residency requirements established, and what are the
design patterns that will be used to solve them?
 Are extraordinary requirements established for row-level security, and
what are the design patterns that will be used to solve them?
 Are requirements in place for security validation or other compliance
requirements, and what are the plans to address them?
Application lifecycle management strategy
Application lifecycle management (ALM) strategy considers those aspects of the
solution that are related to how the solution is developed and how it will be
maintained given that the Dynamics 365 apps are managed through continuous
update. This topic focuses on answering questions such as:

 What is the preproduction environment strategy, and how does it

support the implementation approach?
 Does the environment strategy support the requirements of continuous
update?
 What plan for Azure DevOps will be used to support the implementation?
 Does the implementation team understand the continuous update
approach that is followed by Dynamics 365 and any other cloud services
in the solution?
 Does the planned ALM approach consider continuous update?
 Who is responsible for managing the continuous update process?
 Does the implementation team understand how continuous update will
affect go-live events, and is a plan in place to optimize versions and
updates to ensure supportability and stability during all phases?
 Does the ALM approach include the management of configurations and
extensions?

Environment and capacity strategy

Deployment architecture considers those aspects of the solution that are related to
cloud infrastructure, environments, and the processes that are involved in operating
the cloud solution. This topic focuses on answering questions such as:

 Has a determination been made about the number of production

environments that will be deployed, and what are the factors that went
into that decision?
 What are the business continuance requirements for the solution, and do
all solution components meet those requirements?
 What are the master data and transactional processing volume
requirements?
 What locations will users access the solution from?
 What are the network structures that are in place to provide connectivity
to the solution?
 Are requirements in place for mobile clients or the use of other specific
client technologies?
  Are the licensing requirements for the instances and supporting
interfaces understood?

Prepare for the Solution blueprint

review
Completed100 pkt.
 10 minutes

Typically, the Solution blueprint review takes approximately two to eight hours to
conduct. The time might vary based on the level of detail that is available for review
and the breadth of the overall solution. The solution architect will work with the
implementation team leadership to plan the workshop based on the specifics of the
solution that is being reviewed.

Prior to the Solution Blueprint Review workshop, workshop participants should make
sure that they are as familiar as possible with the structure of the workshop and the
types of topics and prerequisites that will be covered. The solution architect will
provide an agenda with topics and prerequisites ahead of the workshop.

Uwaga

The Solution blueprint review is essentially a discussion; it is not intended to be a

questionnaire that can be completed and reviewed in an offline mode. While the
prerequisites are defined and provided in advance, it is not possible to encapsulate
the breadth of directions in which the conversation might lead.

The solution architect will prepare in advance for the workshop by reviewing existing
project artifacts ahead of time. Helpful project artifacts include:

 Process catalogs – Lists or hierarchies of processes, sub-processes, and

user stories that are in scope for the implementation.
 Process flow diagrams – Diagrams that can add context to the process
catalog and describe the operation of the business. At the Solution
blueprint review stage, the high-level, end-to-end processes are most
helpful.
 Application diagrams – Block diagrams showing the various
components that make up the solution. These diagrams can also provide
context that is related to how capabilities map to application
components or how application components will interface with each
other.
  Gap requirements – Known areas of functionality that are not viewed as
supported by the standard system.
 Data flow diagrams – In a solution that includes multiple Dynamics 365
apps, legacy, or external services and components, it is helpful to be able
to identify where data originates and how it moves and is consumed in
the solution.
 Data migration strategy – Documents or registers that show the entities
to be migrated, the sources they will come from, the volumes, the timing,
and the methods for migration. At the solution blueprint stage, it is key
to ensure that you have scope (tables and sources).
 Interface register – Lists of interfaces with non-functional requirements
and design patterns that document the scope and approach for
implementing those interfaces.
 Analytical data aggregation design – Diagrams or registers of data
sources that will be migrated for aggregated analytics.
 Environment strategy – Block or flow diagrams that outline the types of
environments that will be provisioned and how and when they will be
used and how code and configuration will flow through them.
 System usage profiles – Operational process schedules and peak
transactional volumes by workload type.
 Legal entity structure – Diagrams or registers that show the legal
entities that will be modeled in the solution and their relationships to
each other.
 Deployment locations – Diagrams or registers that show the physical
locations where the solution will be deployed along with language and
localization requirements.
 Project charter – Document providing the background of the project,
objectives, and expected key results, stakeholders, budgets, timelines,
and milestones.
 Project plan/schedule – Document or Gantt charts that depict the
overall schedule and dependency of key project phases and their
associated activities.
 Responsibility assignment matrix – Table of tasks and project roles’
relationship to those tasks. These relationships are typically assigned
through an RACI classification (responsible, accountable, consulted,
informed)
 Test plan/strategy – Document describing the types of testing that will
be done throughout the implementation and how tests will be defined,
implemented, and measured.

This list is not exhaustive of project deliverables, but it is a good starting point for the
Solution blueprint review. The formats, composition, and names of each deliverable
might vary from one project to the next. Format isn’t the most important component;
it is the information that is available and agreed on across the team that is essential.
When you are conducting a Solution blueprint review early in the project, many of
these documents will not be fully formed, which is acceptable in most cases. It’s more
important that scope has been determined and that a conceptual plan is in place to
determine how the solution will support that scope. If the plan is unsuccessful, these
items should be represented at some level in the statement of work that is provided
by the consulting partner who is assisting with the implementation. If the scope and
conceptual solution approach are in place, the Solution blueprint review can focus on
the conceptual approach, and the follow-up, in-depth workshops can focus on the
details at the point when they are available.

It is acceptable if your project is using different ways to manage or track project

information other than what was previously listed. Typically, format is not critical, if
the information is readily available to project members. If the previously listed
information is not documented on your project, or if it is documented in a way that it
is not easily accessible, you should prioritize getting the relevant artifacts produced.

We recommend that you use diagrams and visual representations to provide high-
level summaries, where possible, in the implementation. These diagrams, charts, and
graphs provide a ready means of communication across the team and with executives
about plans and designs.

Uwaga

The Solution blueprint review is not intended to be an exhaustive review of detailed

requirements or design documents. The implementation team will work with lower
levels of detail to derive and present the overall architecture. The assumption is that
the implementation team will display key concerns, and architects will inquire into
potential problem areas. The solution architect will suggest in-depth workshops to
investigate areas that require additional assessment.

Solution blueprint review participants

Completed100 pkt.
 5 minutes

The Solution blueprint review is an excellent chance to establish a baseline for the
core project team on the overall solution. Having the broader team present in the
workshop can be a helpful way to provide context to the team. In some cases, due to
the size of the implementation team, it might be necessary to limit the participation
in the workshop to only core members of the implementation team. With that in
mind, you should consider the following guidelines:
  The workshop should be attended by representatives from the customer
organization and the partner organization that is assisting with the
implementation. Part of the review’s value is providing common
information for the solution across all involved parties.
 The workshop should include the project manager and solution architects
from the customer and the partner organization. If the customer doesn’t
have a solution architect role in their organization, then the responsible
technical stakeholder(s) should be involved. If the partner organization
doesn’t have a designated solution architect who is responsible for the
implementation, then the equivalent delivery lead, functional lead, or
technical architects should be involved.
 In some cases, it might be necessary to bring specific resources for
specific topics, which can be accommodated based on the breakdown of
the solution in the workshop agenda.

The Solution blueprint review is an excellent opportunity to provide essential

information about the solution to the team. Occasionally, this review can benefit
executive stakeholders as well, but you should be aware that the discussions in the
workshop can be comprehensive in some areas and technically detailed in others.
You should set expectations from the beginning that the types of conversations in
the workshop might be at a lower level of detail than some executives might want to
consume.

Ukończono moduł:

Conduct the Solution blueprint review

workshop
Completed100 pkt.
 15 minutes

The Solution blueprint review workshop will be facilitated by the solution architect,
but the expectation is that the implementation team will present the solution
blueprint information. Each section of the agenda should be assigned an owner
within the implementation team. At the beginning of each session, that owner should
present an overview or summary of the scope and plans, including designs that apply
to that aspect of the solution. The team should plan for that summary to take
between 25-50 percent of the allotted time but no more. The remainder of the time
should be reserved for questions and answers with the solution architect.

The implementation team leadership should work with the solution architect ahead of
the workshop to shape the agenda and timings for each session. Depending on the
state and complexity of the solution, different sections might require more or less
time. While the baseline plan is to conduct the workshop in eight hours, that time can
be flexible to a certain extent to accommodate the implementation.

Time management in the Solution blueprint review workshop is critical. The top
priority for the workshop to get through the overall solution, which should be
prioritized over going too in-depth in any one session. If the conversation is going
too detailed and you are running out of time to cover the breadth of the solution,
you should expect the solution architect to discontinue the detailed conversations for
follow-up in a more comprehensive workshop.

Uwaga

You should set an expectation that, during each session, discussion about the scope
and approach will occur. As part of that expectation, the architect might provide
some guidance directly within the meeting. However, these sessions are not intended
to be design sessions but rather review sessions. The provided feedback might alter
the current plan or design, but the detailed work in those areas will be carried out by
the implementation team after the workshop.

Solution blueprint review outputs

The output of the Solution blueprint review workshop is a findings document. This
findings document is a response to information that has been provided as
preparation for the workshop or during the workshop. These findings will generally
be one of three types:

 Assertions – These findings relate to specific aspects of the solution that

the solution architect wants to call out as architecturally significant. These
assertions are factors that might not represent a specific risk or issue but
are foundational to the solution and should be noted because, if
changed, they will have significant impact. These assertions might relate
to specific scope items, design aspects of the solution architecture, or
implementation approach or technique.
 Risks – These findings represent an aspect of the solution or
implementation approach that constitute a risk that should be tracked on
the project. These findings could relate to existing plans, approaches, or
designs that have an observed potential for negative outcomes. They
 could also be related to areas of the solution that have not been
adequately explored yet, and as such, represent a risk that something
unexpected could come up. These findings will be accompanied by a
statement of what the solution architect views as a risk along with
recommended mitigation steps.
 Issues – These findings represent an aspect of the solution or
implementation approach that constitute an issue that is negatively
impacting the implementation, or if not corrected, will have a negative
impact in the future. These findings will be accompanied by a statement
of what the impact is or will be, along with recommended resolution
steps.

The findings document will be distributed to the customer and partner organizations,
and a review meeting will be held to assess the findings in detail. The document will
go to the implementation leadership and executive sponsors in both organizations.
The findings documents can, in some cases, be lengthy, in which case, an executive
summary that highlights key and critical findings is provided for better consumption
by executives.

Uwaga

The output of the Solution blueprint review workshop is not a solution blueprint. The
expectation is that the materials that the implementation team brings into the review
comprises the solution blueprint. The expectation is that the blueprint will continue to
evolve and expand as the implementation progresses.

Subsequent Solution blueprint reviews

In most cases, the Solution blueprint review that is performed at the beginning of the
implementation, supplemented by in-depth workshops, is sufficient for that
implementation. Occasionally, subsequent reviews are required. The following
examples are scenarios where additional Solution blueprint reviews might be
required:

 Challenges with the initial Solution blueprint review – In rare cases,

the Solution blueprint review workshop is unable to cover all required
information. The reason could be that major gaps or conflicts in the
understanding of the scope have occurred, and they need to be worked
out by the implementation team. Another reason could be due to a
significant lack of a conceptual solution design. In these scenarios, going
through the initial Solution blueprint review workshop early is valuable
because it highlights these issues so that they can be resolved, but it will
require the workshop to be repeated.
  Significant scope change – Occasionally, an implementation is impacted
by major changes in scope or approach due to a variety of potential
circumstances. This situation could include changes due to external
factors, but it could also be related to significant changes that follow
detailed requirement analysis. Following such a change, it will make
sense to reassess the solution blueprint.
 Organizational changes – Periodically, organizations will experience
significant change during an implementation. Events like mergers,
acquisitions, or divestitures can significantly impact a solution
architecture and might necessitate reevaluation.

Solution blueprint follow-up

Completed100 pkt.
 3 minutes

After the Solution blueprint review workshop has been conducted and the findings
have been reviewed, those items that have been identified as risks and issues, and
their associated action items for mitigation and resolution, will be managed to
completion as part of the overall engagement.

Identified issues will often have an impact on the ability to successfully go live. These
issues will need to be resolved prior to the go-live readiness assessment and the
deployment of a production environment.

Risks and their associated recommended mitigations can be managed according to

the overall strategy of the project, but they will be monitored throughout the project.
Risks that are not mitigated might be realized later as issues that could also affect the
go live.

Follow-up and in-depth workshops need to be supported by the project team

according to recommendations. This factor can affect risk and issue areas that are
identified within the Solution blueprint review workshop, including areas that require
the next level of details due to complexity.

Answer the following questions to see what you've

learned.
1.

What is the goal of the Solution Blueprint?

To gather and spread out historical documentation and mold the solution to fit
current business processes.
The goal of the Solution Blueprint is to describe just enough of the solution
architecture to give the team sufficient understanding of how the solution will
be realized and dependent technologies. By documenting the solutions
blueprint, you'll have the opportunity to identify challenges and gaps and build
a plan to remediate them.
To describe just enough of the solution architecture to give the team sufficient
understanding of how the solution will be realized and dependent technologies.
The goal of the Solution Blueprint is to describe just enough of the solution
architecture to give the team sufficient understanding of how the solution will
be realized and dependent technologies. By documenting the solutions
blueprint, you'll have the opportunity to identify challenges and gaps and build
a plan to remediate them.
To create a detailed and exact project plan.
To make sure that all managers and users understand the project goals and
expectations and will follow the leadership and strategies of the Solution Architect.
2.

Which of the following are part of the solution scope?

Phases and timelines

Setting the scope defines main functional areas, phases and timelines, and
includes details of the business.
Main functional areas
Business details
All of the above
Setting the scope defines main functional areas, phases and timelines, and
includes details of the business.
3.

When the initial Solution blueprint review is complete, what topics should be
evaluated in subsequent solution blueprint conversations?

Only one Solution blueprint workshop is conducted for each project

A project might cover aspects of a solution blueprint several times during the
delivery to accommodate changes or unresolved issues.
Organizational changes, such as mergers or acquisitions, that affect the project
Sometimes, projects are influenced by big changes in an organization, and it is
worth the effort to review key project aspects that might need to be adjusted.
Specific details of the data model
Minor changes in scope

Summary
Completed100 pkt.
 2 minutes

The Solution blueprint meeting is often the first meeting where you have enough
information to begin making informed decisions about a project's direction. It is also
a great chance to build rapport with stakeholders. You can use the information that
you learned in this module to help you look ahead to the rest of the project as you
begin to create the solution.

Plan a testing strategy for your

Dynamics 365 solution
 55 min
 Module
 6 Units
Feedback
Advanced
Solution Architect
Functional Consultant
Dynamics 365
Sales
Customer Insights - Journeys
Customer Service
Field Service
Finance
Supply Chain Management
Project Operations
Commerce
Human Resources

Testing strategy, identifying gaps in testing plans, and potential risks are discussed in
this module.

Learning objectives
In this module, you will:
 Identify measurable and non-measurable testing goals and results.
 Plan the entire testing strategy for an engagement.
 Learn how to prepare and conduct the Test strategy review workshop.
Dodaj

Prerequisites
 Extensive functional consultant and developer knowledge
 Previous experience as a solution architect on a prior project is helpful
 Download an example of the template for this workshop from GitHub
location

Introduction
Completed100 pkt.
 8 minutes

The Test strategy review workshop is conducted after the Solution blueprint review so
that enough context is provided about the solution scope, solution design, and
overall project goals to ensure that the workshop can be productive. The Test
strategy workshop does not dictate a specific testing methodology; instead, it is
designed to work with and evaluate a variety of testing approaches. The main
objective of this workshop is to evaluate that the underlying principles of testing are
being addressed.

Timing of the Test strategy review

Testing the solution is essential to the success of the implementation. The project’s
test strategy provides the blueprint for the approach to testing and includes the high-
level plan that will be followed to support the validation of the solution. A good test
strategy drives the approach to the validation of the project solution from the start.
The strategy should promote and enable the project to engineer quality into the
solution rather than only being a check at the end of the project. To understand the
specific requirements for this project’s test strategy, it is essential that you have a
good understanding of the project scope and project risks. Setting the right
validation and quality approach from the start of the project will help avoid missed
opportunities toward keeping the solution on the right track. As such, we recommend
that you conduct the Test strategy review soon after the Solution blueprint review
workshop. Conducting the review early allows you to minimize the impact of issues
that are found and identify risks before they become issues.

The Test strategy review also forms the basis of understanding for the planned test
phases and timing, which will provide you with an overall context in which to provide
guidance on testing. Typical questions that solution architects have regarding the
Test strategy review process and the answers to those questions are as follows:
  Question - A generic test strategy document is provided in our
methodology. Is that enough to review?
 Answer - A good, generic test strategy provides a framework. However,
unless it has been mapped to your specific project (scope, risks, timeline)
and the specific organization (requirements, constraints, and resources),
it is not possible to identify the project-specific risks and issues.
 Question - We are busy with project tasks, especially design and build,
and our test strategy is being worked on. Can we postpone the workshop
until later when we have completed the test strategy and it has been
approved by all parties?
 Answer - Postponing the review will also postpone early identification of
risks. Likely, if the project is already in implement phase, some form of
validation and testing is already being conducted or planned. Reviewing
the draft test strategy document will help ensure that it is completed with
review and recommendations for you to consider.

Overview of the Test strategy review

workshop
Completed100 pkt.
 15 minutes

The goal of Success by Design is to ensure a successful customer outcome while

implementing Microsoft Dynamics 365. The purpose of the Test strategy review is to:

 Drive communication and understanding – The Test strategy review

workshop is designed to drive a conversation about the test strategy that
promotes general understanding across the implementation team
regarding the testing objectives, test types, test coverage and planning,
and approach to validating the solution.
 Identify risks and issues – By taking a broad but high-level look at the
test strategy, you can identify issues and risks with the approach that
would negatively impact the outcome.
 Provide recommendations– Based on the identified risks, this workshop
provides recommendations to help you best manage and mitigate the
risks.

The Test strategy review workshop can be conducted in person for complex projects,
in which case, it is typically run as a single workshop that covers all required topics.
The workshop is most often conducted remotely.
The following sections cover the top-level aspects of the Test strategy review
workshop and provide a sampling of the types of questions that are covered in each
section.

Overall test strategy

Test strategy covers the high-level approach and plan to validate that the solution
will be fit-for-purpose in production use. This topic focuses on answering questions
such as:

 Is a documented test strategy in place?

 Does the test strategy reflect this project’s needs and circumstances?
 Is the test strategy expressed in language that is relatable to the project
and understandable by the relevant project and business stakeholders?

Project scope mapped to test scope

The scope of testing is clearly dependent on the scope of the project. This section
examines how well the project scope is covered by the test scope.

This topic considers this question: How, and as part of which test phase or test type,
are the project functional scope areas due to be tested?

For example, consider the following scope areas:

 Business processes
 Business requirements
 Design requirements
 Data (for functional use, migration, interfaces, reporting/BI, and so on)
 Geography
 Customized areas
 Process changes
 Security
 Regulatory requirements
 Project goals

Another question that this topic considers is: How, and as part of which test phase or
test type, are the project non-functional scope areas due to be tested?

For example, consider the following scope areas:

 Performance
  Usability
 Operability
 Maintainability
 Disaster recovery
 Business continuity
 Other areas, as relevant for this project

High-level test plan

Testing will be conducted throughout the project, and the high-level test plan
provides the structure to show how the various testing types and phases build on
each other to provide incremental and comprehensive validation of the solution. This
topic focuses on answering questions such as:

 How does the high-level test plan integrate within the project plan?
 Does the test planning reflect the test strategy?
 Are all test types and phases reflected accurately in the test plan?
 Does the test plan provide sufficient time and effort to conduct testing in
proportion to the size and complexity of the project?
 Does the test plan show that the time and effort that are allocated to the
various areas of testing are in proportion to the risk that is represented to
the business?

Test phases and types

Testing in a business application like Dynamics 365 is multi-faceted, and the test
phases and types represent the validation of different layers and dimensions of the
solution. This section examines the completeness of some important test definition
and test management attributes of the key test phases and types.

The following tables show a view of the areas that each test type should have
defined.

Testing - Key definitions

Rozwiń tabelę
Test phase / Test Key Source documents Test coverage Entry criteria
type objectives
Enter the title of the Enter key List the document Determine which areas Define the entry
test phase (such as goals that are type/requirement area that is of project scope are criteria that must
Integration Testing or expected to used to define the content of expected to be validated met for this test ph
User Acceptance be achieved test cases and the acceptance by this phase, for to be considered
Testing) or enter the by each test criteria (in other words, what example: - End-to-end ready to start form
Test phase / Test Key Source documents Test coverage Entry criteria
type objectives
key test types (such as phase. is being used as the business process and implementation.
Performance Testing definition against which the related configuration -
or Mock Cutover). test result is validated). Specific functions -
Migrated data

Testing management

Rozwiń tabelę
Test phase / Test Test preparation Test implementation Test reporting Test administratio
type
Enter the title of the Brief description of Brief description of Define how the test Determine the tools
test phase (such as the test preparation how this test will be progress will be be used to store, rev
Integration Testing that is expected to implemented (which reported and how the manage the test fram
or User Acceptance meet the test entry roles will perform the results/quality will be test cases, and test r
Testing) or enter the criteria (for example, tests or what the life analyzed and reported, Also, consider what
key test types (such test script writing, cycle of a defect will such as: - Reporting be used to map test
as Performance data requirements, or be). for internal project use requirement/scope,
Testing or Mock environments). - Reporting to senior Azure DevOps, Kir
Cutover). business stakeholders Microsoft Excel.

Information from the preceding tables applies to all test types. Key test phases and
types that could be covered include:

 Unit testing
 Functional/Process testing
 System integration testing
 End-to-end testing
 User acceptance testing (UAT)
 Regression testing

Key non-functional test types that could be covered include:

 Performance testing
 Data validation
 Security testing

This list is not comprehensive, and depending on the nature of the project, other
types of tests might be relevant, such as point of sale (POS) testing for retail stores or
scanning device testing for warehouse applications.

Additional questions that are especially relevant for a given test type/phase that
might not be adequately covered by the previous categories include:
  Have functional test cases been defined from requirements and/or
business scenarios?
 Does functional testing cover all functional modules?
 Are the functional test scripts validated with business users?
 Does the system integration testing strategy explain creating a
production-like test environment for conducting system integration
testing?
 Has a method been defined to synchronize/resynchronize all
participating systems in system integration testing?
 Have end-to-end test cases been validated with the owner of each
functional module?
 Does the end-to-end testing strategy consider usability testing?
 Have the key stakeholders for UAT been identified?
 Does the UAT plan clearly document the role of each stakeholder in the
UAT phase?
 Have you set up a clear communication plan during UAT to all required
stakeholders?
 Has each main process been decomposed to include sub processes?
 Have the test scenarios been prioritized in UAT?
 Does the UAT test plan include appropriate UAT test environment
provisioning?
 Do you have user training planned before UAT testing for the testers?
 Has an adequate definition been established for the core set of tests that
would constitute a regression test suite?
 Is a process in place to identify recent changes (at a high level) for
regression testing?
 Does the test plan include automating regression testing?
 Has a process been defined for data validation testing?
 Have the correct business stakeholders been identified for conducting
data validation testing?
 Is a plan in place for conducting end-to-end testing on migrated data?
 Does data validation testing include data reconciliation reports and
plans?
 Have key areas for security testing been identified?
 Does the test plan require all necessary security roles and privileges to be
defined and populated before UAT or system integration testing?
 Does the security testing strategy include your organization's security
requirements?

Tooling
Planning, preparation, conduct, and reporting of testing requires significant
management. For the simplest projects, this process might be managed through
spreadsheets, but that could become unwieldy and difficult to track for anything
more complex. Most projects will use some form of task management software. In
addition, many organizations use automation tools to plan, create tests, run tests, and
report the test results. This topic focuses on answering questions such as:

 What test administration tools are being used, and in what manner, to
map testing to source requirements (traceability matrix)?
 What test administration tools are being used to manage the
identification and storage of test cases?
 What test administration tools are being used to manage the allocation
of resources and for tracking the full life cycle of a test from its creation,
running the test, collating the test results, defect logging, and then
resolution and retry?
 What tooling is being used to automate the running of test types and
collecting the results?

Prepare for the workshop

Completed100 pkt.
 10 minutes

Typically, the Test strategy review workshop takes two hours to conduct. The time will
vary based on the level of detail that is available for review and the breadth and
complexity of the solution. The solution architect will work with the implementation
team leadership to plan the workshop based on the specifics of the solution that is
being reviewed and the findings from the Solution blueprint review workshop.

Prior to the Test strategy review workshop, participants should make sure that they're
as familiar as possible with the structure of the workshop, the prerequisites, and the
types of topics that will be covered. The solution architect will provide an agenda with
topics and prerequisites ahead of the workshop.

Essentially, the Test strategy review workshop is a discussion; it’s not intended to be a
questionnaire that can be completed and reviewed in an offline mode. While the
prerequisites are defined and provided in advance, it isn't possible to encapsulate the
breadth of directions in which the conversation might lead.

The solution architect will prepare in advance for the workshop by reviewing existing
project artifacts. Helpful project artifacts include:

 Solution blueprint - Helps provide the context of the project scope and
the high-level design that is expected to achieve that scope.
 High-level project plan - Helps explain the context within which the
different types of testing will be conducted, the dependencies, and the
impact of testing outcomes on the project.
  Test strategy document - Provides a description of the key areas to be
reviewed.
 Test plans - Test plans that are created from the test strategy for specific
test types, for example, a separate test plan might exist for system
integration testing or UAT that provides more specific details on test
cases, resources, and reporting.

It also helps for the relevant members of the implementation team to have examined
recommended practices on test strategy, such as this Test Strategy for finance and
operations Implementations Tech Talk. It also helps discussion focus if the
implementation team sends a list of existing questions/concerns ahead of the
workshop.

The preceding list isn't comprehensive of the documents that help frame the
discussion. For example, it would also help to have the solution architecture diagram
(technical and business process) and the high-level business processes, if these
haven't been already shared and reviewed as part of the Solution blueprint review
workshop.

When you conduct a Test strategy review workshop early in the project, some
documents might not be fully completed or approved internally, which shouldn't be a
barrier to sharing the documents or to conducting the workshop. It’s more important
that project scope has been determined and that a conceptual plan has been
developed for how the solution will be validated.

If your project uses different ways to manage or track project information other than
the provided workshop templates, or if the project uses different documents or
terminology, then sharing the documents that fit the project’s approach and structure
is acceptable. Typically, the format isn’t critical if the information is readily available to
project members. If the previously listed information isn’t documented, or if it's
documented in a way that it isn't easily accessible, you should prioritize ensuring that
the relevant documents are produced.

We recommend that you use diagrams and visual representations to provide high-
level summaries, where possible. These diagrams, charts, and graphs provide a ready
means of communication across the team and with executives about plans and
designs.

Uwaga

The Test strategy review workshop is not intended to be an exhaustive review of all
detailed test cases and all testing that will be conducted as part of the project. The
assumption is that the implementation team will provide a relevant summary and
highlight key concerns and that solution architects will investigate potential problem
areas. The solution architect will suggest further in-depth workshops if additional
assessment is required.

Workshop implementation and follow-

up
Completed100 pkt.
 15 minutes

The following sections explain the steps that are involved in conducting the workshop
and following up afterward.

Test strategy review participants

The test strategy review is an excellent chance to ensure that the project team is
familiar with the overall testing strategy and its implications. Having a broader team
present in the workshop can be a helpful way to provide context to the team. In some
cases, due to the size of the implementation team, it might be necessary to limit
participation in the workshop to only the roles that are outlined in the following list.
With that in mind, make sure that you consider these guidelines:

 The workshop should be attended by representatives from the customer

organization and the partner organization that is assisting with the
implementation. Part of the review’s value is providing collective
information about the strategy and status across all involved parties.
 The workshop should include the project managers, solution architects,
and test managers from the customer and partner organization. If the
customer doesn’t have a specific role in their organization, then the
responsible equivalent stakeholder(s) should be involved.
 The customer and partner project managers, solution architect(s), and
test manager(s) are mandatory. Also, depending on the complexity and
risk to the business of the various areas, consider inviting the following:
integration lead(s), data migration lead(s), business intelligence lead(s),
security lead(s), and any other specialist area lead that can contribute to
the discussion.

Conduct the Test strategy review workshop

The Test strategy review workshop will be facilitated by the solution architect, but the
expectation is that the implementation team will present the test strategy
information. Each section of the agenda should be assigned an owner within the
implementation team. At the beginning of each section, that owner should present an
overview or summary of the strategy, scope, plans, design, and status that apply to
that aspect of the strategy. The team should plan for that summary to take around 25
percent of the allotted time, but not much more. The remainder of the time should
be reserved for questions and answers with the solution architect.

The implementation team leadership should work with the solution architect ahead of
the workshop to shape the agenda and timings for the session. Depending on the
state and complexity of the strategy and readiness of the implementation team, the
review might require more or less time. While the baseline plan is to conduct the
workshop in two hours, that time can be adjusted to a certain extent to
accommodate the complexity and requirements of the project.

Time management in the workshop is important. Top priority for the workshop is to
get through the overall test strategy, which should be prioritized over going too in-
depth in any one area. If the conversation is becoming too extensive and you are
running out of time to cover the breadth of the test strategy, you should expect that
the solution architect will discontinue the detailed conversations for follow-up in a
further in-depth workshop.

Uwaga

During the workshop, you can expect that discussion will happen about the scope,
design, planning, and approach. As part of that expectation, the solution architect
might provide some guidance directly within the meeting. However, these sessions
are not intended to be for the solution architect to design the test strategy, but
rather, to review it. The provided feedback might alter the current plan or design, but
the detailed work in those areas will be carried out by the implementation team after
the workshop.

Test strategy review outputs

The output of the Test strategy review workshop is a findings document. This findings
document is a response to information that the solution architect has been provided,
either as preparation for the workshop or during the workshop. Generally, these
findings will be structured in the same way (assertions, risks, and issues) according to
the Solution blueprint review workshop. For more information, see the Solution
blueprint review workshop.

Subsequent test strategy reviews

In general, the engagement extends to the first go live for any specific
implementation. In most cases, the test strategy review that is performed at the
beginning of the implementation is sufficient for that implementation. Occasionally,
subsequent reviews are required. The following examples explain scenarios where
additional test strategy reviews might be required:

 Challenges with the initial test strategy review – In rare cases, the Test
strategy review workshop is unable to cover all required information. The
reason could be major gaps or conflicts in the understanding of the
scope that need to be worked out by the implementation team, or it
could be a lack of a meaningful test strategy. In these cases, going
through the initial Test strategy review workshop early is valuable
because it highlights these issues so that they can be resolved, but it will
require the workshop to be repeated.
 Significant scope change – Occasionally, an implementation is affected
by major changes in scope or approach. Following a significant change in
scope, it might make sense to reassess the test strategy.
 Organizational changes – Periodically, organizations experience
significant change during the implementation. Events like mergers,
acquisitions, or divestitures can significantly impact the solution
architecture design and might necessitate reevaluation.

Test strategy follow-up

After the Test strategy review workshop has been conducted and the findings have
been reviewed, those items that have been identified as risks and issues, and their
associated action items for mitigation and resolution, will be managed to completion
by the implementation team during the overall engagement.

Answer the following questions to see what you

learned.
1.

What is the purpose of the Test strategy review workshop?

To complete a questionnaire that can be reviewed offline

Incorrect. The Test strategy review workshop is a discussion, not a
questionnaire.
To assess how well the testing principles are applied, and to verify that your program
has a suitable strategy for the customer’s business to run smoothly and securely after
go-live.
Correct. The workshop’s main objective is to assess how well the testing
principles are applied, and to verify that your program has a suitable strategy
for the customer’s business to run smoothly and securely after go-live.
To review all detailed test cases and testing that is conducted as part of the project
2.

The Test strategy review workshop should be attended by representatives from

which organizations?

Only the partner organization

Incorrect. The customer organization should also attend.
Only the customer organization
Both the customer organization and the partner organization that is assisting with the
implementation
Correct. Having a broader team present in the workshop can be a helpful way to
provide context to the team.
3.

What is user acceptance testing used for when implementing a test strategy?

User acceptance testing is critical to ensure go-live sign-off and acceptance of the
new system post-go-live.
User acceptance testing is critical to ensure go-live sign-off and acceptance of
the new system post-go-live.
To make sure users can log on to the new system.
To have a signed contract that users will test the system.
To test if the system accepts existing users into the new system.

Summary
Completed100 pkt.
 1 minute

A test strategy should include functional and non-functional requirements. It should

include user experience, security and access, system performance, and more. A good
test strategy is more than a test plan, but an actual strategy that takes end-to-end
system needs into consideration.

Introduction
Completed100 pkt.
  8 minutes

This module describes the data modeling strategy in Microsoft Dynamics 365 and
Microsoft Dataverse and then explains how the data model workshop will help verify
that a complete data model exists before configuration starts. The following sections
provide you with a basic overview of data modeling best practices and how they
relate to a Dynamics 365 project.

Data modeling overview

A data model is a visual model that shows how data flows through your system and
how different entities relate to each other. Data models define the relationship types
between tables and abstract a database to a straightforward visual representation.

Data modeling has multiple types and standards, including Unified Modeling
Language (UML), IDEF1X, and others. Specific data model standards are beyond the
scope of this module, but data models for Dynamics 365 data structures generally fall
into two general categories: logical and physical.

Logical data models

Logical data models are high-level diagrams that show the way that data flows
through the system. These data models are frequently put together at the beginning
of the project during discovery and before all columns have been defined. Generally,
the logical data model diagram uses the business names of the tables, not the
schema/database name.
Physical data models

Physical data models are lower level than logical data models. They generally include
column-level detail and more precisely designed relationships. The physical data
model is created when the high-level logical design is translated to physical tables. A
common type of physical data model is an entity relationship diagram (ERD).
Data modeling best practices
Data modeling is a science, and data modeling professionals and established
standards exist for data modeling. To be effective with Dynamics 365 data modeling,
you don't have to be a professional data modeler or use special tools. Popular tools
like Microsoft Visio can be used to quickly create a basic ERD that visualizes the
relationships and flow of data between tables. This topic examines some general best
practices for data modeling for Dynamics 365 deployments.

Best practices to follow are:

 Data models should be updated continuously during a deployment.

Typically, a data model is designed at the beginning of a project, but it's
important that updates don't stop at that point. As you go through the
deployment, new columns and tables will be added. Therefore, you need
to capture these new columns and tables in the data model to make it a
living data model. Recommend to customers that they continue to
update the data model as they enhance the system.

 Community tools that are available with the XrmToolBox help make it
easier for you to quickly generate ERDs of your Dynamics 365 and
Dataverse configuration. These tools include the UML Generator and
Entity Relationship Diagram (ERD) Generator. After you complete
configuration updates, generate an up-to-date ERD.

 Don't include every table. Some core tables, such as activities, notes, and
users (record owners), are related to nearly every table in Dynamics 365.
If you include every relationship with these tables in your data model, the
result will be unreadable. A best practice is to only include the primary
tables that are used in the configuration in your data model diagram and
only include custom relationships with the user and activity tables to
maximize readability.

 Data models should include tables outside of Dataverse. If you are

integrating with other systems by using Dataverse data connectors or
virtual tables, or if data flows outside of Dataverse by using an
integration, this data should also be represented in your data model
diagram.

 Start simple with the standard tables, and then add custom table
relationships to your data model.
  User experience should influence your data model. Occasionally, it's easy
to over-normalize your data; however, in the process, you can make the
application more cumbersome to use.

 Start with what you need now but design the data model in a way that
will support what you plan to do in the future. For example, if you know
that you'll eventually need to store more details about sales territories,
using a text field for territory now will make it more difficult to implement
than if you use the territory entity relationship. Plan ahead for what is
coming.

Data model workshop

The data model workshop should be limited to about one hour, and it is often
conducted as part of a Microsoft Teams meeting if everyone isn't together on site.
Attendees should include key stakeholders from the customer and partner teams.
Typically, solution architects, functional leads, and technical leads are mandatory. This
workshop should take place while you still have time and opportunity to make course
corrections if needed.

The next units will describe the recommended topics to be covered when you
conduct the data model workshop.

Entity relationship diagram

Completed100 pkt.

 10 minutes

You can copy and paste the entity relationship diagram (ERD) in the entity
relationship diagram slide of the template. This presentation will provide the solution
architect with an overview of the customizations in the system and will help them
discover the design and implemented functionalities. Based on the information
provided, the solution architect will make a recommendation of identified areas of
risk or potential improvement.

Diagram best practices

Best practices that you should follow when using the entity relationship diagram are:

 Where possible, avoid too many depth levels in a data model to avoid
complex queries.
  Avoid data duplication; every piece of data should only have one
location. Rather than duplicating the same data between multiple tables,
functionality like quick view forms and displaying related table data in
views should be used.

 Use the ERD relationships to review and identify potential cascading

behaviors that could impact business logic. For example, with parental
relationships, permissions like Assign, Share, Unshare, Reparent, Delete,
and Merge will automatically happen to related records when a parent
record is updated.

Out-of-the-box vs. custom tables

Completed100 pkt.

 15 minutes

This unit describes the standard, out-of-the-box tables that are used in the
configuration, along with custom tables and the purpose for which they are being
used. This information matters because Microsoft Dataverse has many common
tables and, as a general rule, a custom table should not be created if a standard table
already exists that addresses that purpose. The reason is because if you overload the
configuration with many redundant tables, you'll negatively impact the performance
of the system, ultimately making the system more difficult to use (many redundant-
sounding tables will confuse users in Advanced Find). Each custom table should
serve a specific purpose. This topic will also help you identify the most-used tables
and if you are at risk of overloading tables.

Determine whether to replace standard tables with custom tables

Occasionally, configurators will consider replacing standard functionality with custom

tables. For example, configurators will often reason that if they need a sales
opportunity but need a simpler form than the standard opportunity form, that a
custom table might be easier. However, you should consider the options that you
might be giving up by using a custom table instead of a standard table. Using an out-
of-the-box table ensures greater alignment with core platform features. Because
additional features are added regularly, standard tables make it easier for you to
benefit from new features when they are released. For example, if you decided to
replace the standard opportunity table with a custom opportunity table, you won't be
able to use Sales Insights and other AI features.

For industry-specific tables, consider using Common Data Model. In addition to the
metadata system, Common Data Model includes a set of standardized, extensible
data schemas that Microsoft and its partners have published. This collection of
predefined schemas includes tables, attributes, semantic metadata, and relationships.
Microsoft is working closely with representatives from various industries to make
Common Data Model more relevant to them by creating industry accelerators.

Industry accelerators are foundational components within Microsoft Power

Platform and Dynamics 365 that enable independent software vendors (ISV) and
other solution providers to quickly build industry vertical solutions. The accelerators
extend Common Data Model to include new tables to support a data schema for
concepts within specific industries. Microsoft is currently focused on delivering
accelerators for the following industries:

 Automotive
 Financial services (including banking and insurance)
 Education (including higher education and K-12)
 Nonprofit
 Manufacturing
 Media
 Communications

Do not re-create accounts and contacts

When deploying Dynamics 365, you will frequently track multiple types of companies,
organizations, and contacts in the system. Some types represent customer/client
organizations, some might be support and advisory organizations, such as
accountants and legal firms, while others might be miscellaneous types of
organizations, such as trade associations.

Consequently, you will need to determine how to manage multiple categories of

company relationships. The most common approach is to use the account table for all
organization types and then use a column like relationship type or custom choice
columns to flag companies by their type or category. Views can be filtered based on
the type of company, and business rules can conditionally show or hide column and
form components based on type.

To benefit from a standard integration with finance and operations apps by using
dual-write, your best option is to use the default tables and columns that are added
by the dual-write core solution to your Dataverse environment.

Another approach is to create custom tables for each type of company. One reason
that is commonly cited is that people might need to use accounts for another reason
in the future, so they don't want to customize the account table.

Before re-creating the account table as a custom company table, you should strongly
consider the options that you are giving up by creating a custom table, such as:
  Multiple addresses - The account table has a unique address capability
that supports multiple addresses. The first two addresses are displayed
on the company form, but these address records live in the related
customer address table. While you can create a custom address table
that is tied to a custom company table, re-creating the unique logic
where the addresses are stored in the related table and are displayed on
the form means that table views would require development. If you need
multiple addresses, use the account table.

 Contact hierarchy - Accounts are the parents of contacts. Activities that

are related to contacts roll up to the parent account record. This
hierarchy can't be replaced by a custom company record. You can create
additional relationships with custom company tables, but the standard
account/contact relationship can't be replaced. If the company has
contacts with their primary company relationships to this type of
company, or if you want to roll up activities from contacts to companies,
use the account table.

 Company tables - The standard map control in model-driven apps

doesn't support custom company tables.

 Hierarchical relationships - Relationships between parent/child

accounts and the standard hierarchy visualization and roll-up of child
account activities to the parent account only work with standard account
tables.

 Customer column - Dynamics 365 includes a special type of

polymorphic lookup column called a customer column. This column
allows a record to be linked to a company/account or a contact.
Dynamics 365 doesn't allow for custom tables to be selected from
polymorphic lookup columns.

 Marketing - Marketing lists can only work with contacts, accounts, and
leads, not custom tables. Microsoft Dynamics 365 Marketing can send to
accounts and contacts, but not custom company tables.

In almost every situation, the account table should be used for company records of all
types, with the following exceptions:

 Minor types of companies that are not relational and have minimal
attributes. Think of a type of organization with no contacts and address
and that only exists for lookup purposes.
  Unqualified or unverified companies that are imported from business
cards or web forms that you don't want to pollute the account table. For
these situations, you could use the lead table.

Determine whether to repurpose system tables

Consider a scenario where you have a business requirement that is similar to

opportunities, but it isn't a sales opportunity. In this scenario, you need to determine
whether to repurpose system tables or create new tables.

The following sections explain situations that you should consider before repurposing
system tables.

Consider the future

The future of Dynamics 365 is moving much faster than ever before, so using tables
in non-standard ways can cause problems if Microsoft changes the table that you are
using. Also, if you choose to repurpose a seldom-used system table, such as
contracts, you risk the chance that Microsoft will elect to deprecate that table in the
future. Custom tables aren't deprecated. Also, if you repurpose a system table, you
might have issues if you later need that table for its intended purposes. Scenarios
have occurred where customers have repurposed a case and, when they needed case
management at later time, had to address it with custom tables because the standard
case table was already used for dramatically different purposes.

Consider the overhead

Numerous system tables have certain columns that can't be removed from the forms.
For example, some columns on tables, such as opportunity, case, and campaign, can't
be removed from the form. While you can hide these columns, having several locked
columns on the form can add overhead to your environment configuration.

Consider the user experience

If your use case is less than 50 percent in line with the standard table functionality, a
custom table will typically give users a simpler user experience than scaling down a
more complex system table. It's also possible to add business process flows to any
table, including custom tables, which can make a custom table user experience as
good as, or better than, repurposing a system table.

Table configuration
Completed100 pkt.

 15 minutes

The table configuration section of the template identifies details about design
decisions that influence the overall quality of the data model and helps to avoid
Common Data Model table configuration mistakes. You should provide answers for
the following questions in the template table configuration slides.

Rozwiń tabelę

Question Why it matters

Have you removed all unnecessary options All unnecessary options (such as notes and connections) should be cle
when creating a new table? creating a new table; otherwise, the options might create unnecessar
relationships that can impact the user experience. These options can b

Are you using out-of-the-box capabilities
instead of creating new columns (for example
“Sending email” or “Activity table” for party list
support, and so on)?
When you need columns such as Attendees, To, From, and Scheduled
table should be used. Custom activity tables contain many default acti
From, and so on) that can be useful in specific scenarios. If you need t
table record, enable it for emails so that an email address column is au
columns.

Do you use N:N relationships? Many-to-many (N:N) relationships are lightweight but limited in their
association between two records can be difficult to import.

Instead of N:N relationships, have you
considered bridge custom tables?
Instead of standard N:N relationships, an alternative is a bridge table,
table or a manual many-to-many relationship. Rather than using a sta
you can create a bridge table between the two related tables with a lo
references each side of the relationship. This approach enables the cre
the relationship that describe the relationship. Keep in mind that the u
complicated than a normal N:N relationship.

Do you take advantage of column mappings in When creating a relationship, you can specify column mappings to au
your table relationships? columns on the related table. This approach is useful in cases where y
values between parent and child records (such as automatically popul
contact when it's created from a parent account). However, this appro
create duplicate data for critical columns, and alternatives like quick v
considered for displaying read-only attributes from a parent on the re
record.

Do you use a single publisher for your
customization and a custom prefix?
Avoid having multiple publishers with the same technical name but w
the publisher of your project on a single environment and then deploy
environments with an unmanaged solution. If customizations come fro
with the same solution publisher (name and system name) then comp
columns, must also be truly unique (same GUID) to avoid deployment
schema name is used on the same column that was created separatel
solution import will fail when you import the column into the environ
Choice columns, custom tables, and localization

Choice columns are drop-down list columns that help standardize data capture in
Dynamics 365 and make searching for records much more convenient. If everything
used text columns, then you would eventually have dramatically different spelling and
abbreviations of the same values in multiple records, making reporting and usability
difficult. However, proper forethought is necessary to ensure that you are using
choice columns in an optimal manner. You should answer the following questions in
the choice columns, custom tables, and localization section of the template
document.

Rozwiń tabelę

Question Why it matters

Are you using custom tables to
replace choice columns?
When defining a list of options from which a user can select, you have two options
define a custom table to hold a list of records and replace the choice columns with
selecting between choice columns and lookup columns, consider the following fact
support translation for many different languages, allowing users to see values in th
(multi-select choice columns) can display multiple values in a single column or in a
columns can be deactivated, leaving the value on older records for historical purpo
can only be deleted. Custom table records that are used for lookup column options
and deleted by non-administrators. Choice column values need to be added or cha
and included in the application lifecycle management (ALM) practices in use. Choic
move with solutions, custom table records that are used in lookup columns must b
in each environment individually, or data migration processes must be established
in sync between environments. Custom tables are better suited for large option qu
provide more searchability than choice columns.

Do you use whole number
attributes of format language to
filter records based on the user’s
language?
Creating a whole number column with the language format option displays a list of
provisioned for your organization. Using a language whole number column allows y
on the current user’s language. The values are displayed as a drop-down list of lang
is stored as a number that uses LCID codes. Language codes are four-digit or five-di
ID values can be found on the Microsoft Locale ID Values page.

Security, relationships, and performance

Security is covered in greater detail in the Review the security model for your
Dynamics 365 solutions module. For the purposes of this module, you will evaluate
the impact of data model design on the security model. You should provide answers
to the following questions in the Security, Relationships, and Performance section
of the data model workshop template.

Rozwiń tabelę
Question Why it matters

Have you considered using
user/team owned vs.
organization-owned tables?
Generally, reference data does not require ownership if visibility for the record doesn'
specific users or groups. When in doubt, your best choice is to create the table with a
because you can always grant users organization-level access to these records. Choosi
the Organization ownership can't be changed, and as your company grows, you might
some records later. For this reason, the User or Team option should be selected becau
flexibility for future business changes.

Have you reviewed Relationship behaviors that impact security are: Assign (cascading – from parent to ch
relationships within your data from parent to children), Unshare (cascading – from parent to children), and Reparent
model and their impact on when child record is associated with parent, which is important for implicit sharing).
security?

Do you use field-level security? Field-level security is a good option for securing data in specific fields. However, overu
impact performance and add complexity to administration.

Have you considered moving Field-level security operates at a global level and is not sensitive to the User / Busines
sensitive data to a separate these columns are shared on a per-record basis), while using a custom-related table fo
table? additional flexibility to have different permission levels for sensitive data between bus

Do you track or have naming Columns that contain personal information must receive an extra level of attention to
conventions for sensitive data security regulations. One approach to managing personal information columns is
personal information columns? conventions for personal information columns, such as prepending “person” or “confi
schema name for personal information columns.

Columns - Alternate keys, calculated, and rollup

In this section, you can capture details about miscellaneous column types by
answering the following questions.

Rozwiń tabelę

Question Why it matters

Are you using alternate keys?
Alternate keys allow the administrator to define composite keys, inc
from the table. Alternate keys enforce record uniqueness. Key value
increases search speed, and they make data import more efficient b
match for update based on the alternate key value. Be careful when
system that might break record creation logic that doesn't provide u
keys can be valuable for integration scenarios when you want to ben
capabilities: By providing the key, the system knows if it could create
existing one.

Are you using calculated columns? Excessive JavaScript, business rules, and plug-ins can degrade system
columns can calculate real time when data is viewed and can be mo
is only updated on retrieval, make sure that you don’t need real-tim
source values change.
Question Why it matters

Are you using rollup columns?
When rolling up values from child records to parent, many custome
ins. This approach has an added overhead on performance when ov
rollup columns, you can avoid unnecessary plug-ins, simplify future
system performance. Keep in mind that rollup columns only calculat
default, so if you have rapidly changing data, standard rollup column
to-date information, so plug-ins should be used. However, by using
changing data, you will improve performance.

Have you verified that the min/max length or If the customer will be migrating or integrating Dynamics 365 data w
values of each of your columns was consistent need to verify that configured column lengths are consistent with d
with business requirements and with any data other systems.
integration or data mapping?

Have you considered using date only or time
zone-independent date columns?
Default date column behavior is User Local. This option displays dat
zone of the user who is viewing the record. This option is beneficial
specific time matters but it can cause issues for other types of dates
user local format. If the birthday is January 5 12:00 AM, a user in a ti
the record creator will see the date as the previous day at 11:00 PM
only the date value, and time zone-independent format stores the ti
correct date value.

Auditing

Auditing is important for security traceability as well as troubleshooting issues with

data. In the auditing section of the Data Model Workshop template, capture the
following details about auditing settings in the customer's environment:

Rozwiń tabelę

Question Why it matters

Have you configured auditing? Many customers who assume that they have configured auditing don't truly have a com
Auditing is not enabled for tables by default. We recommend that you only enable audi
that you want to track. When tables are added, it might be easy to forget to turn on aud
data is deleted later, the administrator discovers that no audit logs exist, so it will be im
deleted the data.

Do you periodically delete Audit log data builds up to large volumes over time and should be periodically deleted t
audit logs? storage.

Do you have a process in Audit log data builds up to large volumes over time and should be periodically deleted t
place to periodically clean log storage.
data?

Do you have a process in Transactional data that is imported over many months can grow to large quantities, imp
place to periodically archive performance and increasing storage capacity costs. Data retention policies should be es
transactional data? actionable transactional data, and data outside of the retention period should be archiv
Question Why it matters

system. System bulk deletion jobs can be used to automatically delete records on a sche

External data display or integration

Many Dynamics 365 deployments include integrations with other systems, which
extends the data model outside the walls of Dataverse. Many data migrations can be
replaced with more flexible options, which will reduce the size of the database and
improve system performance. Answer the following questions in this section of the
data model workshop template.

Rozwiń tabelę

Question Why it matters

Do you copy external data in Dynamics
365 tables?
Data integration brings data into Dataverse and provides Dynamics 365 user
system data. However, physical data integrations can have issues: Large data
integrations significantly increase the size and storage capacity cost for the s
migrations are time-consuming and can delay the deployment of the applica
migrations and integrations create duplicate copies of sensitive system data
compliance officers might disapprove of. Large and frequently running data
degrade system performance.

Have you considered using canvas apps Canvas apps from Power Apps can be embedded in Dynamics 365 model-dr
from Microsoft Power Apps to display 300 standard connectors and providing convenient wizards to simplify comm
external data? apps can also create records in other systems by using connectors, so they c
between applications without the need to physically copy data.

Have you considered using Power Apps Power Apps component framework controls allow administrators to replace
component framework to display custom controls and display external data.
external data?

Have you considered embedding By embedding Power BI tiles into your Dynamics 365 model-driven app form
Microsoft Power BI tiles to display ability to display data that is stored in other systems and filter it to be conte
external data? eliminating the need to copy data to Dynamics 365.

Do you use virtual tables? Virtual tables don't contain data; they connect to an external data source w
users as if it were in Dataverse. This data is available for views, subgrids, and
Currently, virtual tables only support reading data, and all virtual table data
users. If granular security is required, you should consider alternative option

Have you considered using Export to The Export to Data Lake service is a pipeline to continuously export data fro
Azure Data Lake or Data Export Services if Azure Data Lake Storage Gen2. The Export to Data Lake service is designed f
you need Dynamics data for external BI analytics by delivering scalable high availability with disaster recovery capab
purposes? Common Data Model format, which provides semantic consistency across a
Dynamics Export Service synchronizes Dynamics 365 data with an Azure SQL
for reporting on large datasets from Dynamics because limits are placed on
that can be reported by using direct query from Power BI when connecting
Question Why it matters

Reporting from an external database is also preferable from a performance

User experience

While the primary point of the data model is to understand how tables relate and
how data flows through the system, the data model needs to be influenced by good
user experience to achieve maximum user adoption of the system. The way data is
modeled in Dynamics 365 can deeply impact user experience and how hard or easy
the application is for users. Take the time to "clean" column and table data so that
users are not confused with the data to use. Answer the following questions in the
User Experience section of the Data Model Workshop.

Rozwiń tabelę

Question Why it matters

Have you excluded unused columns and Setting columns to be non-searchable will exclude these columns and r
relationships from search? the Advanced Find filter designer and help make finding information ea
quick search “Find” columns to only the most important columns will h
faster.

Have you prefixed unused columns (for Making columns non-searchable does not exclude them from view layo
example “ZZ column“) to make sure that they to simplify building views is to prefix the column display names with “Z
appear at the end of list? notation so that they fall last alphabetically and are unlikely to overwhe

Have you adopted a consistent naming When designing a data model, you should create consistent naming co
convention for metadata to simplify UX? consistent and understandable labels. This notion also applies to the co
are displayed for developers or users who are accessing data through A
Power BI).

Have you adopted a consistent procedure for When multiple teams or project streams work on a single implementati
managing metadata (such as adding new important that governance is in place to manage metadata to have a co
columns) to avoid conflicts and duplicates? avoid potential column duplicates.

At the end of the workshop, the solution architect should explain the next steps and
the actions that the customer and partner need to take. Explain that findings and
recommendations will be sent, and a follow-up meeting will be scheduled with the
customer to review status of follow-up items if needed.

Check your knowledge

Completed200 pkt.
 6 minutes
Answer the following questions to see what you've
learned.
1.

Which two general categories do data models for Microsoft Power Platform and
Dynamics 365 data structures typically fall into?

Logical data models and Physical data models

Data models for Microsoft Power Platform and Dynamics 365 data structures
typically fall into two general categories, Logical data models and Physical data
models.
Mental data models and Physical data models
Global data models and National data models
Managerial data models and User Experience data models
2.

Because account and contact system tables are easily re-created, is it a good
idea to re-create them across several custom tables to get exactly the system
that you need?

Yes, you should always re-create custom tables whenever possible.

In almost every situation, account and contact tables should never be re-
created.
Yes, re-creating custom tables causes no issues.
No, in almost every situation, accounts and contacts should not be re-created.
In almost every situation, account and contact tables should never be re-
created.
No, custom tables don't provide value.
3.

Which of the following questions is not a consideration when you are capturing
details about auditing settings in a customer’s environment?

Do you periodically delete audit logs?

Audit log template color and design won't be a consideration for audit settings.
Have you configured auditing?
Will the audit log template match the logo and color scheme of company marketing
materials?
Audit log template color and design won't be a consideration for audit settings.
Do you have a process in place to periodically archive transactional data?

Introduction
Completed100 pkt.
 5 minutes

The Business intelligence and analytics design workshop allows you to spend time
reviewing the overall business intelligence and analytics planning, fit-gap analysis,
design blueprint to provide guidance on maximizing the use of standard features,
alignment to product roadmap, and general design guidance. This workshop isn't
intended as a fit-gap review. The expectation is that fit-gap analysis and initial
consideration of solutions for every scenario will be completed prior to the workshop.

Uwaga

Not every project will need the Business intelligence and analytics design review
workshop.

The goal of the Business intelligence and analytics design workshop is to ensure that
the Business intelligence and analytics solution design is well understood, planned,
and that appropriate solution strategies and technologies are used. You can complete
the design by collecting insights on the implementation activities, reviewing the
current planned solution design, and raising recommendations, risks, and issues that
are related to the plan and solution strategies.

The purpose of the Business intelligence and analytics design workshop is as follows:

 Drive communication and understanding - The business intelligence

and analytics design workshop is intended to drive a conversation about
the business intelligence and reporting requirements of the project that
promotes general understanding across the implementation team
regarding the reporting goals, scope, architecture, and approach to
implementing the reporting solution.
 Identification of risks and issues - By taking a broad but high-level look
at the business intelligence solution and strategy, you can identify issues
and risks with the solution design or implementation approach that will
negatively impact the outcome.

Timing of the Business intelligence and analytics

design workshop
The Business intelligence and analytics design workshop provides a foundation for
the reporting solution and the approach to implementing it. Without having that
foundation in place, subsequent business intelligence activities are at risk of not fully
supporting the goals and ultimate success of the solution. As such, we recommend
that you conduct the Business intelligence and analytics design workshop as close to
the beginning of the design phase because you have already collected the
requirements and started planning solution strategies. Conducting the review early
allows you to minimize the impact of issues that are found and identify risks before
they become issues.

Business intelligence and analytics

design workshop overview
Completed100 pkt.
 8 minutes

The Business intelligence and analytics review is a workshop that can be conducted in
person or remotely. The following sections cover the two top-level topics for the
Business intelligence and analytics design workshop and provide a sampling of the
types of questions that are covered in each section.

 Business intelligence and Reporting - Planning

 Business intelligence and Reporting - Solution Strategy

Business intelligence and Reporting - Planning

The Business intelligence and Reporting - Planning topic is divided into the following
areas:

 Design blueprint
 Work stream information
 Project plan
 Reporting fit-gap analysis

Each of the preceding areas will have questions that are related to these aspects of
the reporting solution, including:

 What is the company data and business intelligence strategy?

 What is your Reporting and business intelligence current state solution
and planned future roadmap?
 How do you plan to bring historical and current system data (the system
that Microsoft Dynamics 365 business apps are replacing) into the
enterprise business intelligence platform for analytics?
  How is the reporting and business intelligence workstream structured
with respect to the overall implementation project team?
 Is your reporting, business intelligence, and analytics tasks defined within
the overall implementation project plan?
 Do all requirements include business process categorization and
information about how the reports are used?
 Does the fit-gap analysis capture business processes and feature areas
where the gaps exist?

Business intelligence and Reporting - Solution

Strategy
The Business intelligence and Reporting - Solution Strategy topic is divided into the
following areas:

 Self-service reporting
 Operational reporting
 Data security
 Strategic reporting
 Regulatory and finance reporting
 Printing strategy

Each of the preceding areas will have questions to help you review these aspects of
the reporting, including:

 Have you identified operational impromptu report gaps and solution

strategy?
 What is your solution strategy to solve for operational reporting needs
that require data mashup from other data sources?
 Have you identified and documented required analytical dashboards,
KPIs, and report requirements for the project?
 Is a data management strategy in place that includes security
requirements (encryption, access controls, row level, and column level)
and requirements for data residency, private data, and data retention?
 What is the solution strategy for financial reporting, such as balance
sheet, profit, and loss, and so on? (finance and operations apps)
 Do you have requirements to generate regulatory, tax reporting, and
payment documents to serve the local government or banking
institutions? (finance and operations apps)
 Do you have high volumes of labels that need to be printed for
warehouse and production operations such as picking, receiving, and
finished goods put away? (finance and operations apps)
  What is your solution strategy to print high-volume label printing?
(finance and operations apps)

Prepare for the Business intelligence

and analytics design workshop
Completed100 pkt.
 8 minutes

Typically, the Business intelligence and analytics design workshop takes

approximately two hours to conduct. The time might vary based on the level of detail
that is available for review and the breadth of the overall solution. The solution
architect will work with the implementation team leadership to plan the workshop
based on the specifics of the solution that are being reviewed.

Ideally, on arrival to the Business intelligence and analytics design workshop,

workshop participants should be as familiar as possible with the structure of the
workshop and the types of topics and prerequisites that will be covered. The solution
architect will provide an agenda with topics and prerequisites ahead of the workshop.

Additionally, the solution architect will prepare in advance for the workshop by
reviewing existing project artifacts. Helpful project artifacts for this workshop include:

Reporting Requirements and Fit Gaps - List of the reporting requirements,

categories, priority, fit-gap analysis, and solution strategies.

Business intelligence Design Blueprint - In a business intelligence and analytics

solution that includes multiple Dynamics 365 apps, legacy, or services and
components from other sources, it is helpful to be able to identify business
intelligence and analytics data, data transformation, data warehouse, and reporting
solutions.

Business intelligence and analytics design workshop

participants
Guidelines to consider regarding Business intelligence and analytics design workshop
participants:

 The workshop should be attended by representatives from the customer

organization and the partner organization that is assisting with the
implementation. Part of the review value is providing a common
understanding of the reporting solution.
  The workshop should include the project manager and business
intelligence and reporting team members/architects from the customer
and the partner organization. If the customer doesn't have these roles in
their organization, then the responsible technical stakeholder(s) should
be involved. If the partner organization doesn't have a designated
solution architect who is responsible for the business intelligence and
reporting implementation, then the equivalent delivery lead, functional
architect, or technical architect should be involved.

Conduct the Business intelligence and

analytics design workshop
Completed100 pkt.
 5 minutes

The Business intelligence and analytics design workshop will be facilitated by the
solution architect, but the expectation is that the implementation team will present
the information. An owner within the implementation team should be assigned for
this workshop. At the beginning of the session, that owner should present an
overview of the scope and plans, including designs that apply to that aspect of the
solution. The team should plan for that summary to take between 25-50 percent of
the allotted time, but no more. The remainder of the time should be reserved for
questions and answers with the solution architect.

Porada

The implementation team leadership should work with the solution architect ahead of
the workshop to shape the agenda and timings for the session.

Business intelligence and analytics design outputs

The output of the Business intelligence and analytics design workshop is a findings
document. This document is a response to information that has been provided as
preparation for this workshop or during the workshop. These findings will generally
be one of three types:

 Assertions - These findings relate to specific aspects of the solution that

the solution architect wants to call out as architecturally significant. These
assertions might not represent a specific risk or issue but might be
foundational to the solution; therefore, they should be noted because, if
they change, they will have significant impact. These assertions might
 relate to specific scope items, design aspects of the solution architecture,
or implementation approach or technique.
 Risks - These findings represent an aspect of the solution or
implementation approach that constitutes a risk that should be tracked
on the project. These risks could relate to existing plans, approaches, or
designs that have an observed potential for negative outcomes. They
could also be related to areas of the solution that simply have not been
adequately explored yet, and as such, represent a risk that something
unexpected could come up. These findings will be accompanied by a
statement of what is viewed as a risk along with recommended
mitigation steps.
 Issues - These findings represent an aspect of the solution or
implementation approach that constitute an issue that is negatively
impacting the implementation or, if not corrected, will have a negative
impact. These findings will be accompanied by a statement of what the
impact is or will be, along with recommended resolution steps.

The findings document will be distributed to all stakeholders, and a meeting will be
held to review the findings in detail. The document will go to the implementation
leadership and executive sponsors in both organizations. Occasionally, these finding
documents can be lengthy, in which case, an executive summary that highlights key
and critical findings is provided for better consumption by executives

Business intelligence and analytics

design follow-up
Completed100 pkt.
 3 minutes

When the Business intelligence and analytics design workshop has been conducted
and the findings have been reviewed, those items that have been identified as risks
and issues, and their associated action items for mitigation and resolution, will be
managed to completion as part of the overall engagement.

Identified issues will often have an impact on the ability to successfully go live. These
issues will need to be resolved prior to the go-live readiness assessment and the
deployment of a production environment.

Risks and their associated recommended mitigations can be managed according to

the overall strategy of the project, but they'll be monitored throughout the project.
Risks that aren't mitigated might be realized later as issues that could also affect the
go live.
Answer the following questions to see what you've
learned.
1.

Which of the following options is not part of the solution strategy for business
intelligence and analytics?

Data security
This option is part of the solution strategy for business intelligence and
analytics.
Strategic reporting
Printing strategy
Success by Design planning review
This option is not part of the solution strategy for business intelligence and
analytics.
2.

Who should facilitate the Business intelligence and analytics design workshop?

Solution architect
The solution architect will facilitate the workshop.
Customer’s CIO
Functional consultant
Project manager
3.

In which phase of Success by Design should the Business intelligence and design
workshop be conducted?

Design
The Business intelligence and analytics design workshop should be conducted as
close to the beginning of the design phase because you have already collected
the requirements and started planning solution strategies.
Build
Initiate
Deploy

Introduction
Completed100 pkt.
 3 minutes
The purpose of this module is to spend time reviewing the top gap solutions for
high-impact, high-risk extensions to provide:

 guidance on maximizing the use of standard features

 alignment to the product roadmap
 general design guidance

This workshop isn't intended as a fit-gap analysis. The expectation is that the initial
approach to a solution for every scenario is completed before the workshop.

The workshop is designed to ensure the gap solution design provides a good
approach and plan to deliver a well-defined, well-tested, reliable, and safer solution.
You can prepare for the workshop by:

 collecting insights on the implementation activities

 reviewing the current gap solution blueprint
 raising recommendations, risks, and issues that are related to the planned
customizations.

Gap solution design workshop overview

Completed100 pkt.
 5 minutes

The following sections cover the top-level aspects of the gap solution design and
provide a sampling of the types of questions that are covered in each section.

Top gaps
The Top gaps section is intended to provide an overview for the primary critical gaps
that the team has identified and get an understanding of the proposed solutions to
fill those gaps, including the related business processes that those solutions will be
supporting.

Reviewing the high-level details on each proposed solution and potential

complexities that are involved will help provide the necessary context for having in-
depth discussions about each gap solution in the later stages of the workshop.

This stage asks for you to provide the following information:

 Short description of the gap

 Business processes that the gap solution will support
  Where the gap exists and whether it's a standard gap in the platform or a
gap in the ISV solution
 Solution type (custom extension, independent software vendor (ISV), and
so on)
 Description of the proposed solution to fill that gap
 Indication of whether a proof of concept of the proposed solution has
been completed or not
 The level of effort for the proposed solution
 Type of business impact that needs to be considered for this gap
 The level of risk that is associated with the proposed solution

Review of each gap and solution

The next section of workshop explains each gap that was highlighted in the top gaps
section. Having comprehensive discussions on each gap will provide you with an
opportunity to gain clarity about business requirements and the proposed solution.
This review will also help you determine if you're taking the correct approach or if
alternative approaches are available that might have less risk or align better with the
product roadmap.

This unit focuses on answering questions such as:

 What are the business requirements that need to be met with the gap
solution?
 What's the business process or processes that the solution will support?
 What's the approach to fill this gap? What are the solution details?
 Do certain risks need to be considered with this approach?
 Do dependencies exist on other solution components?
 Do performance impacts need to be considered?
 Do storage impacts need to be considered?
 Does the solution add complexity to the business process?
 What other solutions have been considered, if any?

You'll go through these questions for each gap that the team has identified for
review. This process will help ease the conversations that are necessary to assess each
gap solution and determine the best approach.

Prepare for the Gap solution design

workshop
Completed100 pkt.
  10 minutes

Typically, the Gap solution design workshop takes approximately one to three hours
to conduct. The time might vary based on the level of detail that is available for
review. The solution architect will work with the implementation team leadership to
plan the workshop based on the specifics of the solutions that are being reviewed.

Before the Gap solution design workshop, participants should be as familiar as

possible with the structure of the workshop and the types of topics and prerequisites
that will be covered. The solution architect will provide an agenda with topics and
prerequisites ahead of the workshop.

Essentially, the Gap solution design workshop is a discussion. It's not intended to be a
questionnaire that can be completed and reviewed in an offline mode. While the
prerequisites are defined and provided in advance, it's not possible to encapsulate
the breadth of directions in which the conversation might lead.

The solution architect will prepare in advance for the workshop by reviewing existing
project artifacts ahead of time. Helpful project artifacts include:

 Gap solution documents - Documentation that includes details on

proposed solutions that have been identified to fill existing gaps.
 Fit-gap analysis documents - Documentation providing details on the
functional areas in the business process that have been identified as not
supported by the standard system. For more information, see Perform fit
gap analysis.
 Functional design documents - Documentation that describes the
planned features that are included in customizations. For more
information, see Create functional design documents (FDD).
 Technical design documents - Documentation that describes in detail
the design of the planned solutions.
 Business process diagrams - Business process diagrams that can add
context to the process catalog and describe the operation of the
business.
 Integration diagrams - Documentation providing an overview of the
integrated system requirements for deploying the solution.

This list isn't exhaustive of project deliverables, but it's a good starting point for the
gap solution design. The formats, composition, and names of each deliverable might
vary from one project to the next. Format isn't the most important concept; it's the
information that is available and agreed upon across the team that is essential.

It's acceptable if your project uses different ways to manage or track project
information other than what is previously listed. Typically, the format isn't critical if
the information is readily available to project members. If the information from the
preceding list isn't documented on your project, or if it's documented in a way that
isn't easily accessible, you should prioritize getting the relevant artifacts produced.

Porada

We recommend that you use diagrams and visual representations to provide high-
level summaries, where possible, in the implementation. These diagrams, charts, and
graphs provide a ready means of communication across the team and with executives
about plans and designs.

Gap solution design review participants

We recommend the following audience participation for the Gap solution design
review:

 Functional and technical architects

 Functional, technical, and development leads
 Project managers (optional)

Conduct the Gap solution design

workshop
Completed100 pkt.
 10 minutes

The solution architect facilitates the Gap solution design workshop, but the
expectation is that the implementation team presents the gap solution information.
Each gap solution should be assigned to an owner within the implementation team.
At the beginning of the workshop, someone from the implementation team should
present the overview or summary of the top gaps, including the solutions that have
been proposed for each gap. This overview shouldn't take more than 10-15 percent
of the overall time for the workshop. It should only be presented at a high level
because each gap solution will be discussed in detail in the later topic areas.

Following the overview of the top gaps, the implementation team should present
each solution gap separately and allow time for discussion among the group. After
participants have discussed all gap solutions, the rest of time should be reserved for
questions and answers with the architect.
An expectation should be set that, during each session, discussion about the scope
and approach will occur. As part of that expectation, the solution architect might
provide some guidance directly within the meeting. However, these sessions aren't
intended to be design sessions but rather review sessions.

The provided feedback might alter the current plan or design, but the
implementation team will carry out the detailed work in those areas after the
workshop.

Gap solution design outputs

The output of the Gap solution design workshop is a findings document. This findings
document is a response to information that has been provided as preparation for the
workshop or during the workshop. Generally, these findings will be one of three
types:

 Assertions - These findings relate to specific aspects of the solution that

the solution architect wants to call out as architecturally significant. These
assertions are factors that might not represent a specific risk or issue but
are foundational to the solution and should be noted because, if
changed, they'll have significant impact. These assertions might relate to
specific scope items, design aspects of the solution architecture, or
implementation approach or technique.
 Risks - These findings represent an aspect of the solution or
implementation approach that is a risk that should be tracked on the
project. These findings could relate to existing plans, approaches, or
designs that have an observed potential for negative outcomes. They
could also be related to areas of the solution that haven't been
adequately explored yet, and as such, represent a risk that something
unexpected could come up. These findings will be accompanied by a
statement of what is viewed as a risk along with recommended
mitigation steps.
 Issues - These findings represent an aspect of the solution or
implementation approach that is an issue that negatively impacts the
implementation, or if not corrected, will have a negative impact in the
future. These findings are accompanied by a statement of what the
impact is or will be, along with recommended resolution steps.

The findings document will be distributed to the customer and partner organizations,
and a review meeting will be held to assess the findings in detail. The document will
go to the implementation leadership and executive sponsors in both organizations.
Occasionally, these finding documents can be lengthy, in which case, an executive
summary that highlights key and critical findings is provided for better consumption
by executives.

Gap solution design follow-up

Completed100 pkt.
 2 minutes

After you conduct the Gap solution design workshop and review the findings, identify
items as risks and issues, and their associated action items for mitigation and
resolution, manage them to completion as part of the overall engagement.

Issues that are identified often affect the ability to successfully go live. Resolve these
issues before the go-live readiness assessment and the deployment of a production
environment.

You can manage risks and their associated recommended mitigation according to the
overall strategy of the project. But they'll be monitored throughout the project. Risks
that aren't mitigated might be realized later as issues that could also affect the go
live.

Answer the following questions to see what you've

learned.
1.

What is the purpose of the Gap solution workshop?

The purpose is to design solutions to fill the identified gaps in the current plan.
The solutions should have already been designed before the workshop.
The purpose is to review the top gap solutions for high-impact, high-risk extensions
to provide guidance.
The workshop is designed to allow time to review plans that have already been
made.
The purpose is to identify gaps in the solution.
The purpose is a detailed planning of the architecture of the proposed gap solutions.
2.

Which of the following options isn't considered a typical participant in the Gap
solution workshop?
Technical architect
The technical architect is an important participant in the workshop.
Development lead
Solution architect
Business decision-maker
The business decision-maker isn't typically part of the Gap solution workshop.
3.

While you're evaluating the proposed solutions to fill gaps, which of the
following factors should you consider?

Risks that are associated with the proposed solution

All these factors, and more, are important considerations for the Gap solution
workshop.
The expected impact of the proposed solution
Whether a prototype or proof of concept has been completed or not
All of these factors
All these factors, and more, are important considerations for the Gap solution
workshop.

Introduction
Completed100 pkt.
 2 minutes

Data migration is a key step in a successful implementation. The Data migration

strategy workshop includes general strategic considerations and specific topics like
volumes, tooling, performance, and validations.

This module explains the data migration strategy in Dynamics 365 and Microsoft
Dataverse. Additionally, it describes how this workshop will help validate a data
migration strategy.

The Data migration strategy workshop can help to ensure a successful migration to
Dynamics 365. You will start with a basic review of data migration and will then learn
about best practices and how data migration relates to a project.

Data migration strategy overview

Completed100 pkt.
 15 minutes
Typically, the Data migration strategy workshop is conducted remotely and includes
several important areas of discussion. The following sections list some important
areas, but these lists aren't exhaustive. Each project will have slightly different
considerations.

Data management strategy

In the Data management strategy section of the workshop, you will review the data
management strategy and identify roles and their responsibilities. Then, you will
define how data will be prepared and validated later and which tools to use. Basically,
this part of the workshop is an initial conversation to help gain understanding of the
whole strategy around data migration.

Planning and strategy

The Planning and strategy section covers project timelines, who owns the data, and
who will be responsible for all tasks around it (extraction, provision, cleansing, and
importing). It’s important to review the type of data to bring into the solution and
determine whether all that data is needed. Environments and tools are necessary in
this conversation. Make sure that you know how many environments, and which
ones, are included in the strategy and the tools in use.

This topic focuses on answering questions, such as:

 Will user acceptance testing (UAT) be performed on migrated data?

 How many data migration cycles or dry runs will be conducted?
 Have data structures and relationships of your destination solution been
defined?
  What are the types of environments in which data migration activities will
take place?

Data volume
In the Data volume section, you should validate that the volume of data that is being
migrated has been assessed. For a successful data migration, it is crucial to have a
clear picture of the number of records that are being migrated from legacy systems
into the new environment. In scenarios where you are migrating high volumes of
data, knowing in advance the number of records that are involved, and
understanding how the tool works, will save you time.

This topic focuses on answering questions, such as:

 Which tables have the largest number of records?

 How will large volumes of data be synchronized initially for dual-write
integration?

Tooling
The Tooling section is about the tools in use and about understanding the plan for
using them. Different approaches and different stages are available to use, such as
copying/synchronizing data between legal entities and copying data between
environments. Make sure that you discuss how data will be extracted, transformed,
and loaded back into the system.

This topic focuses on answering questions, such as:

 Which tools will be used to move/copy/synchronize data between legal

entities?
 Does everyone have a good understanding of the tools to be used
during data migration?
 What will be the tool that is used for the data migration?

Performance
The Performance part of the data migration process is related to a better quality of
data, faster cycles, and eventual, achievable cutover timing. As such, it is important to
determine the best setup, technical and functional, for performance improvement
and to conduct multiple rounds of tests to validate that setup.
This topic focuses on answering questions, such as:

 What are the characteristics of the environment that is planned for data
migration?
 Does the data migration plan include non-functional requirements?
 Has performance-related setup been considered and planned?

Data validation
Data validation is a mandatory step to ensure that migrated data is complete and
aligned to the business requirements. The data validation must be well documented,
with all necessary criteria defined.

This topic focuses on answering questions, such as: What is the plan to validate the
data after migration (data quality, data formatting, and so on)?

Testing
Testing the migrated data is essential to the entire data migration process. The aim is
to ensure that the testing is thoroughly documented, that unit tests exist, and that
the results are accounted for and transferred to the next data migration cycles.

This topic focuses on answering questions, such as:

 Have unit tests been defined for testing migrated data?

 How will the test results be documented?
 Is error handling planned and accounted for?

Prepare for the Data migration

workshop
Completed100 pkt.
 10 minutes

The Data migration strategy workshop typically takes approximately 1-3 hours to
conduct. The time might vary based on the complexity of the project, the scope of
the migration, and the challenges that are encountered throughout the
implementation.
Prior to the Data migration strategy workshop, participants should be as familiar as
possible with the structure of the workshop and the types of topics and prerequisites
that will be covered.

The primary prerequisite is to prepare the Data migration strategy workshop

template that captures information about the sections that are presented (such as the
data management strategy, data volume, tooling, and so on). The implementation
team will need to complete and share the template with the solution architect at least
two working days before the workshop.

Uwaga

Essentially, the Data migration strategy workshop is a discussion. It is not intended to

be a questionnaire that can be completed and reviewed in an offline mode.

Having the following project artifacts ready would enrich the exchanges during the
workshop:

 Project charter – Document providing the background of the project,

especially the objectives and expected key results.
 Rollout plan/schedule with the current and next phases – Document
or Gantt charts depicting the current and the next phases in the digital
transformation journey.
 Environment plan – Document describing the current environment
planning, with a focus on data migration.
 Solution blueprint review template – Document describing the entities
that are subject to data migration, including their volumes, source, target
systems, and more.
Uwaga

This list is not exhaustive of project deliverables, but it is advantageous to share these
or have them ready to show during the Data migration strategy workshop.

Data migration strategy workshop participants

The Data migration strategy workshop is an opportunity for the project team and the
project sponsors to assess the success of their implementation and to reflect on the
adjustments to make in the future.

With that in mind, you should consider the following guidelines:

 The workshop should be attended by representatives from the customer

organization and the implementation team.
  The workshop should include the project sponsor, project manager, and
solution architect from the customer and the partner organization.

If the customer doesn't have a solution architect role in their

organization, then the responsible technical stakeholder(s) should be
involved. If the partner organization doesn't have a designated solution
architect who is responsible for the implementation, then the equivalent
delivery lead, functional lead, or technical architects should be involved.

Conduct the Data migration strategy

workshop
Completed100 pkt.
 12 minutes

The Data migration strategy workshop will be facilitated by the solution architect who
will frame the discussions, but the expectation is that the implementation team will
present the data migration information.

Each section of the agenda should be assigned an owner within the implementation
team.

Preparing and completing the presentation template for the workshop will allow for
richer discussions that often result in clear adjustment actions to take. A main goal of
the Data migration strategy workshop is to reflect on the entire strategy and then
determine the necessary adjustments to make to avoid identified issues or risks. It is
important to arrive to the sessions with a growth mindset, which encourages candid,
constructive, and honest exchanges.

Data migration strategy workshop outputs

The Data migration strategy workshop's main output is a workshop summary that
highlights the key findings and recommendations that are presented during the
session.

Throughout the sessions, we recommend that you note the identified actions by
using the dedicated PowerPoint presentation slide (for example). This approach will
allow the implementation team to follow up with the relevant attendee(s) and
respond in the most efficient manner, based on the related subject.
The final presentation, including the actions that are listed during the session, should
be distributed to all parties who participated in the workshop, including the
implementation leadership and the executive sponsors in both organizations. This
approach will ensure that everyone is in alignment on the items that were discussed
and on the following adjustment actions to take.

Data migration is a topic that will be discussed in several different phases of a project.
The plans will likely fluctuate as you learn more about the idiosyncrasies of the
different data for the project.

Ukończono moduł:

Answer the following questions to see what you've

learned.
1.

In which one of the following Success by Design phases should you review data
migration plans?

Implement
Data migration is a topic that will be discussed in several different phases of a
project.
Prepare
Initiate
All phases
Data migration is a topic that will be discussed in several different phases of a
project.
2.

Which one of the following performance metrics is not affected by your data
migration strategy?

Quality of data
If your data migration is prone to errors, your data quality will suffer.
Faster cycles
On-going, round-trip server return times
While you should be aware of all aspects of a user’s experience, this metric is
not one that is generally influenced by data migration.
An achievable cutover timing
3.

Which one of the following options is not a workshop topic that is discussed
during the Data migration strategy workshop?

Connectors
Connectors might be discussed as they pertain to the other topics, but they are
not a topic of discussion specifically.
Data volume
Testing
Performance
Introduction
Completed100 pkt.

 30 minutes

To ensure that the customer's deployment of Microsoft Dynamics 365 is more secure,
the solution architect should plan and deliver a Security model workshop. The
workshop's goal is to evaluate the proposed security model and provide feedback
and recommendations that highlight the technical risks and issues and then identify
best practices.
The Security model workshop should be scheduled and completed during the
implementation phase of the project. It should provide a summary of all security-
related areas that were previously discussed during prior workshops.

You can download examples of templates for each module workshop and use them
when you conduct these workshops for solutions.

Why security matters

Dynamics 365 drives your customers' businesses. Sensitive business data regarding
customers, financial information, and business critical processes in the system needs
to be secure for customers who adopt the system.

The correct security strategy balances legitimate security requirements with the need
for system access and cross-business collaboration. When implementing Dynamics
365, you need to balance two concerns: user access and system security.

From one viewpoint, the concern of data and system security is important. Your data
drives your business. Your customers, your orders, the contact information for key
business contacts are items that you don't want to fall into the hands of a competitor.
With regulations surrounding personal data, your company could be liable if a data
breach impacts personal data.

Alternatively, you have system usability and user adoption concerns. A main reason
for implementing Dynamics 365 is to increase visibility and sharing of business data
between groups, including elimination of data silos in your organization. By giving
visibility to contacts and accounts across your organization, teams can effectively
collaborate rather than compete, which helps ensure that you have one version of the
truth when it comes to master contact and account information. If you go too far in
either direction, you risk failure of your implementation.
If you're too lax with security, users can change data that they shouldn't be able to
change, thus polluting the single version of the truth and creating a perception that
the data in the system isn't reliable.

If too stringent in your security, and if you lock down everything so that users can
only see a small subset of the records in the system, you will diminish the value of
Dynamics 365 as a collaboration tool. Then, by design, you will revert to the old data
silos, only in a different location.

Security model considerations

Before exploring the workshop details, the following sections will review key security
elements that are common to most Dynamics 365 implementations.

Build a security strategy

While everyone's security strategy will be slightly different, the following guidelines
might be helpful for your implementation.

Be more restrictive about write than read

To maintain good data quality, limiting who can edit or delete records is a good idea,
such as limiting edit or delete rights to only owners of the records. Frequently, it
makes more sense to be less restrictive about what records other users can read. This
approach preserves the usability of Dynamics 365 and allows users to maintain
context about how their records relate to other records, such as parent accounts.
However, the approach removes the risk that users might, by malice or mistake, edit
or delete records that they don't own.

Simplify

Many tools are included in the Dynamics 365 security toolbox; however, before you
decide to use all of them, consider how simple it might be to manage the security
model long term. If the administrator needs to remember to assign four different
roles to a new user, and then add them to multiple teams for the security model to
work, the customer is unlikely to be able to maintain the strategy long term. The
solution architect should consider the impact of the security design on user
experience. Additionally, they need to determine how complex the management of
the security strategy will be for system administrators. The best security strategies are
simple, well documented, and reproducible. For this reason, using features like Active
Directory security groups is a great idea for larger more complex deployments
because the role, team, and business unit assignment can be automated, and the
chance of human error is minimized.

Ensure that security design is based on legitimate business requirements

Make sure to determine whether your decisions about security design are deriving
from a position of fear or from a legitimate business concern. If from fear, perhaps
the decision is being driven by a mistake that someone has made in the past. Fear is
never a good design motivation, especially fear of your employees. You trust your
employees to do their jobs, represent your company, and sell your products.
Occasionally, overly stringent security design indicates fundamental trust issues
between management and employees.

Document and reevaluate your security design

Security design is a concept that's considered at the beginning of a Dynamics 365

implementation, but it will occasionally be overlooked thereafter. Periodically, as the
customer's usage patterns change, or their user base changes, the initial security
design decisions aren't the best fit and need to be adjusted.

For example, when you have a smaller user base, a single business unit design can
work well. However, if your user base grows and encompasses multiple departments
with diverse requirements, you might need to add more units to scale your
deployment to a larger user base. No absolute rule has been established; the best
practice is to periodically review security strategy and design, evaluate its strengths
and weaknesses, and then identify areas for improvement. For this reason,
documenting the security model as part of the Success by Design framework is
important because it creates documentation that can be revisited intermittently by
the customer and consultant and then updated as security requirements change.

Security strategy drives configuration choices

As the customer or partner designs their table structure, they need to keep their
security strategy in mind. Table configuration supports your security strategy. For
example, if tables are created with organization level ownership, the customer will be
unable to restrict table record access by ownership or business unit. Even if you don't
have plans to restrict access to the table, it's a best practice to always select user or
team ownership, unless the table will be used only for cross-company reference data,
such as feeding a lookup list. Also, keep in mind how security of one table should
affect related table security. If access to a parent record should cascade to the child
records, you will want to use parental or configurable cascading relationship types.
Security at the platform layer, not the app layer

Numerous ways to control reading and editing data are available. You can set fields
to read-only on your model-driven form, use JavaScript to mask fields from the user
experience, and hide fields from forms and views. None of these approaches are
considered security because, while these approaches guide user behavior, they don't
secure the data. Users can get to the data in other ways. For real security to occur,
you need to use security features like roles, teams, and business units.

Security model components

Dynamics 365 provides several tools that you can use collectively to meet almost any
security requirement. This section briefly covers the primary tools that are available to
a solution architect to deliver a comprehensive security model.

Business units

Business units provide a framework to define the organizational structure of your

users and records in Dynamics 365. Business units will group users and teams by
organizational hierarchy and can work with security roles to grant or restrict access to
data.

The capability of business units comes from the hierarchical nature of the business
units. Users can be given access to records only in their business unit, or they can
have access to their business unit and the business units below their unit. For
example, the hierarchical nature of business units can allow you to limit access to
records at the site, district, region, and corporate levels.

Factors that you should know about business units:

 The root business unit is created when a Microsoft Dataverse database is

provisioned.

 A user or a team can only be a member of one business unit.

 Records are tied to only one business unit through their owning user or
team.

 A user or a team can be moved to a different business unit. When you

are moving a user or a team between business units, all records that are
owned by the user or team might need to be reassociated with the new
business unit, and people with business unit level read security in the old
business unit will lose access to those records.
  When you are moving a user or a team to a new business unit, all security
roles will need to be reapplied to the user or team.

 Non-root business units can be deleted after they're disabled.

 Business units can be moved in the hierarchy, but the root business unit
can't be reparented.

Business unit structure typically resembles a company's organizational chart, but it

should not need to be as granular as your organization chart, unless you have a
specific business reason to do so. You should see business units as building blocks for
your security model. In most cases, you don't have to create a business unit for each
department in your company. For example, at one site, the sales and marketing
departments might be able to share the same business unit if records don't need to
be restricted between groups. Keep in mind that security roles work with business
units, so though sales and marketing are in the same business unit, all users won't
necessarily be able to see all records if their security roles limit them to user level.

Security roles

Security roles determine the permission level that users have within the entities in the
organization. Security roles can be assigned to the users or teams. Security roles
determine which entities that the user can access, which records within the table they
can act on, and what permissions that they have with those records.

When assigned to a user or a team, the security role always applies within the scope
of the business unit of the user or team. Therefore, if a user inherits a security role
from a team, the privileges that are granted by that security role will apply in the
scope of the team's business unit, not the user's. This approach can be useful to
extend the access rights scope of a user to other business units. For example, using
the preceding business unit diagram, a user from the Chicago Office business unit
can be added to a team that is linked to the Atlanta Office business unit, and they can
be granted read rights to the business unit's records.

Teams

Teams is another way of grouping users and can play a role in your security strategy.
Multiple types of teams are available in Dynamics 365:

 Owner teams can be assigned security roles and can be used as record
owners in Dynamics 365. When a user is added as a member of an owner
team, they inherit from the team's security role, but the role applies in
the context of the team's business unit. Owner teams can be useful when
you are linking a record to a specific business unit.

 Microsoft Entra ID security group teams are similar to owner teams, but
they are linked with a Microsoft Entra ID security group. Users who are
added to the Microsoft Entra ID security group with a Dynamics 365
license are automatically enabled in the system, and they are added to
the linked Dynamics 365 team when they connect to the environment.
This feature is useful when you are managing user access rights outside
of Dynamics 365 because users can inherit the security roles that are
assigned to the Dynamics 365 teams.

 Microsoft Entra ID Office group teams are similar to Microsoft Entra ID

security group teams, except that they use an Office 365 group instead of
a Microsoft Entra ID security group. The primary difference is that Office
365 groups can be created, and group management can be performed
by people who aren't Active Directory administrators.

 Access teams are special types of teams that can't own records and can't
have security role association. However, like owner teams, access teams
can have shared records with them. When enabled at the table level,
access teams can grant specific record level permissions to the member
of the record's access team. This option is an alternative to manually
sharing the record with a user or a team. For entities that are configured
for access teams, creation of these teams is automated by using access
team templates.

When assigning a security role to an owner team (including Azure AD security group
teams or Microsoft Entra ID Office group teams), its member's privilege inheritance
setting should be checked to ensure that it's set properly. This setting can allow users
who are members of the team to inherit user-level privileges, as if the security role
had been directly assigned to them. This feature is useful when you are allowing users
to own records in their name, even though they don't have a security role directly
assigned to them. For example, with this setting, users can own personal views. With
owner teams, security roles don't need to be granted directly to individual users,
which helps reduce administration effort.

Hierarchy security

Hierarchy security can be used to grant visibility for user-owned records to that user's
management and higher levels of the hierarchy. For example, if a sales manager with
a team of five people needs to see records that are owned by someone on their
team, hierarchy security can provide that access. Hierarchy security supports two
different hierarchy models:

 Manager hierarchy - Grants access based on the manager relationship.

With the manager hierarchy security model, a manager has access to the
records that are owned by the user, or by the team that a user is a
member of, and to the records that are directly shared with the user or
the team that a user is a member of.

 Position hierarchy - Grants access based on definable position levels.

This model is useful when security access needs to be provided based on
indirect reporting structures. With the Position hierarchy security model,
a user at a higher position has access to the records that are owned by a
lower position user, or by the team that a user is a member of, and to the
records that are directly shared to the user or the team that a user is a
member of.

Field security

Field security allows you to secure data at the field level, such as when certain users
need to view or edit a record but shouldn't see specific details. This feature is
important in situations where data needs to be truly secure because it's secured at
the platform layer. Essentially, whether a user signs in to a model-driven app or a
canvas app, exports data to Microsoft Excel, or runs a report, field security profiles will
secure the data.

After a user has been granted access (for example, read) to a set of secured fields
through a field security profile, they're granted access to those fields on all records
that they have access to with their security configuration or through sharing.
Sharing

Sharing allows specific record-level access to be granted to specific users and teams.
Use of sharing should be limited to handling exceptions, when possible. Previously, it
was common to use and automate record sharing for complex record access
scenarios. Sharing can be a beneficial approach because it gives administrators and
users, who have the appropriate permissions, the ability to grant specific permissions
to specific records and it is useful for handling exceptions to the rule. For example, if
you need to have Salesperson A handle Salesperson B's accounts while they are out
for a month, sharing can help you accomplish that task. Sharing can also be
automated, meaning that if you need a specific condition to automatically share
records with a user or team, simple plug-ins, workflow assemblies, or ETL tools can be
used to do that. This feature has been the answer to many Dynamics 365 customers'
challenging security requirements in the past.

While sharing is a useful feature, it also creates multiple potential issues, including:

 Performance - Sharing is facilitated by the principal object access (POA)

table. When you share a record with a user or team, a record is created in
the POA table that contains the ID of the user, the ID of the record, and
the permission that they should have. The cascading nature of sharing
means that if a parental or configurable cascading relationship exists that
is sharing enabled, the child records in those relationships will also be
shared with the user or team (and more records will be added to the POA
table). Complex reparent or inherited share scenarios can also create
records, which can cause the POA table to grow quickly. This scenario
becomes a performance issue when the table expands (somewhere
between 20 million and 2 billion records). When you query Dynamics 365,
such as when opening a view or advanced find, or when viewing a chart,
the results are filtered by the POA table. If the table is large or indexes
aren't optimized, it can lead to slow system performance.

 Administration challenges - You can't easily identify which records are

shared with a user. While you can select a record and show whom it is
directly shared with, a method doesn't exist to help you to accomplish
that task for all records. Also, cascading or inherited shares don't show in
the sharing dialog on the record. Without opening each record in the
context of that user, it's almost impossible to know if your sharing
strategy is working correctly.

 Forgotten shares - Previously, a scenario was explained where you

shared Salesperson B's records with Salesperson A, who handled their
coworker's accounts while they were off for a month. Odds are that the
administrator will forget to stop sharing those records, which could
 create issues if Salesperson B needs to reconnect to people in their
workflow.

 Can't make it right - After the customer uses the system for a year or
two, they might find that it has become inaccurate or out-of-date. They
might also decide to make a wholesale change to their sharing strategy;
accordingly, they want to run a batch job to set and update all records
with the appropriate sharing permission. No simple method exists for
completing this task with sharing.

Alternatives to sharing

Steps that you can take to avoid issues with sharing include:

 Use team ownership - With team ownership, you can assign records to
teams of users in multiple business units.

 Share with teams, not users - If you share a record with 10 users, 10
POA records will be created, times 10 POA records for each child
cascading shared record. If you share the record with a team that has 10
users, only one POA record is created (along with one POA record for
each cascading share). This approach will help reduce the size of your
POA table dramatically. If you want to remove a user's permissions, you
can remove them from the team.

 Use access teams for controlled sharing - Use this approach if you
can't create owner teams but still want to be able to grant special access
to specific records to specific users. In this scenario, you want to give
certain users access to only read the record, while you want other users
to be able to read or write to the record. Access teams can handle that
situation, and you can have multiple access team templates, one for read
and one for read/write. Access teams are designed with performance in
mind, so they don't actually create the team and share the record until
you add the first member of the team. When a record is shared with an
access team, a record is also created in the POA table.

Sample security scenario

The following scenario explains how these tools can be combined to provide a
comprehensive security model. In this example, Contoso LTD is a consumer products
company that wants to ensure that users have access to information that is necessary
for them to do their job while protecting sensitive data. By combining the security
tools in Dynamics 365, the company can address each of the following scenarios.
Bob

Field-level security prevents Bob from seeing sensitive information on a record, and
team or business unit security limits their view to only the company's issues.

 Manufacturing engineer

 Needs to be able to see quality issues that are reported by clients

 Shouldn't be able to see the email and mobile phone of the client

 Shouldn't be able to see issues for other companies

Amy

Business unit security means that Amy can see records that are owned by someone
else in the division, but that Amy can't see or edit records in other divisions.

 Customer service rep

 Creates customer service cases from use complaints

 Should be able to see customer information and case history for clients
that use her division’s products

 Shouldn't be able to see customer data for other divisions

Roy

Hierarchical security enables Roy to see records that are owned by their direct or
indirect reports, but not other users.

 Sales manger

 Needs to see his direct reports' records

 Shouldn't see data for other sales managers

Linda

Linda’s security role provides organization-wide visibility for data in Dynamics 365.

 General manager
  Needs visibility for all customer data and related issues

Security model workshop

The Security model workshop should be limited to about one hour and is often
conducted as part of a Microsoft Teams meeting when everyone isn't together on
site. Attendees should include key stakeholders from the customer and partner
teams. Solution architects, functional leads, and technical leads are mandatory.

The security details from the Solution blueprint workshop template should be
referenced in preparation for the Security model workshop.

Security workshop topics

Completed100 pkt.

 50 minutes

This unit focuses on the recommended topics that should be covered in the Security
model workshop.

Security model overview

In the Security model overview section of the template, you should provide a high-
level overview of the attendees' security model. The details don't need to be
extremely granular because each specific area will be discussed in detail later in the
template.

Next, answer the question of how you are managing access to records. This
information is helpful to know if specific restrictions are in place on data (such as
salespeople only being allowed to view their own customer data) or if other special
data access information will impact the security model. In addition, this section can
include technical details, such as the requirement to have multifactor authentication
to access system data.

Basics

Two slides in the template cover basic information about the security model. The
following questions are included on these slides.

 How many users do you have (target)? - The number of users has a
significant impact on the scalability of your security model. For example,
if the customer is relying on sharing records to provide access, they
 should be aware of the potential performance impact when many records
are shared between many users. Some security models that are
acceptable for small user counts become unsuitable as user count grows.
For that reason, it's important to consider current and expected future
user growth.

 How many distinct security patterns or configurations do you have

in your model, and how many users are in each pattern
configuration? - Security pattern refers to the different security
configurations that the customer wants to implement to answer the
requirements. For example, people in the sales department will use the
standard use of user security roles, people in customer service will use a
combination of user roles and manager hierarchy, and people in
marketing will only use access teams. By determining the expected
number of patterns, you'll identify if the security model will be overly
complicated or difficult to maintain long term.

 What percent of users potentially have more complex security

requirements than the rest? - Customers sometimes over-complicate
their security models by designing around niche exceptions to the
standard process. When you identify the existence of many different non-
standard requirements, you should question the requirement and
recommend standardizing on the main process.

 Do you need to restrict access to data or filter access to data? - This

question distinguishes between convenience filters and real security
requirements. Wanting to provide users with a simplified view of data
that matters most to them is a good goal; however, security shouldn't be
used to achieve this objective. Use views to filter data while leaving
access to other records available.

 What number of security roles do you need? - Keeping the number of

security roles to a minimum makes administrative tasks easier to manage.
Dynamics 365 includes many standard security roles for standard user
types like sales manager, customer service rep, and system administrator.
These roles should be used as the basis for the customer's security roles.

If requirements differ from standard roles, consider creating copies of

standard roles and iterate from them.

 Have you created new security roles instead of customizing existing

ones? - A recommended best practice is to save a copy of one of the
standard security roles rather than creating a new one.
 Security roles include many permissions that are required to get into the
application, and creating a new role is problematic because the customer
likely won't have all necessary base permissions.

Remind the customer that new permissions are frequently added to the
standard security roles by using regular application updates, and these
new permissions aren't automatically added to existing custom security
roles. If custom security roles are used, someone will need to remember
to identify the newly added permissions and update the custom security
roles following each update to ensure continuity of system access after
updates.

 Have you tried to reduce the number of security roles as much as

possible? - The more security roles that a Dynamics 365 deployment
uses, the more difficult it will be to administer long term. When new
functionality is added, if 25 separate security roles are available, and the
functionality is needed by everyone, then the maker will need to update
25 security roles to provide access to the new feature.

One popular strategy is to use a base role, which provides the baseline of
functionality that is needed to sign in to the application and all tables
that are available to all users. Next, supplement that role with extra roles
with the role-specific features that are needed by that role.

For example, if all users need to read accounts, but only the sales
managers should be able to create new ones, your base role would
contain organization level account read permission, and the sales
manager role would only include account create permission. Then, if a
new feature was added that all users need, it can be added to the base
role only.

 What's the number of security roles that an individual person

needs? - The more security roles that need to be added to an individual
user, the more complicated user onboarding will become, and the more
likely that someone will make mistakes. If many required roles exist, these
roles should be consolidated to help make ongoing administration
easier.

Another approach that can help is by using Microsoft Entra ID security

group or Microsoft Entra ID Office group teams so that you can grant the
roles once to the team and then the users will automatically inherit the
roles for the team (so, in the context of the team's business unit), after
being added to the appropriate Microsoft Entra ID group.
  Are the security roles created at the root business unit level or at the
child level? - While you can create roles that are specific to one child
business unit, we recommend that you create security roles and edit
them at the root business unit level.

Creating roles at the root business unit level makes the role available to
all business units, while child-level business unit roles are only available
at a single business unit level. If you have a business unit-specific role,
when you move a user to another business unit, that role won't be
available. Otherwise, you'll have different versions of the same role at a
different business unit, making the system difficult to administer.

 What's your strategy to update the security roles as you roll out new
tables and functionality? - In a rapidly changing environment with
continuous development, it can be easy to forget to update roles, or only
test with system administrator access, and miss updating security roles to
include the new functionality. The customer's strategy should include a
process for updating security roles and testing with each persona's role
mix whenever a new configuration release is rolled out.

Reasons for this information

The reasons why you should ask for the preceding information from your attendees is
because:

 It's rare that one security pattern suits all user needs and roles. You need
to understand how many different patterns you will need to implement in
the project.

 Complex security models are frequently designed to accommodate the

needs of a fraction of users that don't fall into the main model. In that
case, an opportunity to challenge could exist if those users couldn't
access the desired data in a different manner or elsewhere, such as
reporting.

Business units

In this section, you will provide a description of the hierarchical structure of the
customer's internal organization and the business unit structure in Dynamics 365.
Some relationship should exist between the business unit structure and the
organization structure, but the business unit structure shouldn't be as granular as the
organization structure. Though two groups are in different divisions of the company
doesn't mean that you'll need to restrict visibility of records between the two groups.
Frequently, multiple departments can share the same business unit.

Use a tool like Microsoft Visio, or some other visual diagram/charting application, to
create a visual representation of the structure. If you already have a document that
visualizes the organizational hierarchy of the company, you can paste a screenshot of
that diagram in the document.

Be aware of two potential issues: too many business units or not enough business
units.

Too many business units

If the proposed security model identifies that hundreds or thousands of business

units will be available, this issue should be flagged as a risk. Business units are like
large granite rocks; they are designed to be permanent and infrequently moved.
While users can be moved between business units, it's not a trivial matter, especially if
they own many records.

When you move a user from Business Unit One to Business Unit Two, the business
unit association of every record that the user owns will change. This factor can cause
some surprises to other users who are members of the user's original business unit, if
they have business unit level read permission. The records that are owned by the
moved user will no longer be available to them, but if they own child records of those
records, like activities, it could cause odd scenarios to occur. Also, if the user owns
many records, moving users between business units can be time-consuming.

Another potential impact from large quantities of business units is extremely slow
security role updates. Each role isn't only one record. A copy of each role is added to
each business unit. Therefore, if you create thousands of business units, making a
small change to a security role could take hours.

A good practice is to keep your business units to a minimum. Use only the minimal
number to facilitate true business unit security requirements. For more granular user
segmentation, consider the use of teams. Teams are more flexible, they can be used
to control security access to records, and users can be members of multiple teams.

Not enough business units

If you're implementing for a single group, it's common to only want to use the root
business unit for all users.
While the "keep it simple" approach is great, a strong possibility exists that the
customer might, at some point, have some pieces of data that they want to keep
secret from a subset of users.

Consider the following scenarios:

 You expand Dynamics 365 usage to other parts of the company.

 Your company is acquired by a large, multinational company.

 The CEO decides to track emails and doesn't want everyone to read
them.

 The VP of sales discovers several contacts in their address book that need
to be in Dynamics 365 but are better kept private from the rest of the
company.

Moving people between business units is difficult, and it's a process that you'll want
to do only when necessary. If the customer starts with all users in the base business
unit, if a change develops that requires a subset of data to be separate, the customer
will have to relocate many or all existing users because the root business unit can't be
reparented.

To guard against this eventuality, it might be a good idea to initially create one child
business unit and then put all users in that business unit. If your business changes to
require further segmentation of data, this approach will help simplify those changes
because the business unit with the bulk of users can be reparented, or selected users,
like the CEO, can be moved to the base business unit. A full-scale business unit move
of all users can be avoided.

Teams
The Teams section of the Security model template captures details regarding the
planned use of team records for security in Dynamics 365.

In this section, you will provide answers to the following questions:

 Do you use owner teams to assign roles to users? - Owner teams

(including Microsoft Entra ID security group and Microsoft Entra ID Office
group teams) are a great way to assign security roles to users and to
reduce administration effort. When a security role is assigned to a team,
it's inherited by the member users but applies in the team's business unit
scope.
 Do you use owner teams to own records? - Team ownership of records
can be considered to manage the association of a record with a business
unit separately from the otherwise standard owning user's business unit.
This approach can be helpful when the functional association of a record
and a business unit differs from the user's association with a business
unit.

Some downsides and risks are associated with team ownership of records
that you should be aware of. Generally, it requires automation to be
consistent and user-friendly. Some features, such as goals and
forecasting, rely on user ownership of records. Also, the ability to
reassign a user's records in bulk (for example when a new salesperson
replaces a retiring salesperson and inherits their customer portfolio) isn't
available for owner teams.

Team ownership of records can be used to simplify complex security

models and reduce the need for excessive record sharing. Owner team
roles grant special security permissions in the context of records that are
owned by the team. Therefore, if members of a sales team should have
the right to edit opportunities for which they're associated, but read-only
for opportunities that they aren't associated with, owner security teams
can enable this exception without having to use complex sharing.

 Do you automate record assignment and how? - When a new account

is created, you need to determine how you will assign the record.
Additionally, you should consider whether the sales coordinator will
remember to accurately assign the record manually. For important record
types, such as accounts, we recommend that you have an automated
process that automatically assigns records when they are created to
simplify ongoing administration of the system. One approach could be
storing sales person assignment by state on the territory record in
Dynamics 365. Then, when a new account is created, a Microsoft Power
Automate flow runs. It compares the state of address one to the territory
state field and assigns the account to the appropriate territory and
salesperson. Then, it sends a notification email to the salesperson to tell
them to contact their new potential customer.

 Do you use access teams (system or manually managed)? - Access

teams are great solutions to managing special record permissions. For
example, if a sales assistant needs to have edit permissions on 25
different accounts, rather than sharing the accounts manually with them,
you can add them to an access team subgrid on the record, and then
they'll inherit edit permissions based on the access team template that is
associated with the grid. Access teams are excellent solutions because
 only one sharing record for the entire access team is created in the POA
table rather than individual records for each person, like record sharing
does (see the previous Sharing section in this module). This approach
also allows administrators to see who has access to the record.

If the same group of people needs access to multiple records, access

teams can also be used to share the records with that team. However,
keep in mind that an access team can't own records and they can't be
assigned security roles.

 Do you automate access team membership? - It's common to have a

matrix of people who need access to records. For example, a
manufacturing project needs an engineer, an electrician, and a safety
engineer. Frequently, these assignments are maintained in another
system.

In this case, the access team should be used because the mix of
individual people is different on each record and security access is
needed for the members of the team. You can automate access team
membership by using approaches like integration, actions, or plug-ins.

 How do you deploy access team templates across environments? -

Access team record permissions are established by an access team
template. The template determines what permissions are shared with the
members of the team.

One challenge is that access team template records aren't solution aware,
meaning that they can't be added to solutions. When customizations are
moved between environments, the access team template will need to be
moved or manually recreated in the target environment. If you're
automating an access team membership, the templates must have
identical GUIDs across environments, as they're referenced in your logic.

Multiple approaches are available for you to use to migrate access team
templates, including the configuration data migration utility, ETL tools
like Scribe or SSIS, or utilities in the XrmToolBox.

 Do you use Microsoft Entra ID synchronized groups to manage

access rights? -Microsoft Entra ID security group teams or Microsoft
Entra ID Office group teams are great for automating the assignment of
role permissions to users and should be considered for larger or more
complex deployments.
 With Microsoft Entra ID, you can fully control permissions from a single
source.

 Do you have requirements that didn't fit into the standard model? -
Identify non-standard security requirements. In the findings and
recommendations section, recommend approaches to standardize non-
standard requirements.

Implemented security mechanisms

In this section, you will identify what methods are used to automate security,
including automated sharing, field-level security, hierarchy security, plug-ins, and
relationship behaviors. Refer to the security tools section of this module if you're
unfamiliar with any of these approaches.

Reasons for providing this information:

 Performance issues can occur if you automate sharing at scale. The

PrincipalObjectAccess or POA table is filled with exceptions to the
standard security model.

 Sharing should typically remain a manual process to grant exceptions to

the security model that is in place and should be avoided at scale.

 While it's easy to adjust a user's business unit, teams, and roles, it can be
complex to do a data migration on custom sharing rules after a
reorganization.

 Field-level security isn't user or business unit aware.

 Hierarchy security can cause performance issues in complex

configurations if too many levels are in the depth of the hierarchy.

 Cascading behavior in relationships is convenient, but it can sometimes

have unintended consequences (such as reassigning closed activities
when an account is reassigned). Cascading assignment or sharing can be
disabled or modified on a relationship basis, or by using an ORG DB
setting of DisableImplicitSharingOfCommunicationActivities.

User interface
Many components of Dynamics 365 are security role enabled, meaning that access to
that item can be limited to one or more security roles. This feature is important
because different users require different experiences while using common tables, and
by limiting access to app components that aren't needed by users, you will provide a
simpler, more tailored experience for the user.

Items in Dynamics 365 that can be role-enabled include:

 Model-driven apps

 Dashboards

 Forms

 Business process flows

 Site map subareas

 Command bar buttons

 Document templates

In this section of the template, you will identify if roles are being used to simplify
access to these areas.

Reasons for providing this information:

 Security roles and table privileges can be used to tailor and trim the
experience for your users.

 The fewer elements that users see, the easier the experience will be.

 Model-driven apps can be associated with security roles and help

simplify the overall user experience by trimming the list of views, charts,
dashboards, forms, and business process flows.

 Customers without a strategy in this area might experience unexpected

issues. For example, the common Microsoft apps like Sales Hub,
Customer Service Hub, and App for Outlook will control access by using
app access security roles. If a customer tests with only a system
administrator role, they might miss the fact that users without this role
need the app access role to use the app (or the app needs to be shared
with their custom security roles). This scenario can lead to users not
having access to the apps that they need during deployment.

Scalability, performance, and maintainability

In this section of the template, you will examine questions that will identify if
potential issues might occur when the application scales to additional users and the
amount of data increases.

Maintenance questions and why they matter

Answer the following maintenance questions in the template.

 Have you identified scenarios where the record doesn't need to be

owned by a user or team? - When creating new tables that represent
cross-company referential data and will never need granularity for each
business unit, team, or user, you should consider creating them as
organization-owned tables.

Record ownership is important where variable visibility or editing

permission will need to be granted to different users. However, if general
records exist that should be visible to all users, and all users share the
same level of edit permissions (such as records that are generated by
using an integration), a strategy such as assigning records to the business
unit team should be considered so that these records don't need to be
reassigned when someone leaves the company.

 Have you identified potential scalability challenges in your security

design at higher volumes? - Strategies like record sharing can work
adequately in smaller deployments but can quickly become inefficient
when scaled to large numbers of users.

Also, having users be members of thousands of teams in thousands of

business units can be a challenge in terms of performance and scalability.

 Have you considered the impact of your data and security models on
the POA table? - Excessive sharing leads to a large POA table and can
degrade system performance.

 Do you regularly update user, team, or business unit records? - As a

general rule, regular updates to user, team, or business unit tables should
be avoided. For example, updating an attribute on a user table can cause
the security cache to flush and potentially impact performance.

 Have you considered the impact of a large reorganization to the

users, teams, business units, and records? - Business structures
change. New companies are acquired, divisions are divested, and people
leave or move to other departments. Your structure should be flexible
 enough so that you can easily add or remove users, teams, or business
units without requiring a complete security model redesign.

 For users who already have access to a large percentage of records,

have you considered providing global access for better
performance? - Providing organization/global read access to records
can optimize performance for the implementation of a view because the
system doesn't have to consider the security principles that apply to a
user (individual roles, team roles, shared records, hierarchy) when
retrieving records.

While a user might have access to all records from a security standpoint,
you should customize system views that will filter the number of records
to only present what is relevant to their work.

 Do you bulk reassign records when a user leaves? Have you

considered the impact of a cascading relationship? - Relationship
cascading settings for activities and other common records can cause
unexpected results when you are reassigning records, and this behavior
should be modified if you don't want to have closed activities reassigned
when you reassign customer account and contact records.

Security testing
The security model is composed of multiple parts working together, and it has
multiple areas where it could fail. In this section of the template, you will review the
approach that will be used for testing security, identify the ongoing plan to monitor
access to Dynamics 365, and ensure that the design of security roles is well
documented and will be simple to maintain long term.

Security questions and why they matter

In the security testing section of the Security model template, answer the following
questions.

 Do you have test environments to validate the data in the context of

your security requirements? - To adequately test security roles, your
customer will require a non-production environment with the same
configuration as production and a close approximation of the production
dataset. While you don't require 100 percent of the data from
production, the data must be similar enough to accurately test the
behavior of security roles. It's also important to have distinct test users
and not reassign roles to the same test users. The reason is because users
 who originally have higher permission might retain access to certain
records when that role is removed by using record ownership or sharing.

Do you have the security matrix Excel sheet with access levels and
privileges defined by your business or customer? It's important to have
some documentation of security design outside of the Dynamics 365
security role in case someone changes the security role in Dynamics 365
and you want to remember how it was designed. This document can be
an Excel spreadsheet that indicates the appropriate permission level by
table.

 Do you have test cases around the security matrix for all security
roles? - The customer's security requirements likely came from the
requirements that were gathered during the previous workshops in the
project, and these requirements create the basis of security test cases.
Each security restriction should have a test case and be tested thoroughly
before go live. Then, the restrictions should be tested in the context of
each impacted security role or persona.

 Have you considered negative testing on field-level security fields

and teams? - It's important to test if someone with a role can see
secured fields and can access records that are assigned to their team.
Additionally, you should verify that users without these roles or team
assignments can't access these items.

 Will you perform penetration tests on the platform? - For highly

secure environments, penetration testing is an option. Keep in mind that
penetration testing must follow the Microsoft Cloud rules of engagement
for penetration testing. For more information, see Penetration testing
rules of engagement.

Other Dynamics 365 security questions

In this section of the Security model template, you will examine security regarding the
related functions within Dynamics 365.

Dynamics 365 security questions and why they matter

Provide answers to the following questions.

 Have you considered the Export to Excel privilege? - Export to Excel is

a great convenience and reporting feature, but it can also be a risk
 because some customers have had employees take client data with them
when they leave the company.

It's important to be aware and cautious that, though the Export to Excel
privilege might prevent some users from easily downloading data off
Dynamics 365 with the Export to Excel button, whoever has a read
access to a record can access that data through APIs and ultimately
export it.

 If applicable, how do you plan to control security in Data Export

Service, Azure SQL, or Export to Data Lake and Power BI? - When
data leaves Microsoft Dataverse for reporting or integration, it's no
longer protected by Dynamics 365 security. Organizations must be aware
of this parameter and plan for security when the data leaves the system.

 If applicable, what is your security model strategy for Power Pages

and Unified Service Desk? - Power Pages help you expose data
externally and also allow external parties to update Dynamics 365 data.
However, it's important to consider the security implications of this
feature and ensure that secure and sensitive data isn't exposed to the
wrong people.

If your users inherit their security roles exclusively from teams, have you
considered using the Inheritance to direct user setting on security
roles? When you are assigning a security role to an owner team
(including Microsoft Entra ID security group teams or Azure AD Office
group teams), its member's Privilege inheritance setting should be
checked to ensure that it's set properly. This setting can allow users who
are members of the team inherit user-level (and not business unit-level
or higher) privileges as if the security role had been directly assigned to
them.

This feature is useful in allowing users to own records in their name, even
though they don't have a security role directly assigned to them. For
example, with this setting, users can own personal views. With owner
teams, security roles don't need to be granted directly to individual users,
which helps reduce administration effort.

 If you plan to use virtual tables, have you considered creating a

security model around them? - Virtual tables enable creation of tables
that don't store data in Dataverse but rather point to an external data
source. While this feature is convenient, and in many cases preferable to
overloading Dynamics 365 with data, you should understand that the
virtual table connection uses a single data source, meaning that all users
 who have access to the virtual table will see the same records. If you have
sensitive records that shouldn't be visible to all users, data integration is
recommended.

Security monitoring
In this section of the template, you will review the customer's strategy for monitoring
appropriate access rights and will identify misuse of the application. If activity audits
are enabled in Dynamics 365, many user activities are logged in the Microsoft 365
admin center. By using these logs, you can identify unusual or potentially malicious
activity in the system, including common actions such as:

 Who published customizations

 Who was added to a team

 Who added a solution

 Who published customizations

 Who exported to Excel

 Who viewed a report

 Who exported a report

Standard audit logs monitor when users access the system. Tools like Microsoft
Power Automate can alert you when certain activities happen, and Microsoft Entra ID
can alert you when people outside of the usual geographies attempt to access the
system.

In this section of the Security model workshop template, you will summarize the
strategy for monitoring and alerting abnormal behavior and plans to regularly verify
user permissions in Dynamics 365.

Regulations and compliance

In this section of the template, you will identify if governmental or compliance
regulations are in place that might impact the security model for Dynamics 365.
These regulations include consumer data protection regulations like HIPAA, and SEC
and auditor concerns like business segmentation. Complete the information in the
regulations and compliance slide.
Security beyond Dynamics 365
In this template section, you will look beyond Dynamics to other systems that
integrate with Dynamics 365 and associated security. Dynamics 365 is not
autonomous; other systems interact with it or are integrated with it. Therefore, you
should take a holistic view of security, not just security for the individual pieces.
Update the Security Beyond Dynamics 365 slides to answer the following questions.

 Have you associated your environments with a security group to

control users who have access to it? - Associating a Dynamics 365
environment with a Microsoft Entra ID security group will limit access to
the environment for users who are outside of the group and will limit the
users who show as enabled in the system. It also simplifies the experience
for users because they'll only see the environments that they have access
to appear in the environment list.

 Do you use Conditional Access in Microsoft Entra ID to control how

users access your Office 365/Dynamics 365 data? - Conditional Access
in Microsoft Entra ID can be used to limit from where and from what
device the environment can be used and what services and connectors
can be used.

 Do you use mobile device management to manage a fleet of devices

(mobile phones and so on)? - By using mobile device management
(MDM) solutions, like Microsoft Intune, you can enforce security,
remotely manage the deployment of Dynamics 365 mobile apps, and
also remotely remove data in case the device is lost or stolen.

 Do you integrate with SharePoint? If yes, how are you addressing

security in SharePoint versus security in Dynamics 365? - SharePoint
document integration automates the creation of document libraries in
SharePoint from Dynamics 365 records and provides quick access for
Dynamics 365 users to documents that are stored in SharePoint. Security
can be a concern because the SharePoint document library security
doesn't mirror Dynamics 365 security. If someone has access to the
SharePoint site where Dynamics 365 documents are stored, they can view
the documents in the library, even if they don't have access to the related
Dynamics 365 record. If this situation is a concern, you should consider
alternatives where access rights are narrower on the SharePoint side (for
example with multiple SharePoint sites, OneDrive for Business
integration, or Teams integration).

 Do you integrate with Microsoft Power BI? If yes, how are you
addressing security in Power BI versus security in Dynamics 365? -
 When Power BI is reporting directly from Dataverse by using the
standard Microsoft Dataverse connector, it reflects only the data that the
user has access to in the system. However, if that Power BI report is
shared, other users with whom the report is shared will see the data from
the report owner.

Row-level security can be implemented to enforce security on the Power

BI side, but another option is to create a SQL DirectQuery report in Power
BI that will render in the connected user context. Then, sharing a report
will only result in sharing the representation of the data, not the actual
data, and the Dynamics 365 security model will be fully enforced.

 Do you use other security mechanisms? - Other security mechanisms

might include multifactor authentication, external authentication
providers like OKTA, and others.

 Does your security model hold dependencies on independent

software vendor (ISV) solutions? If yes, what are they? - ISVs provide
valuable solutions that can enhance a deployment of Dynamics 365, but
they can also introduce security risks and dependencies. It's important to
understand how this solution will be deployed, how it will be updated,
and what kind of security access that the ISVs will require.

 What are your requirements for data integration security patterns? -

When data flows between systems, it's important to understand when
security will need to be controlled at the flow level. Make sure that you
determine what security access that the integration will need to the
source system, what security access that the integration will require in
Dynamics 365, and what account that the integration process will run as.
We recommended that you use application (non-interactive) users to
control access for integration accounts.

 If you're using other Microsoft Power Platform capabilities such as

Power Automate and Power Apps, what are your security
requirements and design? - Power Apps and Power Automate use
connectors to integrate to hundreds of different systems, and these tools
are part of the same platform as Dynamics 365. Canvas apps in Power
Apps and Power Automate flows use Dataverse, as does Dynamics 365,
and apps and flows can be managed in solutions along with other
Dynamics 365 components in solutions. The introduction of other
connectors into the process introduces a number of additional security
considerations, including data access and security in those systems and
environment strategy for where apps and flows that touch production
Dynamics 365 are being built. Other security considerations include
 access for makers who are connecting to your production Dataverse
environment and data loss prevention (DLP) policies that determine
which connectors can be used together. The solution architect should ask
clarifying questions around Microsoft Power Platform environment
strategy and DLP strategy, and then identify what permissions that users
will have for making apps and flows.

 Do you have specific infrastructure security requirements

(encryption and so on)? - Dynamics 365 offers advanced encryption
options, including customer-managed keys for eligible scenarios. Identify
if these options are used and whether the customer has established a
strategy to maintain these methods long term.

Ukończono moduł:

Answer the following questions to see what you've

learned.
1.

During what phase of Success by Design should the Security model workshop
be scheduled and completed?

Initiate
The Security model workshop should be scheduled and completed during the
implementation phase of the project. It should consist of a summary of all of
the security-related areas that were discussed during prior workshops.
Implement
The Security model workshop should be scheduled and completed during the
implementation phase of the project. It should consist of a summary of all of
the security-related areas that were discussed during prior workshops.
Prepare
Operate
2.

Does security only need to be reviewed at the user level because team and
business unit security is set automatically and shouldn't be updated?

Yes, it only needs to be reviewed at the user level.

Business unit and team security should be evaluated as part of the Security
model workshop.
No, it also needs to be reviewed at the team and business unit levels.
Business unit and team security should be evaluated as part of the Security
model workshop.
3.

What items in Dynamics 365 can be role-enabled?

Dashboards
Items in Dynamics 365 that can be role-enabled include model-driven apps,
dashboards, forms, business process flows, site map subareas, command bar
buttons, and document templates.
Business process flows
Site map subareas
Command bar buttons
All of the above
Items in Dynamics 365 that can be role-enabled include model-driven apps,
dashboards, forms, business process flows, site map subareas, command bar
buttons, and document templates.

Introduction
Completed100 pkt.
 2 minutes

finance and operations apps has an array of security and configuration options to
help keep your sensitive data safe, users focused on their roles, and the system as
streamlined as possible.

Knowing how to implement different security options will help companies cover their
security requirements. When you understand the security architecture of finance and
operations apps, you can more easily customize security to fit the requirements of
your business.

Understand the security architecture

Completed100 pkt.
 8 minutes

When you understand the security architecture of finance and operations apps, you
can more easily customize security to fit the requirements of your business.
In this lesson you will learn about:

 Security architecture
 Role-based security
 Duties
 Privileges
 Permissions
 Authentication
 Authorization
 Auditing

The system architecture of finance and operations apps uses the stack of features
within Microsoft Azure. This allows finance and operations apps to operate and
communicate with a variety of web enabled devices.

The security model is hierarchical, and each element in the hierarchy represents a
different level of detail. Consider the following facts regarding security:

 Finance and operations apps uses role-based security.

 Access is granted only to security roles, not to individual users.
 Users are assigned to roles. A user who is assigned to a security role has
access to the set of privileges that is associated with that role.
 A user who isn't assigned to any role has no privileges.

The following diagram provides a high-level overview of the security architecture:

Role-based security
Role-based security is aligned with the structure of the business. Users are assigned
to security roles based on their responsibilities in the organization and their
participation in business processes. The administrator grants access to the duties that
users in a role perform, not to the program elements that users must use.

In role-based security, access is not granted to individual users, only to security roles.
Users are assigned to roles. A user who is assigned to a security role has access to the
set of privileges that is associated with that role. A user who is not assigned to any
role has no privileges.

All users must be assigned to at least one security role to have access to finance and
operations apps. The security roles that are assigned to a user determine the duties
that the user can perform and the parts of the user interface that the user can view.

Users are assigned to roles via System administration > Security > Assign users to
roles.

Because rules can be set up for automatic role assignment, the administrator does
not have to be involved every time that a user's responsibilities change. After security
roles and rules have been set up, business managers can control day-to-day user
access based on business data.
By default, sample security roles are provided. All functionality in finance and
operations apps is associated with at least one of the sample security roles. The
administrator can assign users to the sample security roles, modify the sample
security roles to fit the needs of the business, or create new security roles. By default,
the sample roles are not arranged in a hierarchy.

Duties
Duties correspond to parts of a business process. The administrator assigns duties to
security roles. A duty can be assigned to more than one role. In finance and
operations apps, duties contain privileges. For example, the Maintain bank
transactions duty contains the generate deposit slips and cancel
payments privileges. Both duties and privileges can be assigned to security roles.
However, we recommend that you use duties to grant access to finance and
operations apps.
Privileges
Privileges can be assigned directly to roles. However, for easier maintenance, we
recommend that you assign only duties to roles. A privilege specifies the level of
access that is required to perform a job, solve a problem, or complete an assignment.
It also contains permissions to individual application objects, such as user interface
elements and tables.

For example, the Cancel payments privilege contains permissions to the menu items,
fields, and tables that are required to cancel payments.

By default, privileges are provided for all features in finance and operations apps. The
administrator can modify the permissions that are associated with a privilege or
create new privileges.
Permissions
Permissions represent access to individual securable objects, such as menu items and
tables. Privileges are composed of permissions and represent access to tasks, such as
posting a journal and processing credits and collections. Duties are composed of
privileges and represent parts of a business process, such as maintaining cash and
bank transactions. Both duties and privileges can be assigned to roles to grant access
to finance and operations apps.

Each function in finance and operations apps, such as a form or a service, is accessed
through an entry point. Menu items, web content items, and service operations are
referred to collectively as entry points.

Authentication
Only authenticated users who have user rights in finance and operations apps can
establish a connection. finance and operations apps uses Microsoft Entra ID as a
primary identity provider. To access the system, users must be provisioned into a
finance and operations apps instance and should have a valid Microsoft Entra ID
account in an authorized tenant.
Authorization
Authorization is the control of access to the finance and operations apps program.
Security permissions are used to control access to individual elements of the
program: menus, menu items, action and command buttons, reports, service
operations, web URL menu items, web controls, and fields in the finance and
operations apps client.

In finance and operations apps, individual security permissions are combined into
privileges, and privileges are combined into duties. The administrator grants security
roles access to the program by assigning duties and privileges to those roles.

Finance and operations apps uses context-based security to determine access to

securable objects. When a privilege is associated with an entry point (such as a menu
item or a service operation), a level of access, such as Read or Delete, is specified. The
finance and operations apps authorization subsystem detects the access at run time,
when that entry point is accessed, and applies the specified level of access to the
securable object that the entry point leads to. This functionality helps to ensure that
you do not assign more permissions for a user than you need to.

Auditing
Auditing of user sign in and sign-out is now enabled in finance and operations apps.
The system logs when a user signs in or out of the application. A sign-out is logged
even if the user's session expires or ends.

A system administrator or security administrator can access the audit logs by going
to the User log page (System administration > Inquiries > User log).

Additional considerations:

 External Roles form allows administrators to assign security roles to an

external part role such as a customer, vendor, prospect, prospective
vendor and worker
 Dormant user security accounts allow you to identify idle accounts and
find out if the accounts are enabled or disabled

Encryption in finance and operations

apps
Completed100 pkt.
 5 minutes
Encryption at rest
Microsoft uses encryption technology to protect customer data while at rest in an
environment's SQL Server database and Azure Storage.

All instances use Microsoft SQL Server Transparent Data Encryption (TDE) and Azure
Storage encryption to perform real-time encryption of data when written to the disk
at rest.

Finance and operations apps use server-side encryption using service-managed keys.
All key management aspects such as key issuance, rotation, and backup are handled
by Microsoft.

In addition to the default encryption at rest provided above, you can use the
encryption API available in the Global X++ class. The
methods Global::editEncryptedField() and Global::editEncryptedStringField() use
the environment-specific data encryption certificate to perform data encryption and
decryption. You can use these methods as an additional layer of protection beyond
the default encryption at rest technology used for data storage.

Encryption in transit
Connections established between customers and Microsoft datacenters are
encrypted, and all public endpoints are secured using industry-standard Transport
Layer Security (TLS) 1.2. TLS effectively establishes a security-enhanced browser-to-
server connection to help ensure data confidentiality and integrity between desktops
and datacenters.

See Encryption in finance and operations apps for information about encryption.

Manage users and security

Completed100 pkt.
 12 minutes

Users are internal employees of your organization, or external customers and

vendors, who require access to the system to perform their jobs. It is not
recommended that you add users from outside your company to your organization.
Partners and other users who aren’t part of your organization should be invited only
to projects.
Administrators can't remove automatically assigned roles from users. Users can be
excluded from roles by the administrator.

When a user is excluded from a role, the role assignment for that user is no longer
controlled automatically. Excluded users are listed in the role membership when the
rules for automatic role assignment are run, or when an Active Directory group is
assigned to a role. However, they are marked as excluded. The role's associated
access is not granted to the excluded users. Users who are excluded from the role
can't be assigned to the role again until the administrator removes the exclusion.

Here is an overview of creating new users, assigning security roles and linking
records.

 Create new users- Before you can access finance and operations apps,
you must first be added to the Users page in System administration >
Users. Users include internal employees of your organization, or external
customers and vendors. Users can be imported or added manually. All
users must be correctly licensed for compliant use.
 Add an external user in Microsoft Entra ID and assign a license -
External users must be represented in your tenant- directory (Microsoft
Entra ID) so that they can be assigned licenses. Those external users
should be added to the tenant in Microsoft Entra ID as guest users and
then assigned the appropriate licenses. A requirement for finance and
operations apps is that the guest user's company must use Microsoft
Entra ID.
 Manage users and security roles - To use anything other than common
capabilities in finance and operations apps, users must be assigned to
security roles. You can assign users to roles automatically, based on rules
and business data, exclude users from automatic role assignment, or add
users to roles manually.
 Automatically assign users to roles - Based on business data, system
administrators can automatically assign users to roles.
 Exclude users from automatic role assignment - When you remove an
exclusion by resetting the user's status, the user's role is assigned
automatically. However, the user is not immediately assigned to the role
or excluded from the role when you reset the status. Instead, the user is
either assigned to the role or removed from the role the next time that
the rules for automatic role assignment are run.
 Manually assign users to roles - Users who are manually assigned to
security roles must also be manually removed by the administrator. These
users aren't removed from roles by rules for automatic role assignment.
 Manually remove users from roles - Users who are manually assigned
to security roles must also be manually removed by the administrator.
 These users aren't removed from roles by rules for automatic role
assignment.

Batch job manager security role

By assigning a user to the Batch job manager security role, the user has permissions
to copy batch jobs. They can change who can run jobs, and specify the time ranges
during which jobs can execute. The Batch maintain security privilege is part of the
Batch job manager security role. It allows a user to create an unplanned batch job
and grant privileges to other users.

To be able to manage batch jobs, you should assign the user to the batch job
manager security role, and not to the system admin or IT admin security.

Set up and apply segregation of duties

Completed100 pkt.
 5 minutes

Security or policies may require that specific tasks be performed by different users.
You can set up rules to separate tasks that must be performed by different users. This
concept is named segregation of duties. This helps reduce the risk of fraud, and helps
you detect errors or irregularities.

For example, you might not want the same person both to acknowledge the receipt
of goods and to process payment to the vendor. Segregation of duties helps you
reduce the risk of fraud, and it also helps you detect errors or irregularities. You can
also use segregation of duties to enforce internal control policies.

To comply with regulatory requirements, such as those from Sarbanes-Oxley (SOX),

International Financial Reporting Standards (IFRS), and the United States Food and
Drug Administration (FDA), use segregation of duties.

Default duties are provided. The administrator can modify the privileges that are
associated with a duty or create new duties.

Identify and resolve conflicts in segregation of duties

When the definition of a security role or the role assignments of a user violate the
rules, the conflict is logged.
All conflicts must be resolved by the administrator. To identify and resolve conflicts
and verify whether user role assignments comply with new rules for segregation of
duties, you need to run the Verify compliance of user-role assignments process
from System administration > Security > Segregation of duties > Verify
compliance of user-role assignments.

After you select OK, to run the process, a notification displays the results of the
validation. If there is a conflict, you can open the Users page and change the user’s
role assignments.

Conflicts are also logged on the Segregation of duties conflicts page. To run the
verification process as a batch job, select Batch processing, and then set the other
batch parameters. After the batch job runs, you can review the conflicts in
the Segregation of duties conflicts page.

Run security reports

Completed100 pkt.
  8 minutes

Finance and operations apps provides a set of rich security reports to help you
understand the set of security roles running in your environment and the set of users
assigned to each role.

Security reports can be found under System administration > Inquiries > Security.
Let’s get to know some of these security reports.

User role assignments report

The User role assignments report generates a view of the current user role
assignments in your system. By default, the report includes all users with roles
assigned. You can optionally limit the report to a specific set of users by entering a
list of users when generating the report.

On the User role assignments parameters pane, go to Records to include > Filter.
From here you can add or remove filters to the list of users the report will be
generated for. For each user in the report a list of roles is provided, along with any
restrictions at the legal entity or organization level.
Role to user assignments report
The Role to user assignment report provides an aggregation of role assignments.
Expanding a role in the report shows the list of users assigned to the role, and
expanding the user name shows any restrictions the role has applied. The same
method for filtering the set of users can be applied to this report as described for
the User role assignments report.
Security role effective access report
The Security role effective access report provides a view of the effective permissions
for each security role. This report provides a flattened list of permissions grouped by
type across all sub-roles, duties, and privileges contained in the role.

This report may take some time to run. If it is the first time the report has run, or
there could be changes to the role definitions, the Rebuild collection option should
be set to Yes. You can optionally limit the roles to be included in the report by
adding a filter under Records to include.

Expanding a role shows the category of objects the role has access to. Expanding one
of the object types will show a detailed list of each object of that type included in the
role.

Security duty assignments report

The Security duty assignments report provides a view of all the duties contained
within a role. This report can be configured to run on any collection of roles to ensure
that segregation of duties is maintained between roles. By default, the report will
include all roles. To limit the roles included, leverage the filtering provided in
the Records to include section.

Expanding a role in the Security duty assignments report will show each duty
assigned to the role, along with details of the duty.
Stay compliant with user licensing
requirements
Completed100 pkt.

 12 minutes

The licensing requirements for users are determined by the security roles that are
assigned to those users. Security roles are based on a hierarchy of sub-roles, duties,
privileges, and directly referenced securable objects.

The licensing requirements for users are determined at the organization or tenant
level. When using multiple environments and applications, you must analyze
requirements across all environments.

Examples of licensing requirements include None, Team members, Activity,

and Operations.

The Operations licensing requirement indicates that a full user license is required.
Some privileges are unique to a specific full user license and require a base or attach
license before a full user license is assigned to a user.

Roles for selected user FactBox on the Users page

View license requirements for each role in the Roles for selected user FactBox. To
view license requirements, go to System administration > Security configuration >
View permissions and select any security object (role, duty, permission). The largest
license requirement determines the actual licensing requirement for a user.

Available reports under System administration

License reports
You can run the User license counts report to get a count of required licenses per
license type (for example, Team members, Activity, and Operations.

The User license counts report also provides details about each user and the
licensing requirements for each assigned role. Users are listed under the highest
license type. If the license requirement is identified as Operations, you must use the
User license estimator report to figure out the specific full user licensing
requirements.
User license estimator report

If no privileges that require a specific full user license have been assigned to a user,
that user is shown but no specific full user licenses are marked in this report. The user
is compliant with any full user license that is assigned.

If privileges assigned to a user require one or more specific full user licenses, those
licenses are shown in this report. In this case, the user must have a base license for
example for Supply Chain Management and an attach license for all other full user
licenses that are needed (for example, for Finance).

Licensing glossary
Application subscriptions are named user subscriptions that license a user for core
business applications. You can assign different licenses to one user-named
subscription.

Most Dynamics 365 Full user licensing follows the base plus attach model which
provides a cost-effective way for a single user to be licensed for multiple applications.
To license a core business Dynamics 365 application, customers may purchase either
a base or, in many cases, an attach license.

 SKU – stock-keeping unit, unit used for licenses

 Multiplexing - Customers use hardware or software to pool connections,
reroute information, or reduce the number of devices or users that directly
access or use a product. Multiplexing can also include reducing the number of
devices or users a product directly manages. Multiplexing does not reduce the
number of Dynamics 365 licenses that are needed.
 SL - Subscription license used to license access to Microsoft online services

For more information about Dynamics 365 licensing and the Microsoft Dynamics 365
Licensing Guide, see Stay compliant with user licensing requirements

Security diagnostics for task recordings

Completed100 pkt.
 8 minutes

This unit provides information about how to analyze and manage security permission
requirements based on a task recording. Before you complete the steps in this article,
you must have a task recording of the business process that you want to analyze. To
record a business process, see Task recorder resources.

Manage security for a task recording

1. Go to System administration > Security > Security diagnostic for task
recording.
2. Open the task recording from its location. Select Open from this
PC or Open from Lifecycle Services, and then select Close.
3. This will open the Security menu item details page that lists the security
objects required for the process.

Uwaga

The Action and Output menu items are not included in the list.

4. In the User ID field, select a user. If the user does not have permissions
for some menu items, the Missing permissions field will update to Yes.
5. Select Add Reference to see a list of the security objects, including roles,
duties, and privileges that grant the missing permission.
6. Select a security object from the list:

 If Role is selected, select Add role to user. This will open

the Assign users to roles page. For more information,
see Assign users to security roles.
 If Duty is selected, select Add duty to role, select the roles
that the duty should be added to, and then select OK.
 If Privilege is selected, select Add privilege to duties, select
the roles that the duty should be added to, and then
select OK.

Extensible data security policies

Completed

100 pkt.

13 minutes

This unit provides an overview of Extensible Data Security (XDS) policies in finance and operations
apps. XDS allows developers to supplement role-based security by restricting access to table records
based on security policies. The query in the policy applies a filter, and only records that satisfy the
conditions of the filter will be accessible from the restricted tables.

Data security policy components

The data security policy components are:

Constrained tables- The table or tables from which data is filtered or secured. For example, in a policy
that secures access to transactions based on customer, the CustTrans would be an example of a
constrained table.

Primary table - Used to secure the content of the related constrained table. In the example below, the
CustTable table would be the primary table. The primary table must have an explicit relationship to
the constrained tables.

Policy query - Used to secure the constrained tables content using a range condition on the primary
table contents. Only records that are included in the range will be accessible. The range can, for
example, be based on a specific value for Customer.

Context – Controls the conditions under which a policy is applicable. Two main types of contexts that
are available are Role context and Application context:

Role context - Based on the roles that the user is assigned. There are two suboptions for role context:

RoleName – Indicates that the security policy is only applied to the application user assigned to the
role equal to the value of RoleName.

RoleProperty – This value is used in combination with the ContextString property to specify multiple
user roles context. It is applied when the Context String value defined in the Role Property field for
the policy is the same as the ContextString field value for the assigned user roles.

Application context - Applied if the context string set by the application using the XDS::SetContext API
is the same as the value defined in the Context String field for the policy. In the Application Object
Tree (AOT), policies and their components are displayed under Security > Policies.

Important considerations

The policy query is added to the WHERE clause, or ON clause, on SELECT, UPDATE, DELETE and INSERT
operations involving the specified constrained tables. Unless carefully designed and tested, policy
queries can have a significant performance impact. Therefore, make sure to follow simple but
important guidelines when developing an extensible data security policy. For more information, see
Developing Extensible Data Security Policies (White paper).

When two or more security policies apply, the intersection (not the union) of the records that are
included by each policy are the only records that can be accessed. This means that a record must
satisfy all the applicable security policies before access to the record is allowed.

The following video is a demonstration of creating and implementing an XDS policy.

Additional resources

For information about how to debug policies, create more advanced policies, including chaining of
restricted tables, table relations based on expressions, and much more please refer to these
resources:

Create a security policy

Developing Extensible Data Security Policies (white paper)

Securing Data by Dimension Value by using Extensible Data Security (White paper)

Extensible Data Security examples

Extensible Data Security (XDS) Framework in D365FO

Exercise - Import a user and assign

security role
Completed100 pkt.
 5 minutes

The HR department of company USMF has requested access to finance and

operations apps for a new hired employee as an accounts receivable clerk. The active
directory user account has already been created as part of onboarding process.

You must import a new hired employee and assign the default the company
to USMF and associate the accounts receivable clerk role.

1. Go to System administration > Users > Users.

2. Select Import users in the Action Pane.
3. From the list of aliases, select your desired alias to be imported.
4. Select Import users.
5. Select Close.
6. In the Users list page, verify the new user has been imported successfully.
7. Select the User ID link.
8. Select Assign roles.
9. In the list, find and select accounts receivable clerk.
10. Select OK.
11. Select Save.

Lab - Work with security

Completed100 pkt.
30 minutes
Ukończenie tej sekcji wymaga skorzystania z maszyny wirtualnej.
Tryb maszyny wirtualnej zapewnia bezpłatne, oparte na sieci Web środowisko
maszyny wirtualnej umożliwiające wykonanie czynności podanych w tej lekcji.

Firma Microsoft udostępnia to środowisko laboratoryjne i powiązaną zawartość do

celów edukacyjnych. Wszystkie przedstawione informacje są własnością firmy
Microsoft i są przeznaczone wyłącznie do nauki produktów i usług w tym module
usługi Microsoft Learn.

Uruchom tryb maszyny wirtualnej

Read this first - before you start the lab!

Ważne

For this lab, you CANNOT sign in with your own credentials. Use the following steps
to sign in to your lab environment with the correct credentials.

1. Ensure that you are signed in to Microsoft Learn.

2. Select Launch VM mode or Sign in to launch VM mode in this unit.
3. In the Resources tab on the lab side bar, select the T icon next
to Password in the MININT box, to have the administrator password for
the Virtual Machine entered for you.

4. Select Enter.
5. Microsoft Edge will open. Wait for it to navigate to the Sign in page for
finance and operations.
6. On the Microsoft Sign in page in finance and operations, place your
mouse cursor into the Username field.
7. On the Resources tab of the lab side bar, below the Azure
portal heading, select the T icon next to Username, then press Enter.
8. Your mouse cursor will now be in the Password page.
9. On the Resources tab of the lab side bar, below the Azure
portal heading, select the T icon next to select Password, then
press Enter.

10. Don't stay signed in or store the password on the virtual machine.
11. Select Accept in the Permissions requested page.
 12. To see the lab instructions, select the Instructions tab on the lab side
bar.

You can now begin your work on this lab.

Scenario - Create a new user and assign a security

role
The HR department of company USMF has requested access to finance and
operations apps for a new hired employee as an accounts payable clerk.

You must create a new user ID for the new hired employee and assign the default the
company to USMF and associate the accounts payable clerk role.
 1. Go to System administration > Users > Users.
2. Select New.
3. In the User ID field, enter a unique identifier for the user. A user ID is
required.
4. In the User name field, enter John.
5. In the Company field, select the drop-down button to open the lookup.
6. In the list, select USMF.
7. In the Email field, enter "john@contoso.com".
8. Select Assign roles in the User's roles section.
9. In the list, find and select Accounts payable clerk.
10. Select OK.
11. Select Save.

Scenario - Import users in bulk as a batch job

The HR department of company USMF is hiring new employees for different roles in
the next few weeks. The active directory user accounts will be created as part of
onboarding process. You must import many users from Microsoft Entra ID into
finance and operations apps.

1. Go to System administration > Users > Users.

2. Select Batch import.
3. Expand the Run in the background section.
4. Select Yes in the Batch processing field.
5. In the Task description field, type a value.
6. In the Batch group field, enter or select a value, such as 'DOMBatch'.
7. Select Yes in the Private field.
8. Select Yes in the Critical Job field.
9. In the Monitoring category field, select an option, such as 'Integration'.
10. Select OK.
11. After the batch job is completed, all new users from active directory will
be imported in finance and operations apps.
12. Close the page.

Scenario - Assign users to security roles dynamically

The HR department of USMF has requested to dynamically assign users to the
Accounting supervisor role based on a criterion defined by HR department. Associate
the Accounting supervisor role based on the rule defined by the HR department to
the selected employees.

1. Go to System administration > Security > Assign users to roles.

 2. In the tree, select Accounting supervisor.
3. Select Add rule to open the drop dialog.
4. In the list, find and select the wanted query rule, such as
'FMDynamicRoleAssignmentWorkerTitle'.
5. In the list, select the link in the selected row.
6. Select Edit query. You can change the query as you desire.
7. Select OK.
8. Close the page.

Scenario - Exclude users from a role assignment

The HR department of USMF has requested to remove access for the Accounts
receivable clerk role in finance and operations apps for an employee who has
changed role.

1. Go to System administration > Security > Assign users to roles.

2. In the tree, select Accounts receivable clerk.
3. Select Manually assign / exclude users.
4. In the list, select a user.
5. Select Exclude from role to exclude the selected users from the role.
6. To remove exclusions, select the users that you want to remove
exclusions for, and then select Reset status.
7. Close the page.

Scenario - Set up segregation of duties

The HR department of USMF has requested a rule for segregation of duties for
the Access benefits workspace, and the Approve production journal. You must
create the rule in finance and operations apps.

Complete the following procedure to create a rule. You must be a system

administrator to complete the procedure. The demo data company used to create
this procedure is DAT.

1. Switch to companyDAT.
2. Go to System administration > Security > Segregation of
duties > Segregation of duties rules.
3. Select New.
4. In the Name field, enter a name for the rule.
5. In the First duty field, select the drop-down button to open the lookup.
6. In the list, find and select the first duty that is controlled by the
rule, Access benefits workspace.
 7. In the Second duty field, select the drop-down button to open the
lookup.
8. In the list, find and select the second duty that is controlled by the
rule, Approve production journal.
9. In the Severity field, select the severity of the risk that occurs when the
same user or role performs both duties.
10. In the Security risk field, enter a description of the security risk.
11. In the Security mitigation field, type a value.
12. Enter a description of the actions that you take to mitigate the security
risk.
13. For example, you can mitigate the risk by conducting more detailed
reviews of the process, by conducting a monthly managerial review, or by
sharing resources with other departments.
14. Select Save.
15. Close the page.

Close the lab environment

1. Select Done in the Instructions pane in the lab side bar.
2. In the Lab is complete window, select Continue, and then
select Leave to return to the next unit in the module.

Check your knowledge

Completed200 pkt.
 6 minutes

Answer the following questions to see what you've

learned.
1.

Which of the following statements best describes role-based security in finance

and operations apps?

A duty can be assigned to only one security role.

A duty can be assigned to multiple security roles.
A privilege can be assigned to only one security role.
Access is granted only to security roles.
Access is granted only to security roles, not to individual users.
A security role cannot be defined as a combination of other security roles.
2.

Which one of the following security pages in finance and operations apps is
used to manage privileges?

Assign users to role

The Assign users to role page does not have the option to manage privileges.
Security configuration
The Security configuration page enables administrators to manage privileges.
External roles
Dormant user security accounts
3.

Which of the following security reports in finance and operations apps provides
a view of the effective permissions for each security role?

User role assignments

The User role assignments report generates a view of the current user role
assignments in your system.
Role to user assignments
Security role effective access
The Security role effective access report provides a view of the effective
permissions for each security role.
Security duty assignments
4.

To comply with regulatory requirements, such as those from Sarbanes-Oxley

(SOX) and International Financial Reporting Standards (IFRS), which page
should you use?

Segregation of duties
The Segregation of duties page helps finance and operations apps to comply
with regulatory requirements, such as those from Sarbanes-Oxley (SOX),
International Financial Reporting Standards (IFRS), and United States Food and
Drug Administration (FDA).
External roles
Assign users to role
Dormant user security accounts

Introduction
Completed100 pkt.
  8 minutes

This module focuses on your integration strategy and how the Integration workshop
will help verify that the project's integration plans are comprehensive and will support
initial implementation and long-term needs. The workshop's goal is to evaluate the
proposed integration plan and provide feedback and recommendations that
highlight technical risks and issues and identify best practices.

The Integration workshop should be scheduled and completed during the

implementation phase of the project. You can also download examples of
templates for this and other workshops.

What integration means

Integration is the connecting of one or more parts or components of systems to
create a more unified experience or to ensure a more consistent outcome of a
process. Integration allows the use of existing services, internal and external, without
having to rebuild or migrate existing functionality.

Different types of integrations that you will use on projects include:

 Process integration - Multiple disparate systems, and each system is

part of an overall business function.
 User interface integration - Visibility of data from one or more systems,
without bringing records of data into the system.
 Data integration - Combining data from different sources and
presenting the user with a unified view.
The actual implementation of integrations can use many different technical
approaches, including user interface (UI), file, APIs, Microsoft Power Platform,
connectors, and other external ETL tools. Some integrations will also be
configurations of prebuilt integrations that are supported by the platform and
Microsoft Dynamics 365 applications. Each approach contains factors that you should
be aware of as part of the Integration workshop review. These integrations will be
covered in detail later.

Understanding the reasons for the integration and the problem that you're trying to
solve can help you establish the importance of the integration and the level of risk
associated with it. For each integration, make sure that you are clear about what you
expect to happen if an integration is unavailable and how you anticipate handling
failures.

Integrations can be grouped as essential or convenient. Essential integrations are key

to your project's success and ongoing operation. They often involve ensuring data
integrity or participation in larger organizational business processes. They can also
integrate services that augment the functionality of your core system and handle
important logic. For example, an external service might be used to conduct credit
scoring to determine whether credit will be issued for an order.

Convenience integrations help make the process easier for users or help improve
their productivity. For example, a convenience integration might prevent a user from
having to go into a separate application, which allows them to run the integration
from within the Dynamics 365 application. While convenience integrations help save
time, they also provide an alternate path that users can take to complete the task if
the system is down. Mostly, your effort for the Integration workshop should focus on
the essential integrations that are critical to your project success.

Similar to all workshops in Success by Design, not every aspect of the Integration
workshop will apply to every project. However, it is vital to have a plan and process
for managing your idea to deployment process.

Timing of the Integration design review

The Solution blueprint review should always precede the Integration design review.
Before delving into integration design-related topics, you need to understand the
solution, which will help you determine how integrations will play a part in the
solution.

The Integration design review does not provide an overview of how to integrate with
Dynamics 365. For that purpose, several Tech Talks have been developed that discuss
and exemplify the usage of integration tools and patterns.

The Integration design review workshop should be conducted when the design is
near completion, or already completed, and when a solid understanding of how
various apps will be integrated while forming the full solution has been reached.

Ukończono moduł:

Integration design review workshop

overview
Completed100 pkt.
 15 minutes

Integration design review is a workshop that can be conducted remotely, typically in

a single session for 90 to 120 minutes.

Integration strategy
Integration strategy considers the design of communication and connectivity
between the various components of the solution. This strategy includes the
application interfaces, the middleware, and the processes that are required to
manage the operation of the integrations. This topic will focus on answering
questions, such as:

 Are plans for integrations with other Dynamics 365 applications in place?
If so, are they aligned with standard Microsoft integration patterns, such
as dual-write?
 Who is responsible for delivering the integration scope?
 Where and how is message-format transformation being handled?
 Would the same message-format transformation approach apply to
existing and new systems?
 Has the integration architecture been defined? If so, does it reflect the
planned solution landscape?

Integration patterns
Integration patterns consider the patterns that are used for inbound and outbound
communication and the interface models that are used for each. This assessment
includes standard interface choices, including real time (synchronous), batch data API
(asynchronous), and business events (event-based) interfaces. It also covers standard
integration options, including dual-write and bring-your-own-database integration.
This topic will focus on answering questions, such as:

 Have you defined and mapped integration patterns for all scenarios? If
so, do they fall under standard patterns?
 Is authentication done through a registered Microsoft Entra ID
application (SPN) or normal user account?
 Do you have real-time integrations with external systems that could
result in UI thread blocking?
 Is real-time integration used for high volumes? If so, can you share the
peak hourly volumes for top integrations?
 Does the customer have high-volume integration scenarios that they
plan to use dual-write for?
 When the endpoint goes down, how are retries handled?

Middleware
Middleware considers the aspects of middleware usage within the integration
landscape and how it will be used for transformation, communication, error handling,
retries, and monitoring and alerting. However, the workshop is not intended for
discussing or validating the internal design of the middleware of choice. This topic
focuses on answering questions, such as:
  Are you planning to use middleware for integrations? If so, what's the
middleware scope for this project?
 How are you planning to mitigate errors and provide logging?
 Is transformation done in the middleware level? If so, to what extent?
 Are you planning to use Azure services for integration? If so, have you
planned to host the Azure services in the same data center as your
Dynamics 365 environments?
 Are you using Microsoft Power Platform connectors for your integrations,
or do you plan on using custom connectors?
 Do integrations with on-premises or line-of-business applications exist?

Business critical integration scenarios

Business critical integration scenarios cover all integrations that are critical to
continuous operation of the solution. This topic focuses on answering questions, such
as:

 What happens when integrated systems are offline?

 Are built-in retry mechanisms and user notifications in place?
 Can integrations automatically recover from failures and network
connectivity issues, or is human intervention required to recover the
integrations?

Monitoring and alerting

The monitoring and alerting process covers the design within your overall solution
architecture. This topic focuses on answering questions, such as:

 What is the overall approach to monitoring and alerting for integrations?

 Are you planning to use tools for monitoring and alerting? Are you
familiar with the analytics that are available in Microsoft Power Platform
admin center?
 What is your approach to error handling?

Microsoft 365
Microsoft 365 covers integrations with other Microsoft products and cloud services.
This topic focuses on answering questions, such as:

 Are you integrating with SharePoint on-premises? If so, how are you
planning to complete this task?
  Are you planning to integrate with Exchange on-premises for server-side
sync? Have you considered the requirements and limitations for this
integration versus integration with Exchange Online?
 Are you planning integration with Microsoft Teams? Are you aware of the
capabilities, limitations, and additional considerations?
 Are you planning a collaboration structure before enabling the
collaboration between Dynamics 365 and Teams?

Ukończono moduł:

Prepare for the Integration design

review
Completed100 pkt.
 10 minutes

The Integration design review workshop typically takes approximately 1-2 hours to
conduct. The time might vary based on the level of detail that is available for review.
The solution architect will work with the implementation team leadership to plan the
workshop based on the specifics of the solution that are being reviewed.

Prior to the Integration design review workshop, participants should be as familiar as

possible with the structure of the workshop and the types of topics and prerequisites
that will be covered. The solution architect will provide an agenda with topics and
prerequisites ahead of the workshop.

The Integration design review is essentially a discussion; it is not intended to be a

questionnaire that can be completed and reviewed in an offline mode. While the
prerequisites are defined and provided in advance, it is not possible to encapsulate
the breadth of directions in which the conversation might lead.

Porada

We recommend that you use diagrams and visual representations to provide high-
level summaries in the implementation, wherever possible. These diagrams, charts,
and graphs provide a ready means of communication across the team and with
executives about plans and designs.

Integration design review participants

The Integration design review is an excellent chance to provide a baseline for the core
project team on the overall integration strategy. Having the broader team present in
the workshop can be a helpful way to provide context to the team. In some cases,
due to the size of the implementation team, it might be necessary to limit
participation in the workshop to core members of the implementation team. With
that in mind, you should consider the following guidelines:

 The workshop should be attended by representatives from the customer

organization and the partner organization that is assisting with the
implementation. Part of the review's value is providing common
information about the solution across all involved parties.
 The workshop should include the architects and integration leads from
the customer and the partner organization. If the customer doesn't have
a solution architect role in their organization, then the responsible
technical stakeholder(s) should be involved. If the partner organization
doesn't have a designated solution architect who is responsible for the
implementation, then the equivalent delivery lead, functional lead, or
technical architects should be involved.
 In some cases, it might be necessary to bring specific resources for
specific topics, which can be accommodated based on the breakdown of
the solution in the workshop agenda.

Ukończono moduł:

Conduct the Integration design review

Completed100 pkt.
 10 minutes

The Integration design review workshop will be facilitated by the solution architect,
but the expectation is that the implementation team will present the integration
design information. Each section of the agenda should be assigned an owner within
the implementation team. At the beginning of each section, that owner should
present an overview or summary of the scope and plans, including designs that apply
to that aspect of the integration design. When all topics in the planned agenda have
been discussed, the remainder of the time should be reserved for questions and
answers with the solution architect.

During each session, you can expect that discussion about the scope and approach
will occur. As part of that expectation, the solution architect might provide guidance
directly within the meeting. However, these sessions are not intended to be design
sessions but rather review sessions. The provided feedback might alter the current
plan or design, but the detailed work in those areas will be carried out by the
implementation team after the workshop.

Integration design review outputs

The output of the Integration design review workshop is a findings document. This
findings document is a response to information that has been provided as
preparation for the workshop or during the workshop. These findings will generally
be one of three types:

 Assertions – Assertions relate to specific aspects of the integration

design that the solution architect wants to call out as significant. These
assertions are factors that might not represent a specific risk or issue but
are foundational to the integration design and should be noted because,
if changed, they will have significant impact. These assertions might
relate to specific scope items, design aspects of the integration, or
implementation approach or technique.
 Risks – Risks represent an aspect of the integration design or
implementation approach that constitute a risk that should be tracked on
the project. These risks could relate to existing plans, approaches, or
designs that have an observed potential for negative outcomes. They
could also be related to areas of the integration that have not been
adequately explored yet, and as such, represent a risk that something
unexpected could come up. These findings will be accompanied by a
statement of what is viewed as a risk along with recommended
mitigation steps.
 Issues – Issues represent an aspect of the integration design or
implementation approach that constitute an issue that is negatively
impacting the implementation, or if not corrected, will have a negative
impact in the future. These findings will be accompanied by a statement
of what the impact is or will be, along with recommended resolution
steps.

The findings document will be distributed to the customer and partner organizations,
and a review meeting will be held to review the findings in detail. The document will
go to the implementation leadership and executive sponsors in both organizations. In
some cases, these findings documents can be lengthy, in which case, an executive
summary that highlights key and critical findings is provided for better consumption
by executives.

Ukończono moduł:
Integration design review workshop
follow-up
Completed100 pkt.
 3 minutes

After the Integration design review workshop has been conducted and the findings
have been reviewed, those items that have been identified as risks and issues, and
their associated action items for mitigation and resolution, will be managed to
completion as part of the overall engagement.

Identified issues will often have an impact on the ability to successfully go live. These
issues will need to be resolved prior to the go-live readiness assessment and the
deployment of a production environment.

Risks and their associated recommended mitigations can be managed according to

the overall strategy of the project, but they will be monitored throughout the project.
Risks that are not mitigated might be realized later as issues that could also affect the
go live.

Ukończono moduł:
Odblokuj osiągnięcie

Check your knowledge

Completed200 pkt.
 6 minutes

Answer the following questions to see what you've

learned.
1.

During which phase of a project should the Integration workshop be scheduled?

Initiate
The Integration workshop should be scheduled and completed during the
implementation phase of the project.
Implement
The Integration workshop should be scheduled and completed during the
implementation phase of the project.
Prepare
Operate
2.

Which of the following options isn't a type of integration that you can use on
projects?

Process integration
Different types of integrations that you can use on projects include process
integration, user interface integration, and data integration.
User interface integration
Model integration
Model integration isn't an integration type. Different types of integrations that
you can use on projects include process integration, user interface integration,
and data integration.
Data integration

Introduction
Completed100 pkt.
 4 minutes

The overall goal of the Success by Design framework is to ensure a successful

customer outcome for each implementation. As part of Success by Design, the Dual-
write implementation workshop helps accomplish this overall goal by focusing on the
following objectives:

 Drive understanding on how dual-write will be used in the customer

scenario. The Dual-write implementation workshop is designed to drive a
conversation about how different apps will integrate through dual-write.
 Identification of risks and issues. By taking a broad but high-level look at
the solution, it is possible to identify issues and risks with the solution
design or implementation approach that will negatively impact the
outcome.
 Identification or discussion about gaps. Identify areas where dual-write
might not be a good fit for a project, and then discuss identified gaps
and alignment with the dual-write roadmap.
Timing of the workshop
The Dual-write implementation workshop should always be preceded by the solution
blueprint. Before you consider dual-write related topics, it's imperative that you
understand the solution as a whole, which will help you understand how dual-write
will play a part in the solution.

The goal of the Dual-write implementation workshop isn't to provide an overview on

how dual-write works. For that purpose, the FastTrack team has created several Tech
Talks that discuss and exemplify the usage of dual-write. These resources can be used
in addition to the available documentation.

The Dual-write implementation workshop should be conducted when the design is

near or already completed and when you have a solid understanding on how dual-
write will be used to integrate data between different apps.

Dual-write implementation workshop

overview
Completed100 pkt.
 10 minutes

The Dual-write implementation workshop is conducted remotely. It should include

high-level aspects of the Dual-write implementation workshop and provide a
sampling of the types of questions that are covered in each section.

Application strategy
Application strategy considers the various apps, services, and platforms that will make
up the overall solution. This topic focuses on answering questions, such as:

 Which Microsoft Dynamics 365 applications or services will be deployed

as part of the solution?
 Which, if any, of the applications are already live?
 What will be the approach to integrate across different apps, including
data integration, dual-write, Microsoft Azure Logic Apps, and more?
 Will the out-of-the-box maps or custom-built maps be used?
 What is the estimated go-live timeline for each app?
 Is a trial being used during the build phase?
Business process strategy
Business process strategy considers the underlying business processes (the
functionality) that will be implemented on the Dynamics 365 platform as part of the
solution and how they will be used to drive the overall solution design. This topic
focuses on answering questions, such as:

 What are the top processes in scope for the implementation?

 What is currently known about the general fit for the processes within the
Dynamics 365 applications?
 How are processes being managed within the implementation, and how
do they relate to subsequent areas of the solution such as user stories,
requirements, test cases, and training?

Based on the processes that are in scope, the solution architect who is conducting the
review might ask a series of feature-related questions to gauge complexity or
understand potential risks or opportunities to optimize the solution based on the
future product roadmap.

Integration strategy
Integration strategy considers the design of communication and connectivity
between the various components of the solution. Within this topic, you will try to
answer questions, such as:

 How is the number sequencing handled for each of the integrations

(table to table)?
 Will the filtering of source data be required?
 What are the integration triggers?
 Will high volumes of data be used?
 What are the business processes that will trigger a bulk creation or
update to integrated records in different applications?

Environment and capacity strategy

The deployment architecture considers those aspects of the solution that are related
to cloud infrastructure, instances, and the processes that are involved in operating the
cloud solution. Within this topic, you will try to answer questions, such as:

 How many production environments will be deployed, and what are the
factors that went into that decision?
 Are trial environments used during build?
  Will the various apps be deployed under the same tenant?
 Will the various apps be deployed in the same region?
 What are the data sovereignty requirements?
 Do you have alignment of your release process across the different apps?
 What is the monitoring plan for dual-write integration status and errors?
 What are the plans to monitor capacity requirements for data
redundancy across different data repositories?

Data strategy
Data strategy considers the design of the data within the solution and the design for
how legacy data will be migrated to the solution. Within this topic, you will try to
answer questions, such as:

 What will be the approach to migrate data?

 Is the initial sync feature planned to be used as part of data migration?
 Is the responsibility matrix established for data migration activities?
 What historical data will be migrated and synched?
 Will more data migration activities occur post initial go live?
 What is the cutover approach for data migration?

Test strategy
Test strategy covers the various aspects of the implementation that deal with
validating that the implemented solution works as defined and will meet the business
need. Within this topic, you will try to answer questions, such as:

 Does your test plan include testing dual-write synchronization across all
apps?
 Does the test plan focus on performance for business processes (for
example, prospect to cash)?
 Does the test plan include testing planned and unplanned
outages/maintenance of different apps?
 What are the desired performance metrics for dual-write integration,
especially for key scenarios?
 Who is responsible for reviewing metrics after each iteration and are
these metrics included in the design?
 What are the expected service levels, such as the time that it takes for a
record to synchronize across apps?

Security strategy
Security strategy considers the design of security within the Dynamics 365
components of the solution and the other Microsoft Azure and external solution
components. Within this topic, you will try to answer questions, such as:

 Have you tested the access to data across different apps?

 Does your test plan focus on the security aspect as well?
 Is the security model aligned across different apps?
 What is the plan to align the security model and make it scalable for
future changes?

Gaps and risks

Gaps and risks detail all identified gaps and risks, including questions that might exist
from the implementation team.

Ukończono moduł:

Prepare for the workshop

Completed100 pkt.
 3 minutes

Typically, the Dual-write implementation workshop takes 1-2 hours to conduct. The
time might vary based on the level of detail that is available for review and the
breadth of the overall solution. The solution architect will work with the
implementation team leadership to plan the workshop based on the specifics of the
solution that is being reviewed.

Before you schedule the workshop, make sure that the implementation team has a
good understanding of dual-write and how it is planned to be used.

Uwaga

Essentially, the Dual-write implementation workshop is a discussion; it's not intended

to be a questionnaire that can be completed and reviewed in an offline mode. While
the prerequisites are defined and provided in advance, it's not possible to
encapsulate the breadth of directions in which the conversation might lead.
Ukończono moduł:

Workshop implementation and follow-

up
Completed100 pkt.
 8 minutes

The following sections describe how to implement the Dual-write implementation

workshop and then conduct follow-up sessions for more in-depth information.

Dual-write implementation workshop review

participants
The Dual-write implementation workshop is an excellent chance to provide a baseline
for the core project team on the overall dual-write usage. Having the broader team
present in the workshop can be a helpful way to provide context to the team. In some
cases, due to the size of the implementation team, it might be necessary to limit the
participation in the workshop to core members of the implementation team. With
that in mind, you should consider the following guidelines:

 The workshop should be attended by representatives from the customer

organization and the organization that is completing the implementation.
Part of the review's value is providing a common understanding of the
solution across all involved parties.
 The workshop should include the project manager and solution architects
from the customer and the implementation team. If the customer doesn't
have the solution architect role in their organization, then the responsible
technical stakeholder(s) should be involved. If the implementation team
doesn't have a designated solution architect who is responsible for the
project, then the equivalent delivery lead, functional lead, or technical
architects should be involved.
 In some cases, it might be necessary to bring in specific resources for
specific topics, which can be accommodated based on the breakdown of
the solution in the workshop agenda.

Implement the Dual-write implementation workshop

The Dual-write implementation workshop will be facilitated by the solution architect,
but the expectation is that the implementation team will present the information.
Each section of the agenda should be assigned an owner within the implementation
team. At the beginning of the session, the owner should present an overview or
summary of the scope and plans, including the designs that apply to that aspect of
the solution. The team should plan for that summary to take between 25 to 50
percent of the allotted time, but no more. The remainder of the time should be
reserved for questions and answers with the solution architect.

Workshop review outputs

The output of the Dual-write implementation workshop is a findings document. This
findings document is a response to information that has been provided as
preparation for the workshop or during the workshop. Generally, these findings will
be of three types:

 Assertions - These findings relate to specific aspects of the solution that

the solution architect wants to call out as architecturally significant. These
assertions are factors that might not represent a specific risk or issue but
are foundational to the solution and should be noted because, if
changed, they will have significant impact. These assertions might relate
to specific scope items, design aspects of the solution architecture, or
implementation approach or technique.
 Risks - These findings represent an aspect of the solution or
implementation approach that constitute a risk that should be tracked on
the project. These risks could relate to existing plans, approaches, or
designs that have an observed potential for negative outcomes. They
could also be related to areas of the solution that have not been
adequately explored yet, and as such, represent a risk that something
unexpected could come up. These findings will be accompanied by a
statement of what is viewed as a risk, along with recommended
mitigation steps.
 Issues - These findings represent an aspect of the solution or
implementation approach that constitute an issue that is negatively
impacting the implementation, or if not corrected, will have a negative
impact in the future. These findings will be accompanied by a statement
of what the impact is or will be, along with recommended resolution
steps.

The findings document will be distributed to the customer and partner organizations,
and a meeting will be held to review the findings in detail. The document will go to
the implementation leadership and executive sponsors in both organizations. In some
cases, these findings documents can be lengthy, in which case, an executive summary
that highlights key and critical findings is provided for better consumption by
executives.
Workshop follow-up
After the Dual-write implementation workshop has been conducted and the findings
have been reviewed, those items that have been identified as risks and issues, and
their associated action items for mitigation and resolution, will be managed to
completion as part of the overall engagement.

Identified issues will often have an impact on the ability to successfully go live. These
issues will need to be resolved prior to the go-live readiness assessment and the
deployment of a production environment.

Risks and their associated recommended mitigations can be managed according to

the overall strategy of the project, but they will be monitored throughout the project.
Risks that are not mitigated might be realized later as issues that could also affect the
go live.

Follow-up and in-depth workshops need to be supported by the project team as

recommended. These follow-up workshops can affect risk and issue areas that are
identified within the Dual-write implementation workshop, and they can also affect
areas that require the next level of details due to complexity.

Answer the following questions to see what you've

learned.
1.

At what point in a project should the Dual-write implementation workshop

occur?

Prior to the Solution blueprint review

The Dual-write implementation workshop should be conducted when the
design is near completion.
At go-live planning
During the performance design sessions
When design is nearly complete
The Dual-write implementation workshop should be conducted when the
design is nearly completed, or completed, and when presenters have a solid
understanding of how dual-write will be used to integrate data between
different apps.
2.
Which one of the following personas should facilitate the Dual-write
implementation workshop?

Solution architect
The Dual-write implementation workshop will be facilitated by the solution
architect.
Data analyst
Customer lead
Account representative
3.

Which one of the following options is not a purpose of the Dual-write

implementation workshop?

Drive understanding on how dual-write will be used in the customer scenario

The Dual-write implementation workshop is designed to drive a conversation
about how different apps will integrate through dual-write.
Identification of risks and issues
Identification or discussion about gaps
Provide an overview on how dual-write works
The goal of the Dual-write implementation workshop isn’t designed to provide
an overview on how dual-write works. For that purpose, the FastTrack team has
created several Tech Talks that discuss and exemplify the usage of dual-write.

Introduction
Completed100 pkt.
 5 minutes

The Solution performance workshop will also emphasize the importance of having
performance goals defined and having the correct focus on performance and
performance testing during the entire project life cycle.

The goal of the overall Success by Design framework is to ensure a successful

customer outcome for each implementation.

The Solution performance workshop has the following goals:

 Evaluate planning and readiness activities for conducting meaningful

performance testing.
 Collect requirements and design for the project that might ultimately
impact performance or areas that are already identified as problem areas.
 Define targeted sections of the solution. Enterprise solutions tend to be
extensive. The intent of the workshop isn’t to cover every feature of your
 solution; rather, it will target the areas that will provide the most impact
to the user.
 Define clear goals and objectives and use the correct tools and processes
for implementing performance testing.

Ukończono moduł:

Solution performance workshop topics

Completed100 pkt.
 10 minutes

The Solution performance workshop can be conducted in person because it’s

typically a single workshop that covers all required topics. Additionally, you can
conduct the workshop remotely. If done remotely, the workshop can be divided into
several sessions over several days.

The following sections highlight the topics that the Solution performance workshop
covers, including a sampling of the types of questions that are covered in each.

Project plan
The project plan section covers the overall planning that is in place for activities to
address performance. This topic focuses on answering questions, such as:

 What is the plan, and how often will the project implement performance
testing?
 What is the plan for performance testing during different stages of the
project life cycle?
 Are experienced resources available and tasked to support the
performance test implementation?

Solution design - Volumes

Volumes will cover the impact of transaction volumes and integration on the solution.
Within this topic, you will collect information in the following areas:

 The expected volume of transactions for various types of business

processes.
 Types of integrations and methods that are used to pass data.
  Licensing and service protection limits that have been considered.

Solution design - Geographic location strategy

Geo location strategy focuses on the environmental factors of a solution and its
performance. The location of workloads and users can have an impact on the solution
performance. This topic focuses on answering questions, such as:

 In which geo location(s) will the solution be hosted?

 Are you transferring data across geo locations?
 Where are the users located?

Solution design - Key business scenarios

Because solutions tend to cover a wide spectrum of business functions, the intent of
this section is to focus on the key business scenarios that show where performance
will have the most impact on users. Within the scope of key business scenarios, this
section will cover planned configuration/customizations.

This topic explores the techniques and tools that the project team uses that might
impact performance, including:

 Identifying methods and techniques that might impact performance

output.
 Ensuring that developers are following best practices for
configuration/customization.
 Ensuring that the project team uses the available tools to check for
performance and use of best practices.

Performance testing
Performance testing becomes a key component in collecting actionable insights into
identifying problematic areas and addressing them. Planning and implementing
performance testing are critical activities in ensuring that solution performance is
optimal.

This topic focuses on answering questions, such as:

 Are clear performance goals and objectives defined?

 What are the KPI and non-functional requirements?
  What is the performance testing strategy as part of the overall testing
strategy?
 What tools will be used for testing?
 What environment(s) and data will be used for testing?

Risks, Q&A, and next steps

In this section, a summary of the identified risks, outstanding questions, and next
steps will be captured. The information in this section will lead to tasks that will be
completed by the project team to address outstanding topics.

Ukończono moduł:

Define performance benchmarks and

success criteria
Completed100 pkt.
 10 minutes

A performance benchmark is a metric or point of reference that gives evidence that

the solution being built during implementation can achieve business performance
objectives and constraints.

Performance benchmarks confirm that the solution can process the targeted
transactions/user’s volume within an acceptable duration/response time with a
specific data starting point.

Performance benchmarks answer questions that are related to handling real-life

workloads and thousands of users concurrently. They also answer questions about
performance and scalability in years after go-live, performance in rollouts to other
countries after the first go-live, and so on.

Develop a performance tuning process to meet

performance objectives
Performance testing is an iterative approach and requires a defined process that
should have a life cycle and clear steps. Some tests need to be run in a loop until the
required solution is achieved. Make sure that you're clear on performance goals and
prioritize tuning scenarios.
The typical performance tuning process includes the following steps:

1. Narrow it down - This step is the first for each scenario. Find out where
you lose the most time and then focus your efforts on that point. For
example, validate whether few or many calls exist, validate whether
process is running or waiting, and so on.
2. Troubleshoot - Analyze why that part of the process is slow. It could be
configuration, looping, row-by-row operations, or resource contention,
such as locking or single threading.
3. Solution - create a fix - Consider lead time for Microsoft or
partner/provider hotfixes. You might be able to fix by extension.
4. Evaluate it – Validate that the performance goal has been met.
5. Test the new solution.
6. Repeat or deploy the solution.

Sample performance benchmark activities RACI

Part of the strategy definition is to define roles and responsibilities. Samples of the
performance benchmark activities and responsibilities between customer and
implementation partner are included in the following table.

RACI abbreviations:

 R - Responsible
 A - Accountable
 C - Consulted
 I - Informed
Rozwiń tabelę
ACTIVITY PARTNER (sample) C
Define the target/projected business goals I A
Define the detailed benchmark scenarios RIC A
Take task recordings and document the reproduction steps I A
Provide the environment artifacts (code build and database to use) I A
Build the benchmark environment R A
Create test scripts and data scripts R A
Run the performance benchmark R A
Deliver the performance benchmark report R A
If bugs occur in the standard solution, open a support request to Microsoft C A

Performance benchmarks outcomes

Performance benchmarks will confirm that the solution will perform the critical
business scenarios as expected. Key benchmark deliverables include performance
benchmark report, issues detected/fixed in each iteration, and optimizations
performed in each iteration.

Ukończono moduł:

Timing of the Solution performance

review
Completed100 pkt.
 8 minutes

Frequently, addressing solution performance becomes a reactionary activity after a

solution goes into production and users are experiencing poor performance. In
reality, solution performance needs to be planned and implemented at every stage of
the project life cycle. Activities to address performance reviews need to be built into
the design, development, and testing phases. To be well prepared, we recommend
that you schedule the solution performance workshop early in the implementation
phase.

The following questions and answers are typical regarding the Solution performance
review:

Question: How can we review performance aspects of a solution when we haven’t

started (or only now started) the design and development of the solution?

Answer: Most implementations begin with a planned timeline, or at least a target go-
live date, and a defined budget. These factors should be based, at a minimum, on a
conceptual solution and approach. Performance is impacted by more than code.
Having a scalable design is a key starting point. Environmental factors can also impact
performance. Defining your environment strategy is a first step that you should take
before you start to build. The Solution performance workshop can be an important
tool to help you make some of these key decisions early in the project.

Question: We haven’t made decisions on the ways to implement the solution. Would
it make more sense to wait until development is complete to conduct the Solution
performance workshop?
Answer: If needed, the Solution performance workshop can be implemented as an
iterative process. The benefit of starting this activity early is that the project team will
have awareness of best practices, techniques, and resources that they can use as they
design and develop the solution. Having knowledge and awareness early will help the
team build the solution with performance in mind instead of having to return to fix
issues after completion.

Ukończono moduł:

Prepare for the workshop

Completed100 pkt.
 15 minutes

Typically, the Solution performance workshop takes approximately 2-4 hours to

conduct. The time might vary based on the level of detail that is available for review
and the breadth of the overall solution. The solution architect will work with the
implementation team leadership to plan the workshop based on the specifics of the
solution that is being reviewed.

Prior to the Solution performance workshop, participants should be as familiar as

possible with the structure of the workshop and the types of topics and prerequisites
that will be covered. The solution architect will provide an agenda with topics and
prerequisites ahead of the workshop.

Uwaga

Essentially, the Solution performance workshop is a discussion; it’s not intended to be

a questionnaire that can be completed and reviewed in an offline mode. While the
prerequisites are defined and provided in advance, it’s not possible to encapsulate
the breadth of directions in which the conversation might lead.

The solution architect will prepare in advance for the workshop by reviewing existing
project artifacts ahead of time. Helpful project artifacts include:

 Solution blueprint review – As a prerequisite to the solution

performance workshop, a Solution blueprint review workshop should
have been completed already. The information that is captured for areas
such as project plan, solution architecture diagram, business processes,
integration strategy, environment strategy, number of users, data
 migration strategy, and other solution information can lead directly into
this workshop.
 Project plan/schedule – Document or Gantt charts depicting the overall
schedule and dependency of key project phases and their associated
activities.
 System usage profiles – Operational process schedules and peak
transactional volumes by workload type.
 Environment strategy – Block or flow diagrams that outline the types of
environments that will be deployed, how and when they will be used, and
how code and configuration will flow through them.
 Deployment locations – Diagrams or registers that show the physical
locations where the solution will be deployed along with language and
localization requirements.
 Interface register – Lists of interfaces with non-functional requirements
and design patterns that document the scope and approach to
implementing those interfaces.
 Data flow diagrams – In a solution that includes multiple Dynamics 365
apps, legacy, or external services and components, it is helpful to be able
to identify where data originates and how it moves and is consumed in
the solution.
 Data migration strategy – Documents or registers that show the entities
to be migrated, the sources that they will come from, the volumes, the
timing, and the methods for migration. At the solution blueprint stage,
ensuring that you have scope (entities and sources) is key.
 Performance test strategy – Any pre-existing documentation around
performance testing strategy that describes areas such as performance
objectives, KPIs, testing tools, environment to be used, and other factors
that are consistent with performance testing.

This list is not exhaustive of project deliverables, but it is a good starting point for the
solution performance review. The formats, composition, and names of each
deliverable might vary from one project to the next. Format isn’t the most important
element; rather, it’s the information that is available and agreed on across the team.

When you are conducting a solution performance review early in the project, many of
these documents will not be fully formed, which is acceptable in most cases. Most
important is that scope has been determined and that a conceptual plan is in place
for how the solution will support that scope. If the scope and conceptual solution
approach are in place, the solution performance review can focus on the conceptual
approach, and then the follow-up, in-depth workshops can focus on the details at the
point when they are available.

It’s acceptable if the project uses different ways to manage or track project
information other than what is shown in the preceding list. Typically, the format isn’t
critical if the information is readily available to project members. If the information
from the preceding list isn’t documented on the project, or if it’s documented in a
way that isn’t easily accessible, you should prioritize getting the relevant artifacts
produced.

Porada

We recommend that you use diagrams and visual representations to provide high-
level summaries in the implementation, wherever possible. These diagrams, charts,
and graphs provide a ready means of communication across the team and with
executives about plans and designs.

Ukończono moduł:

Workshop implementation and follow-

up
Completed100 pkt.
 20 minutes

The following sections describe how to implement the Solution performance

workshop and then conduct follow-up sessions for more in-depth information.

Solution performance workshop participants

The Solution performance workshop covers a wide range of areas that will involve
many different roles on the project team and those who will be using or supporting
this solution. Additionally, you will need resources that manage other systems that
have dependencies to this solution. In general, participants will fall under these
categories:

 Representatives from the business who are subject matter experts and
can articulate key business processes and expectations on performance
and responsiveness of the system.
 Representatives from the business and the technical team who can
articulate the non-functional requirements.
 Implementation team members (customer and implementation partner)
with intimate knowledge of the design and implementation methods that
are used for configuration, customization, integration, and other aspects
of the solution that will be the focus of the Solution performance review.
  The testing team that will conduct the performance tests.
 IT administrators who can provide information on the
environment/tenant strategy and assist with setting up environments for
performance testing.

Even for technical discussions, it might still make sense to have business
representation so that participants are aware of the impact on their requirements for
performance. Scenarios might exist where non-functional requirements are difficult to
meet unless the business scope is changed. Because of these scenarios, it is important
for business representatives to understand the technical implications so that they can
make better decisions when analyzing the need and priority of requirements.

Implement the Solution performance workshop

The Solution performance workshop will be facilitated by the solution architect, but
the expectation is that the implementation team will present the solution
performance related information. Each section of the agenda should be assigned an
owner within the implementation team. At the beginning of each session, that owner
should present an overview or summary of the scope and plans, including designs
that apply to that aspect of the solution. The team should plan for that summary to
take between 25 to 50 percent of the allotted time, but no more. The remainder of
the time should be reserved for questions and answers with the solution architect.

The implementation team leadership should work with the solution architect ahead of
the workshop to shape the agenda and timings for each session. Depending on the
state and complexity of the solution, different sections might require more or less
time. While the baseline plan is to conduct the workshop in 2 to 4 hours, that time
can be flexible (to a certain extent) to accommodate the implementation.

Time management in the Solution performance workshop is critical. The top priority
for the workshop is to get through all relevant content, which should be prioritized
over going too in depth in any one session. If the conversation becomes extensive,
and you are running out of time to cover the breadth of the subject, you should
expect that the solution architect will table the detailed conversations for follow up in
a more in-depth workshop.

During each session, participants should expect discussion about the scope and
approach. As part of that expectation, the solution architect might provide some
guidance directly within the meeting. However, these sessions are not intended to be
design sessions but rather review sessions. The provided feedback might alter the
current plan or design, but the detailed work in those areas will be carried out by the
implementation team after the workshop.
Solution performance workshop outputs
The output of the Solution performance workshop is a findings document. This
findings document is a response to information that has been provided as
preparation for the workshop or during the workshop. Generally, these findings will
be one of three types:

 Assertions – These findings relate to specific aspects of the solution that

the solution architect wants to call out as architecturally significant. These
assertions are factors that might not represent a specific risk or issue but
are foundational to the solution and should be noted because, if
changed, they will have significant impact. These assertions might relate
to specific scope items, design aspects of the solution architecture, or to
implementation approach or technique.
 Risks – These findings represent an aspect of the solution or
implementation approach that constitute a risk that should be tracked on
the project. These risks could relate to existing plans, approaches, or
designs that have an observed potential for negative outcomes. They
could also be related to areas of the solution that have not been
adequately explored yet, and as such, represent a risk that something
unexpected could come up. These findings will be accompanied by a
statement of what is viewed as a risk, along with recommended
mitigation steps.
 Issues – These findings represent an aspect of the solution or
implementation approach that constitute an issue that is negatively
impacting the implementation, or if not corrected, will have a negative
impact in the future. These findings will be accompanied by a statement
of what the impact is or will be, along with recommended resolution
steps.

The findings document will be distributed to the customer and partner organizations,
and a meeting will be held to review the findings in detail. The document will go to
the implementation leadership and executive sponsors in both organizations. In some
cases, these findings documents can be lengthy, in which case, an executive summary
that highlights key and critical findings is provided for better consumption by
executives.

Addressing all risks and issues is not a guarantee that the solution won’t have
performance issues. This exercise is to mitigate risks and address issues of all factors
that are reviewed and true at the time of the review. However, with any project are
exceptions or new developments that will have an impact. For this reason, the
workshop is iterative so that, as new factors are introduced into the solution, the
workshop can be conducted again to address new needs.
Subsequent Solution performance workshops
Solution performance is an aspect that the implementation team needs to be aware
of throughout the project life cycle. The team will need to plan for solution
performance at the beginning of the project and as they go through development
and testing. Therefore, subsequent reviews might be required for the following
reasons:

 Challenges with the initial Solution performance workshop – The

project team might not have had all relevant information to properly
assess the risks and issues in the initial workshop. Therefore, areas that
might have been tabled in the past can be revisited through subsequent
workshops.
 Significant scope change – In some cases, an implementation is
impacted by major changes in scope or approach due to a variety of
circumstances. These changes could be due to external factors, but could
also be related to significant changes that follow a detailed requirement
analysis. As a result, it will make sense to re-review the Solution
performance workshop.
 Feedback from team – As the solution is developed and tested,
opportunities might become available for you to identify problem areas
of the solution that weren’t captured in the initial workshop. Feedback
from the users through user acceptance testing or administrators from
integration testing can provide more details into the actual end-user
experience, which might warrant a subsequent workshop.

Solution performance workshop follow-up

After the solution performance workshop has been conducted and the findings have
been reviewed, those items that have been identified as risks and issues, and their
associated action items for mitigation and resolution, will be managed to completion
as part of the overall engagement.

Issues that are identified will often have an impact on the ability to successfully go
live. These issues will need to be resolved prior to the go-live readiness assessment
and the deployment of a production environment.

Risks and their associated recommended mitigations can be managed according to

the overall strategy of the project, but they will be monitored throughout the project.
Risks that are not mitigated might be realized later as issues that could also affect go
live.
Follow-up and in-depth workshops need to be supported by the project team
according to recommendations. This factor can affect risk and issue areas that are
identified within the Solution performance workshop, but it can also affect related
areas that require the next level of details due to complexity.

Ukończono moduł:

Check your knowledge

Completed200 pkt.
 6 minutes

Answer the following questions to see what you've

learned.
1.

Which phase of an implementation should the Solution performance workshop

be scheduled to happen?

Initiate
This meeting should be scheduled to happen during the build or implement
phase.
Implement/Build
This meeting should be scheduled to happen during the build or implement
phase.
Prepare
Operate
2.

What tool can be used to validate solution supportability?

Solution Checker
Solution Checker can be used validate solution supportability, along with other
things.
Power Apps
Power Automate
Customization Support Validation
3.

Which of the following customization types should be reviewed and tested for
solution performance?

Developer logic
All of these items are things to look for when reviewing solution performance.
Functional configurations
Flows and workflows
All of the above
All of these items are things to look for when reviewing solution performance.

Ukończono moduł:

Introduction
Completed100 pkt.
 5 minutes

In a Microsoft Dynamics 365 deployment, the process of transition from the old
system to the Dynamics 365 application is defined as the cutover. Occasionally,
cutover is described as the final transition at go-live, but that description
mischaracterizes the actual work for cutover that starts early in the project. During
this final transition, the old system is typically unavailable and so this part of the
transition period is kept to a minimum. Usually, this final transition is conducted over
a quiet period for the business, such as a weekend or holiday shutdown.

You will implement the final cutover later in the project life cycle during the Prepare
phase. Therefore, before go-live happens, you should begin defining the cutover
strategy early in the Initiate phase of the Success by Design framework. The early
conversations about the cutover strategy should include leadership level business
sponsors and the necessary business and technical project team members. This
approach will help ensure that all stakeholders are aligned from the beginning of the
project and are collaborating on defining the end goal in terms of moving from the
current systems to the new systems.

The overall cutover project plan provides the view of the milestones and key tasks
from the start of the project to the go-live event (including the post go-live cutover
tasks). However, the go-live cutover plan needs to be a detailed, task-oriented plan
because you have a limited period in which to perform and validate the final cutover
tasks and limited room for significant errors.
Purpose of the Cutover strategy
workshop
Completed100 pkt.
 5 minutes

The Cutover strategy workshop is designed to ensure that the cutover strategy
provides a good approach and plan to deliver a well-defined, well-tested, reliable,
and safe transition from current systems to the new production systems.

The workshop is layered to help you gain an understanding of the cutover strategy
during the Initiate/Implement phase in terms of:

 Cutover vision and strategy.

 Overall cutover project plan.

During the Implement phase, make sure that you confirm that the cutover-related
tasks (such as data migration for mock cutover testing) are proceeding as planned
and are making the necessary incremental progress. As you approach the Prepare
phase, you need to confirm that the go-live cutover planning and testing is
comprehensive, robust, and well-defined by reviewing the following elements:

 Go-live cutover plan

 Post go-live plan

Capturing these details helps you ensure a complete and well-rounded

understanding of the cutover strategy.

The goal of the Cutover strategy review includes:

 Drive communication and understanding - The review is designed to

drive a conversation about the multiple aspects of cutover across the
various business and technical teams. The cutover has significant
components that the business teams need to own and drive beyond the
technical data migration tasks. The workshop helps to ensure that the
goals, planning, and approach are aligned and well-understood from the
beginning.
 Identification of risks and issues - By starting with a review of the
overall cutover vision and strategy at an early stage, you can identify risks
early. The cutover reviews during the Implement phase are designed to
identify risks to keeping the cutover milestones on track and ready for
final go-live cutover.
Ukończono moduł:

Timing of the Cutover strategy review

Completed100 pkt.
 5 minutes

The first review of the cutover strategy should be conducted as part of the Solution
blueprint review or soon afterward. It might be tempting to postpone the cutover
strategy review because it can be perceived as an activity that happens at go-live.
However, cutover includes the touchpoints from data migration and rollout planning,
and it's a process that starts at the early review of the vision, scope, and strategy. The
overall project plan for cutover helps the project to anticipate and manage risks.

The detailed cutover plan would not be ready in the early stages; therefore, you
should review it at a later stage so that you can identify risks in enough time to
remediate them. During the Implement phase, and for more complex cutovers, you
should plan a key milestone review, which involves reviewing the status and issues
that arise from a key mock cutover. Make sure that you conduct this milestone review
before user acceptance testing (UAT) environment and data preparations are
complete. This approach will help the project team identify risks and address them so
that the environment that is created for UAT is a close approximation of the process
by which the production system will be created after the final cutover.

As the project approaches go-live, make sure that you review the readiness for the
final go-live. This process involves reviewing the risks that are associated with the
following elements and then ensuring that they can be resolved:

 Business activities prior to go-live are identified, communicated, and are

on track
 Data quality from source systems through to Dynamics 365 is understood
in depth and is adequate for effective use in production after the final
cutover
 Issues from mock cutovers have been addressed
 Readiness of the detailed cutover plan and resources is in place
 Readiness of the communication channels and messages for the teams
during the cutover has been defined

Ukończono moduł:
Cutover strategy workshop overview

Completed

100 pkt.

10 minutes

The following sections focus on the high-level aspects of the cutover strategy, including a sampling of
the types of questions that are covered in each section.

Cutover vision and strategy

The Cutover vision and strategy section includes review and discussion of the business goals, cutover
scope and overall strategy, and the cutover timeline. This section provides you with an opportunity to
identify those key stakeholders who support the cutover from all areas of the business. It also
provides details of the cutover strategy that helps establish the remaining topics in the workshop.

This topic focuses on answering questions, such as:

What are the goals of the cutover from a business perspective?

Who is the designated cutover leader and what is the scope of their responsibilities?

What are the responsibilities and ownership for the key cutover activities like data cleansing, data
migration, communication, and so on?

What is the full scope that's intended to be covered by the cutover?

What is the high-level strategy for the cutover?

Has a calendar of key business activities that will take place leading up to and during cutover been
established?

Cutover project plan

The cutover project plan section assesses the more specific details of areas such as the cutover
project plan, data cutover strategy, and the system cutover and transition plans. This section will also
review the strategy for cutover testing, including mock-cutover tests, the timing, and performance
expectations for the cutover, change management processes including end-user communication, and
environment preparations to support the cutover activities.
This topic focuses on answering questions, such as:

Have a description and a copy of the cutover project plan been completed?

What is the detailed data cutover strategy?

What are the data migration processes and milestones that are managed by, or integrated with, the
cutover management process?

How many data migration runs (as part of the mock cutover) have been completed and with what
level of success?

What is the detailed system cutover strategy, and the agreed-on legacy system shutdown process,
including dates/times?

What are the system cutover processes and milestones that are managed by, or integrated with, the
cutover management process?

How, when, and where are the mock cutovers conducted, and how are you validating the cutover
process and the resulting systems?

What are the entry/exit criteria for mock cutovers?

How long is the final end-to-end cutover expected to take?

What day and time will the final cutover start, and when is the new system expected to be live?

What are the high-risk areas for performance during the cutover, and how are they being addressed?

How has change management been implemented and communicated with business users throughout
the project as it relates to the implications of the cutover strategy?
What is the environment strategy to support mock go-live activities?

For finance and operations customer cutover, which environment is currently used as the "golden"
environment, and what's the strategy to move from gold to production?

Go-live cutover plan

The go-live cutover plan considers areas like the organizational aspects of the cutover process,
including the key players who are involved in managing the cutover process and the final approval for
go-live. This section also closely examines the details for the final go-live cutover plan, go/no-go and
rollback plans, and considerations about implementing a remote go-live, including communication
planning.

This topic asks for the following information:

Description of the organization structure that will manage, perform, validate, and approve the final
go-live cutover and the related communication plan.

Description of the key elements of the final go-live detailed cutover plan.

Review of the final go-live detailed cutover plan.

Definition of the go/no-go decision points and when they will be made.

Explanation of the criteria for invoking rollback and/or contingency and the plans for implementing
them.

Discussion and review of the communication plan.

Description of the cutover management strategy that is being designed to work effectively and
efficiently for a remote go-live.

Post go-live

The post go-live section reviews the processes that are defined for those activities that will take place
when the application is in production. This review includes considerations for cutover actions/steps
that need to happen after go-live, transitioning from project into a support model, and the exit
criteria that are defined to complete the cutover process.

This topic asks for the following information:

Description of the process and planning for transition from project to support.

Explanation of post go-live cutover activities and how they will be managed.

Description of the exit criteria and strategy for the cutover process and cutover organization.

Prepare for the workshop

Completed100 pkt.
 10 minutes

Typically, the Cutover strategy workshop takes approximately 1-3 hours to conduct.
The time might vary based on the level of detail that is available for review. The
solution architect will work with the implementation team leadership to plan the
workshop based on the specifics of the solution that is being reviewed.

Prior to the Cutover strategy workshop, participants should be as familiar as possible

with the structure of the workshop and the types of topics and prerequisites that will
be covered. The solution architect will provide an agenda with topics and
prerequisites ahead of the workshop.

Uwaga

Essentially, the Cutover strategy workshop is a discussion; it's not intended to be a

questionnaire that can be completed and reviewed in an offline mode. While the
prerequisites are defined and provided in advance, it's not possible to encapsulate
the breadth of directions in which the conversation might lead.

The solution architect will prepare in advance for the workshop by reviewing existing
project artifacts ahead of time. Helpful project artifacts include:

 Cutover requirements - Known business requirements that need to be

included in the cutover strategy.
 Cutover plan - Document showing the detailed steps and actions for the
entire cutover process. This document should include the documented
 timeline of all cutover activities, dependencies, and owners of each step
of the cutover process.
 Cutover schedule - Document or Gantt charts outlining the overall
schedule for the various cutover activities that are in alignment with the
cutover plan.
 Mock-cutover test strategy - Document describing the plans and steps
for testing the cutover process prior to final cutover.
 Data migration strategy - Documents or registers showing the entities
to be migrated, the sources that they will come from, the volumes, the
timing, and the methods for migration. At the solution blueprint stage,
ensuring that you have scope (tables and sources) is key.

This list is not exhaustive of project deliverables, but it is a good starting point for the
Cutover strategy workshop. The formats, composition, and names of each deliverable
might vary from one project to the next. It's not the format that's most important; it's
the information that is available and agreed on across the team.

It is acceptable if your project uses different ways to manage or track project

information other than the preceding list. Typically, the format isn't critical, if the
information is readily available to project members. If the information in the
preceding list is not documented on your project, or if it's documented in a way that's
not easily accessible, you should prioritize getting the relevant artifacts produced.

Cutover strategy workshop participants

In accordance with the Success by Design framework, the Cutover strategy workshop
should be attended by representatives from the customer organization and the
partner organization that is assisting with the implementation. Having representation
from all parties involved is important in ensuring that everyone is aligned with and
have a common understanding of the plan. In some cases, due to the size of the
implementation team, it might be necessary to limit participation in the workshop to
core members of the team.

With that in mind, you should consider the following guidelines:

 The workshop should include the following customer and partner

participants:
o Cutover lead
o Data migration lead
o Solution architect(s)
o Project manager(s)
 If the customer doesn't have the solution architect role in their
organization, then the responsible technical stakeholder(s) should be
 involved. If the partner organization doesn't have a designated solution
architect who is responsible for the implementation, then the equivalent
delivery lead, functional lead, or technical architects should be involved.
 In some cases, it might be necessary to bring specific resources for
specific topics, which can be accommodated based on the breakdown of
the solution in the workshop agenda.

Additionally, it might be necessary to include executive stakeholders in the cutover

strategy discussions. Ideally, the cutover requirements should have been provided,
and discussions with the executive team members should have already taken place
prior to the workshop. By including executive stakeholders in the workshop, you can
help confirm and provide common understanding of the cutover plans. However, you
should be aware that the discussions in the workshop can become extensive in some
areas, and in some cases, technically detailed. You should establish an expectation
that the types of conversations that will be held as part of the workshop might be at
a lower level of detail than some executives will want to consume.

Ukończono moduł:

Workshop implementation and follow-

up
Completed100 pkt.
 8 minutes

The Cutover strategy workshop will be facilitated by the solution architect, but the
expectation is that the implementation team will present the cutover strategy
information. Each section of the agenda should be assigned an owner within the
implementation team. At the beginning of each section, that owner should present an
overview or summary of the scope and plans, including designs that apply to that
aspect of the cutover plan. When all topics in the planned agenda have been
discussed, the remainder of the time should be reserved for questions and answers
with the solution architect.

During each session, participants should expect discussion about the scope and
approach. As part of that expectation, the solution architect might provide some
guidance directly within the meeting. However, these sessions are not intended to be
design sessions but rather review sessions. The provided feedback might alter the
current plan or design, but the detailed work in those areas will be conducted by the
implementation team after the workshop.
Cutover strategy outputs
The output of the Cutover strategy workshop is a findings document. This findings
document is a response to information that has been provided as preparation for the
workshop or during the workshop.

Generally, these findings will be one of three types:

 Assertions - These findings relate to specific aspects of the cutover

strategy that the solution architect wants to call out as significant. These
assertions are factors that might not represent a specific risk or issue but
are foundational to the cutover and should be noted because, if changed,
they will have significant impact. These assertions might relate to specific
scope items, design aspects of the cutover strategy, or implementation
approach or technique.
 Risks - These findings represent an aspect of the solution or
implementation approach that constitute a risk that should be tracked on
the project. These risks could relate to existing plans, approaches, or
designs that have an observed potential for negative outcomes. They
could also be related to areas of the cutover that have not been
adequately explored yet, and as such, represent a risk that something
unexpected could come up. These findings will be accompanied by a
statement of what is viewed as a risk along with recommended
mitigation steps.
 Issues - These findings represent an aspect of the cutover strategy or
implementation approach that constitute an issue that is negatively
impacting the implementation, or if not corrected, will have a negative
impact in the future. These findings will be accompanied by a statement
of what the impact is or will be, along with recommended resolution
steps.

The findings document will be distributed to the customer and partner organizations,
and a meeting will be held to review the findings in detail. The document will go to
the implementation leadership and executive sponsors in both organizations. In some
cases, these findings documents can be lengthy, in which case, an executive summary
that highlights key and critical findings is provided for better consumption by
executives.

Cutover strategy follow-up

After the Cutover strategy workshop has been conducted and the findings have been
reviewed, those items that have been identified as risks and issues, and their
associated action items for mitigation and resolution, will be managed to completion
as part of the overall engagement.

Identified issues will often have an impact on the ability to successfully go-live. These
issues will need to be resolved prior to the go-live readiness assessment and the
deployment of a production environment.

Risks and their associated recommended mitigations can be managed according to

the overall strategy of the cutover, but they will be monitored throughout the project.
Risks that are not mitigated might be realized later as issues that could also affect go-
live.

Ukończono moduł:

Answer the following questions to see what you've

learned.
1.

At what point of a project should you begin planning for cutover?

As part of the Solution blueprint review or soon afterward

The first review of the cutover strategy should be conducted as part of the
Solution blueprint review or soon afterward. It might be tempting to postpone
the cutover strategy review because it can be perceived as an activity that
happens at go-live.
As part of go-live planning
In tandem with the data migration review
After user acceptance testing is complete
2.

When does a cutover typically take place?

Over a weekend or other quiet period

The final transition typically happens over a quiet period for the business, such
as a weekend or holiday shutdown.
During peak volumes to ensure that the system can handle realistic user activity
Mid-week to allow users time to learn the system during the week
After the solution architect has issued the all-clear notice
3.

During the Cutover vision and strategy review, which of the following factors
would be included?

Business goal
The Cutover vision and strategy section includes review and discussion of the
business goals, cutover scope and overall strategy, and the cutover timeline.
Cutover scope
Cutover timeline
All of these options
The Cutover vision and strategy section includes review and discussion of the
business goals, cutover scope and overall strategy, and the cutover timeline.

Introduction
Completed100 pkt.
 3 minutes

The overall goal of the Success by Design framework is to ensure a successful

customer outcome for each implementation.

The Post go-live workshop is the final workshop in the Success by design series, and
has the following goals:

 Review of project goals and lessons learned - After the go-live event,
reviewing the project goals' achievements against success measures will
help determine if project adjustments are necessary. Reflecting on the
lessons learned will prevent past issues from reoccurring.
 Insights on the next implementation phases - Sharing what's next for
the project/program after go-live will allow a global understanding of
where the digital transformation is heading.
 Support overview - Having a clear escalation path with the correct
support plan for post go-live issues will allow an optimal time-to-
resolution for all future incidents.

Timing of the Post go-live workshop

Completed100 pkt.
 5 minutes
The Post go-live workshop should be scheduled when the go-live event has been
stabilized with no active major escalations. On average, this timeframe usually occurs
one month after go live.

Having the workshop immediately after go live wouldn't provide a high level of
confidence to measure the success of the implementation against the business goals.
Additionally, having the workshop during an escalation likely wouldn't allow the
project team to reflect transparently and constructively on the lessons learned.

For this reason, facilitators should leave sufficient time after go live to stabilize the
solution and to confirm that all business-as-usual operations perform as expected.
This theory is especially true for workloads that could happen at a later date, such as
month-end closing activities for finance.

The following question and answer are typical for the Post go-live workshop.

Question: The go live was relatively simple and limited in scope. Is it necessary to
conduct the Post go-live workshop?

Answer: While it might be tempting to skip the Post go-live workshop, it should be
done at every go live (minor or major) to give the implementation team the
opportunity to confirm that the solution delivered on the goals that were initially set.
Additionally, the team will have time to reflect on the past issues and to take the
correct actions to improve the live operations support and be better prepared for the
next phases.

Ukończono moduł:

Post go-live workshop overview

Completed100 pkt.
 10 minutes

Typically, the Post go-live workshop is conducted remotely. The following sections
cover the high-level aspects of the Post go-live workshop and provide a sampling of
the types of questions that are covered in each section.

Key accomplishments: Review of goals and objectives

The review of goals and objectives section covers the project goals and objectives
that were initially set when the project was launched.
This section aims to confirm whether the goals were achieved by looking at and
comparing business success measures before and after the go-live event to
potentially take corrective actions.

Ultimately, this approach helps the customer realize the value of the investment that
they made.

This section focuses on answering questions, such as:

 What were the initial goals of the implementation?

 What were the business success measures before go live, and what are
the measures after go live?
 Do the success measures indicate that the initial goals have been
achieved? If not, what were the reasons why the goals weren't achieved?
 What should be the changes to start now or for the next phases in the
rollout?

Discussion of lessons learned

The discussion on lessons learned section covers the various learnings that were
captured as the implementation team faced challenges, whether they were with the
implementation of or use of the Dynamics 365 solution.

Candid exchanges around the lessons learned will help prevent past issues from
reoccurring to improve the project delivery and collaboration cross-party and cross-
organization.

This section focuses on answering questions, such as:

 What were the top challenges that were faced during the
implementation, and how could these challenges have been prevented?
 What are the top lessons learned from the implementation?
 What were the top issues related to the Dynamics 365 solution?
 What are the top lessons learned with the use of Dynamics 365?
 How are the lessons learned going to be converted to action items to
assign and follow among the teams?

Post go-live assessment

Post go-live assessment considers the continuous feedback loop and the satisfaction
ratings in key areas of the implementation experience. This section searches for
examples of rating and collecting feedback on items, such as:
  Overall satisfaction with the Dynamics 365 solution
 Administration and governance
 Partner ecosystem
 Support experience
 Service health
 Application lifecycle management (ALM)
 Product roadmap and release cadence
 Reporting and analytics
 Other general feedback

The customer and partner experience of implementing Dynamics 365 has abundant
lessons. Sharing these lessons in the form of open and constructive feedback
contributes to the continuous improvement of the Dynamics 365 implementation
experience.

The post go-live assessment also aims to confirm that a feedback loop is in place to
help the implementation team gather and act on end users' feedback (for example,
with the in-app survey). Then, users can share what they appreciate and what they
think could be improved to ensure a continuous improvement cycle.

Look forward
The looking forward section considers the next phases of the digital transformation
following the go-live event. This section focuses on answering questions, such as:

 What is the rollout strategy and timeline?

 Which other Dynamics 365 applications or services will be deployed in
the next phases of the digital transformation?
 Which other Microsoft Azure platforms or services will be deployed in the
next phases of the digital transformation?
 Will other major external application components or services be
deployed in the next phases of the digital transformation?
 Will major Dynamics 365 upcoming features (preview/generally available)
be considered for the next phases of the digital transformation?

Microsoft Dynamics 365 support options

The Microsoft Dynamics 365 support options section covers the support escalation
path, including the Dynamics 365 support plans that are available to customers.
Minimizing the time-to-resolution requires a clearly defined support process with an
efficient escalation path (from the incident, to levels 1, 2, 3, and 4, and then up to the
resolution).

After the go-live event, all support requests or advisory requests that are opened with
Microsoft support are ruled by the support plan service level agreement (SLA), and
it's critical to understand what these SLAs are so that you select the correct support
plan. This section focuses on answering questions, such as:

 What is the escalation path in case issues occur in the Dynamics 365
solution?
 Are the teams that are involved in the escalation path trained enough to
handle the incidents after the hypercare period?
 Which Microsoft Dynamics 365 support plan will be used, and is it
relevant with the solution coverage?
 Is the team using the online content to stay up to date?

Ukończono moduł:

Prepare for the workshop

Completed100 pkt.
 5 minutes

Typically, the Post go-live workshop takes approximately 1-2 hours to conduct. The
time might vary based on the complexity of the project, the scope of the go-live
event, and the challenges that are found throughout the implementation.

Before the Post go-live workshop, participants should be familiar with the structure of
the workshop and the types of topics and prerequisites that will be covered.

The central prerequisite for preparation is the Post go-live workshop template that
captures information about the presented sections (such as the project goals, lessons
learned, and so on). The implementation team needs to complete and share the
template with the solution architect at least two working days before the workshop.
Essentially, the Post go-live workshop is a discussion. It's not intended to be a
questionnaire that you can complete and review in an offline mode.

Additionally, having the following project artifacts ready would enrich the exchanges
during the workshop:

 Project charter - Document that provides the background of the project,

especially the objectives, and expected key results.
  Rollout plan/schedule with the next phases - Document or Gantt
charts showing the next phases in the digital transformation journey.
 Support process/escalation path - Support levels and support owners
for new live incidents.
 Support responsibility assignment matrix - Table of support, servicing,
and maintenance tasks, and roles related to these tasks. These
relationships are typically assigned through a responsible, accountable,
consulted, informed (RACI) classification.

This list isn't exhaustive of project deliverables. But it's beneficial to share these
deliverables or have them ready to show during the Post go-live workshop.

Ukończono moduł:

Post go-live workshop implementation

and follow up
Completed100 pkt.
 8 minutes

The following sections describe how to implement the Post go-live workshop and
then conduct follow-up sessions for more in-depth information.

Post go-live workshop participants

The Post go-live workshop is the opportunity for the project team and the project
sponsors to assess the success of their implementation and to reflect on the
adjustments to make in the future.

With that in mind, you should consider the following guidelines:

 The workshop should be attended by representatives from the customer

organization and the partner organization that is assisting with the
implementation.
 The workshop should include the project sponsor, project manager, and
solution architect from the customer and the partner organization. If the
customer doesn't have the solution architect role in their organization,
then the responsible technical stakeholder(s) should be involved. If the
partner organization doesn't have a designated solution architect who is
 responsible for the implementation, then the equivalent delivery lead,
functional lead, or technical architects should be involved.

Implement the Post go-live workshop

The solution architect facilitates the Post go-live workshop and frames the
discussions, but the expectation is that the implementation team will present the post
go-live information.

Each section of the agenda should be assigned an owner within the implementation
team.

Preparing and completing the presentation template for the workshop allows for
richer discussions that often result in clear adjustment actions to take (for example,
on the project goals, the lessons learned, or the post go-live assessment).

One main goal of the Post go-live workshop is to reflect on the implementation
journey and identify the adjustments to make in the future to improve on all possible
levels (project delivery, collaboration, communication, and so on). So it's critical for
everyone to come to the sessions with a growth mindset, which encourages candid
and constructive exchanges.

The intent of the Post go-live workshop isn't to review the status of support incidents
or to treat solution design questions at this late stage.

Post go-live workshop outputs

The Post go-live workshop has a main output in the form of a workshop summary
email that highlights the key recommendations that are presented during the session.
It doesn't have a findings document (as is the case for the Solution blueprint review
workshop).

This approach allows the implementation team to follow up with the relevant party
and in the most efficient approach based on the related subject, such as:

 project delivery
 project risk or issue
 licensing
 transition to support

The final presentation, including the actions that are listed during the session, should
be distributed to all parties who participated, including the implementation
leadership and the executive sponsors in both organizations. This full distribution will
ensure an alignment on the items that are discussed and on the following adjustment
actions to take.

Post go-live workshop follow-up

After the Post go-live workshop has been conducted and the adjustment actions
have been identified, the implementation team will follow up after the workshop by
using the appropriate channel based the related subject. For example, support
incidents on the standard platform with Microsoft, or licensing questions with the
Microsoft account team.

The learnings that are compiled throughout the engagement and Success by Design
workshops should be used even after the implementation.

For larger programs or projects, the implementation team should consider running
Success by Design reviews internally. You can use the Use Success by Design for
Dynamics 365 solutions self-service training material that is available online.

Ukończono moduł:

Check your knowledge

Completed200 pkt.
 6 minutes

Answer the following questions to see what you've

learned.
1.

Which one of the following options accurately describes Success by Design?

It is a project management tool for managing apps in Microsoft Power Apps.

Many options are available to help you manage your apps in Power Apps, but
Success by Design isn't one of them.
It is prescriptive guidance for designing, building, and deploying Dynamics 365 and
Microsoft Power Platform solutions.
Success by Design guides you through the key checkpoints of your project to
ensure its success.
It is a training program for Dynamics 365 users.
It is training for solution architects.
2.

Which one of the following options are goals of the Post go-live workshop?

Review of project goals and lessons learned

Following the go-live event, reviewing the project goals achievement against
success measures will help you determine if project adjustments are necessary.
Reflection on the lessons learned will help prevent past issues from reoccurring.
Insights on the next implementation phases
Support overview
All of these options
As you evaluate and reflect on the project, each goal will help you move ahead
to a productive system that users will appreciate.
3.

Which of the Success by Design workshops is the most important to complete?

Test strategy review

While important, this workshop is only one part of the bigger picture.
Gap solution design
Cutover strategy review
All of these options
Each workshop can make or break your project if you need the review. It's
important to evaluate the goals of each workshop against the specific project
needs, and then use each workshop to your advantage.