This very comprehensive white paper provides a detailed and clear overview of Microsoft's D365 Finance & Operations solutions to support Data & Analytics. There is a newer version of this available - search SlideShare for the new version of this deck.

1. 1 | P a g e
What you need to know about Reporting & Analytics
Dynamics 365 Finance & Operations
Written By:
Gina Pabalan
Managing Director, Business Intelligence
Edgewater Fullscope
https://www.linkedin.com/in/ginapabalan

2. 2 | P a g e
Table of Contents
A. OVERVIEW 3
B. DEFINING THE BASICS 3
C. MICROSOFT’S APPROACH FOR REPORTING AND ANALYTICS WITH D365 F&O 5
EMBEDDED OPERATIONAL WORKSPACES 5
EMBEDDED ANALYTICAL WORKSPACES 6
EMBEDDED POWERBI.COM DASHBOARDS 6
OTHER REPORT AUTHORING TOOLS 8
CURATING DATA 8
SUMMARY OF OPTIONS 9
ENTITY STORE 10
WHAT IS THE DIFFERENCE BETWEEN AN “AGGREGATE MEASURE” AND “AGGREGATE ENTITY”? 10
ODATA CONNECTIONS 11
BRING YOUR OWN DATABASE (“BYOD”) 11
ENTERPRISE DATA WAREHOUSE (“EDW”) 12
D. IN CONTEXT OF YOUR D365 F&O IMPLEMENTATION 13
ASSESSING THE LANDSCAPE AND SETTING EXPECTATIONS 14
BUILDING REPORTING & ANALYTICS REQUIREMENTS WITHIN YOUR D365 F&O PHASE I IMPLEMENTATION 16
FULLSCOPE’S BI ACCELERATOR 16
E. UPDATES AND FEEDBACK 17

3. 3 | P a g e
A. Overview
There are many advantages and exciting promises of cloud-based computing, along with new challenges
that we will face along the way. In regards to Microsoft Dynamics 365 Finance & Operations (“D365 F&O”)
reporting and analytics, the same holds true.
In this white paper, we will describe Microsoft’s out-of-box tools for reporting and analytics, define the
various customer requirements and how these are met within the D365 F&O framework, address the
specific skills required to deliver on each, and best approaches to serving complex data & analytical
requirements.
B. Defining the Basics
Before we get started, it’s important to define the different terms used to discuss this hot topic:
1. Report Form – A business form such as an Invoice or Bill of Lading. Forms are developed using SSRS.
2. D365 Grid – This is a predefined “grid” of information displayed within the D365 application. A grid
of information may be easily sorted and filtered. You may also export a grid data into Excel via
OData protocol (note: size limitations apply, see section on OData). Grids are developed using X++.1
3. Paginated Report – This is typically a printed report with columns and lines of transactional data,
possibly with totals and subtotals. Paginated reports are typically developed using SSRS.
4. Excel Export (“Export to Excel”) – this is when transactional data is exported into Excel for the
purpose of serving a more exploratory business reporting requirement. In this case, Excel is both
storing the data as well as authoring the report (note: size limitations and data security are key
considerations).
5. Excel-based Report (“Open in Excel”) – This implies that Excel is connected to the D365 data set and
being used merely as the reporting authoring tool.
6. Embedded Workspaces – these are dashboards viewed within D365. They can be either Analytical
Workspaces or Operational Workspaces. (more on this later)
7. Analytics - Related to interacting with and visualizing data, leveraging aggregated or summarized
data sets with the ability to slice and dice, and interactively drill into lists and individual transactions
in a more ad hoc exploratory fashion. Analytics implies the use of dashboards and the ability to set
up KPIs and metrics to visually understand where the organization is trending, and also to potentially
use more advanced predictive BI capabilities to better understand the key performance drivers of
the business and predict where it is heading.
8. Augmented Analytics – Related to leveraging Machine Learning (“ML”) and Artificial Intelligence
(“AI”) used for the analysis of current and historical data to generate actionable predictions of future
events. Augmented Analytics can also be used to automatically perform tasks that normally require
human intelligence, such as speech recognition, decision-making, and translation between
languages.
Once the business’s reporting and analytics requirements are understood, there are two key
considerations to determine in the design:
 Curating Data (how and where will the data be curated)
 Authoring Reports (what is the best tool to write the report)
1
In release 8.1, not yet available at this writing, users are expected to be able to expand, collapse (group by), see
subtotals by group, and see totals in filtered or non-filtered views in form grids. The Excel style filtering in the grid
by top row will return.

4. 4 | P a g e
Although most people are very excited to see the output of business intelligence (the “authoring report”
part), it is important to note that one does not exist without the other. Curating data correctly is critical
to a successful reporting and analytics program. If we don’t get the data part right, there are
consequences, like reports that take too long to run, system performance issues (impacting other parts of
the system), inability to get at the required information, getting inaccurate information, displaying wrong
level of granularity, inability to harmonize data with other sources, latency between a business need and
the availability of a solution, etc.
Understanding where to source and curate data, how to structure the data, what tools and skills are
required to do this work are questions that should be considered, along with the proper report authoring
tool, when embarking on a reporting and analytics initiative.

5. 5 | P a g e
C. Microsoft’s approach for reporting and analytics with D365 F&O
Microsoft understands that although most people interact with business applications daily, fewer than
22% of employees have access to analytical insights. Further, Microsoft intends to make PowerBI the new
“Excel” for business users to federate analytics across the organization. With Microsoft Dynamics 365
Finance & Operations (“D365 F&O”) delivery of cloud-based ERP, the promise of delivering analytics to
the masses has become a reality. And here in lies the opportunity.
What is new in Microsoft Dynamics 365 Finance & Operations (“D365 F&O”) are Embedded Analytics.
Embedded analytics empower and enrich the user experience. Within D365 Embedded Analytics, we are
able to deliver an enriched user experience to all D365 users. There are three types of Embedded
Analytics: Operational Workspaces, Analytical Workspaces (also referred to as “embedded PBi”), and
Embedded PowerBI.com2
.
Embedded Operational Workspaces
Operational Workspaces help D365 F&O users manage and prioritize daily tasks and track items that
require attention. Operational workspaces provide big picture statistics with drill through capability to
the detailed transactions. An example is perhaps a tile that lists the number of unapplied customer
payments, with a drill through to the associated detailed payments, so the associate can easily navigate
to the list of payments requiring settlement. These workspaces directly access the D365 transactional data
(also referred to as “D365 OLTP”, or “AxDB”) real time and are relatively easy to personalize. Microsoft
delivers over 50 pre-configured Operational workspaces within D365 F&O that can be enhanced to meet
specific business requirements. The underlying technology for these workspaces is native X++
programming language and embedded chart controls.
It should be noted that users can create their own workspaces and enrich them with lists and tiles – even with the
drill though capability. However, KPIs and charts require the D365 developer to create these visuals.
2
Embedded PowerBI and Embedded PowerBI.com are two different capabilities and are also implemented
completely differently.

6. 6 | P a g e
Embedded Analytical Workspaces
Analytical Workspaces, also referred to as “embedded PowerBI,” deliver insights into the business,
leveraging data summarized in charts, KPIs and beautiful PowerBI (PBI) visuals. These workspaces are
intended to help users identify trends, relationships and anomalies expressed through data visualizations.
Analytical workspaces leverage aggregated data sourced within the D365 Entity Store (also referred to as
“AxDW”), and are designed to quickly analyze large volumes of data at once. The aggregated data in the
Entity Store is updated from the D365 OLTP near real time. Microsoft delivers over 18 pre-configured
Analytical workspaces within D365 F&O that can be enhanced to meet specific business requirements.
These workspaces, developed using Embedded PowerBI, require data preparation, which is accomplished
through the development of Aggregate Measures (which are then used to push data to the Entity Store).
The creation of Aggregate Measures requires knowledge in proper data modeling design, X++, MDX3
and
native D365 application configurations. Embedded PowerBI should not be confused with Embedded
PowerBI.com Dashboards, which are explained below.
Embedded PowerBI.com Dashboards
In addition to the above two types of embedded workspaces, PowerBI.com dashboards can also be
embedded into the D365 F&O form. This requires each report viewer to have a PowerBI Pro license (or
Premium) in addition to their D365 F&O license, and is configured by the user, as opposed to an enterprise
configuration. Any user who has both a D354 F&O license and a PowerBI Pro license can select the “Get
Started” option (shown above in the Operational Workspace illustration), to quickly embed a
PowerBI.com dashboard that they have access to. The data and dashboard are completely separate from
the underlying D365 data, unless of course the D365 data has been first curated and surfaced through
PowerBI.com. In this scenario, the D365 form is merely being used as a display for the PowerBI.com
3
The MultiDimensional eXpressions (MDX) language provides a specialized syntax for querying and manipulating
the multidimensional data stored in OLAP cubes. MDX has become the standard for OLAP systems.

7. 7 | P a g e
dashboard. There is no drill through into the D365 forms in this case. The data source for the
PowerBI.com dashboard is not limited to D365 data, and can include data from any source that has been
curated and surfaced through PowerBI.com.
For example, the PowerBI.com dashboard shown below has been created using a separate PBI.com model
file. In fact, the data contained in this particular dashboard is completely unrelated to the D365 data.
With the Embedded PowerBI.com feature within D365, a user can quickly embed this Dashboard
wherever the option for PowerBI is made available.
PowerBI.com Dashboard Embedded in the Credit and Collections Operational Workspace
(the same) PowerBI.com Dashboard Embedded in the Budget Planning Operational Workspace

8. 8 | P a g e
It should be noted that this feature is not available to be made at the corporate level and is handled as a
personalization by individual users.
Other Report Authoring Tools
Customers have more options for addressing operational and analytical reporting needs within D365 F&O.
Again, one must consider both the reporting tool, as well as the data source, when developing a holistic
approach for reporting. There are seven (7) standard report authoring tools within D365 F&O, and six (6)
areas in which to source data.
In addition to the two different flavors of Embedded Workspaces, the other five Report Authoring tools
standard to D365 F&O are:
1. Management Reporter (“MR”) is the report authoring tool Business Users use to develop and
generate financial reports. MR is included in D365 F&O licensing. MR leverages its own “data
mart” which prepares the underlying OLTP data for consumption. This “data mart” is a black box,
in that external data cannot be brought in, nor can it be modified in any way. In fact, most
customers are not even aware that it’s there. Microsoft delivers the MR data mart to specifically
serve the needs of reporting in Management Reporter. No other report authoring tools may
access the MR data mart.
2. SQL Server Reporting Services (“SSRS”) is the tool IT resources use to generate pixel perfect
paginated reports, with structured headers and footers that include columns and rows of
transactional data, with subtotals and totals. SSRS is included within D365 F&O application.
Microsoft delivers approximately 1,200 SSRS reports available with out-of-box D365 F&O.
Customers are also able to write custom SSRS reports from within the D365 F&O application,
connected directly to the OLTP data. Of course, an externally deployed version of SSRS can also
be used to author reports, but it would be subject to the same constraints as other external report
authoring tools mentioned in this white paper.
3. D365 Grid is a D365 form that has predefined “grid” of information displayed within the D365
F&O application. Once the grid is defined and developed by IT development resources, business
users are able to easily sort and filter the live D365 data and even export it to Excel, with an OData
connection. D365 grids also allow for some limited personalization by users to add or hide data
fields.
4. Excel is considered an analytical tool used by Business Users that allow for tabular reporting and
data exploration.
5. PowerBI.com is considered an “analytical” tool used by IT and business users that allow for data
exploration and visualization. Generally, PowerBI.com is used over an aggregated, or
summarized, data set. The degree of aggregation is dictated by how the underlying data has been
modeled. Data may be ingested into PowerBI.com directly, or a “Direct Query” method against
an external data source may be used. Any PowerBI.com dashboard can be displayed within D365
forms, as discussed above.
Curating Data
The curation of data is a key inflection point in determining your overall reporting and analytical
strategy.
There are six (6) different places in which to source data when authoring a report or visualization. Not all
report authoring tools may connect with all data sources!

9. 9 | P a g e
The six potential Data Sources are:
1. D365 Transactional OLTP Database, “AxDB” (not available to external report authoring tools)4
2. D365 Data Entities within AxDB (available to external report authoring tools via an OData
connection). There are two types:
a. Aggregate Data Entities, or simply “Aggregate Entities” – for aggregated data
b. Standard Data Entities, or simply “Standard Entities” – for transaction level data
3. Management Reporter Data Mart (only serves Management Reporter for report authoring)
4. Entity Store, “AxDW” (only serves Embedded PowerBI for report authoring)
5. BYOD (Bring Your Own Database) – secure Azure SQL database with no access restrictions
6. Enterprise Data Warehouse (“EDW”) – secure Azure or On-Prem Data Warehouse with no access
restrictions
Summary of Options
The following is a table and illustration of options for Data sourcing and report authoring for D365 F&O:
4
Sometimes confusingly, access to the D365 OLTP database is available in some NON Production D365 F&O
environments. This should be considered in the design and implementation of reporting.
1 2 3 4 5 6
Report Authoring Tool
Authoring
Technology
D365Transactional
OLTP("AxDB")
D365DataEntities
(Standard&
Aggregated)
Management
ReporterDataMart
EntityStore
("AxDW")
BYOD
EnterpriseData
Warehouse
Embedded Workspace - Operational View X++, Chart Controls l l
Embedded Workspace - Analytical View Embedded PBi l
Management Reporter MR l
SSRS SSRS l l l l
D365 Grid X++ l l
Excel Excel l l l
PowerBI.com PBi l l l
l through Odata Connection only
Data Source

10. 10 | P a g e
Entity Store
The Entity Store, which is named “AxDW” within D365, serves Embedded PowerBI/Analytical Workspaces.
The Entity Store is a Clustered Column Store Database, separate from the OLTP, and as such, data is “near”
real-time. At this writing, the Entity Store is only available to be refreshed as a full load. Incremental
refresh is in an early Microsoft preview program. It is anticipated that once the incremental load is
available, the Entity Store can be updated as “Low Priority” to refresh every 15 minutes, or “High Priority”
to set up every 1-5 minutes5
.
In order to populate the Entity Store, “Aggregate Measures” must first be configured with the D365
application. Conceptually, this is similar to building OLAP cubes, but less complex when using the D365
Aggregate Measure options. If more complex features are required, such as building out complex
calculations, MDX language (calculations and scripts) may also be used to augment out-of-the-box
features of building Aggregate Measures. Aggregate Measures provide the definition, or data model, for
the Entity Store. The creation of Aggregate Measures requires knowledge in data modeling design, X++,
MDX and native D365 application configurations.
At this writing, there are 52 out-of-box Aggregate Measures within Dynamics 365 F&O that are used to
publish data to the Entity Store.
Aggregate Measures are different from Aggregate [Data] Entities.
What is the difference between an “Aggregate Measure” and “Aggregate Entity”?
In addition to providing definition for the Entity Store, Aggregate Measures also provide the definition for
the Aggregate [Data] Entities. We must first define and create an Aggregate Measure before we can
5
We recommend setting the Entity Store update on Low Priority – as every 15 minutes should meet most reporting needs.
Setting this at a High Priority may create excess batch processes to keep the Entity Store updated and could possibly delay other
operational batch processes. Microsoft states that in case of very high system utilization (ex. due to extreme refresh schedules),
the Microsoft operations teams will advise the customer on managing load.

11. 11 | P a g e
create an Aggregate Entity. The Aggregate Entities reside within the OLTP (AxDB), so access to the data is
in real time and since it may access transactional level data, non-clustered column store indexing is used
to return data more quickly when a query is executed. Aggregate Entities can be useful for “Pie Charts”
and other visuals when working with Embedded Operational Workspaces. Aggregate Entities can also be
accessed via OData from PowerBI.com, or even Excel.
At the current writing, there are 11 Aggregate Entities delivered out-of-the-box with D365 F&O, 5 are
finance-specific and 6 support the Retail module:
 BudgetActivityEntity
 BudgetAmoutnbyPeriodAggregateDataEntity
 BudgetPlanActivityEntity
 LedgerActivityEntity
 LedgerAmountsByPeriodAggregateEntity
 RetailTransDetailsADE
 RetailTransDetailsNoItemIdADE
 RetailTransDiscountedADE
 RetailTransInvoicedADE
 RetailTransPriceOverridesADE
 RetailTransVoidedADE
Embedded PowerBI (aka, Embedded Analytical Workspaces) uses Aggregate Measures, NOT Aggregate
Entities!
OData Connections
Open Data Protocol (OData) is an open integration protocol developed by Microsoft and recognized as a
global standard, for querying and updating data and is built on standardized technologies such as HTTP,
Atom/XML, and JSON. Unless the BYOD is leveraged, OData is the only way to connect with D365 data
from external report authoring tools.
Further, access to D365 F&O data via the OData protocol is only available through the Data Entities
(either Standard Entity or Aggregate Entity). Access to the underlying transactional D365 tables is not
available from external report authoring tools, including PowerBI.com.
The OData protocol limits transfer to 10,000 records at a time6
. If using an external report authoring
tool (Excel or PowerBI.com, connecting directly to the Data Entities), and running reports with data
volumes exceeding 10,000 records, the report will not be performant.
Bring your own Database (“BYOD”)
BYOD is an Azure SQL database that is used as a data store for transactional level D365 F&O data. D365
F&O customers are licensed for BYOD, however an additional Azure subscription will be required. The
BYOD has no Microsoft driven limitations in terms of data access, and is available for all external report
authoring tools, including PowerBI.com, Excel or SSRS (external).
BYOD is built leveraging the Data Management Framework and supports large batch D365 F&O data
exports. To set up the BYOD, D365 F&O Standard Data Entities must be configured to incrementally export
the D365 F&O transactional data (AxDB) into the customer’s own Azure SQL data store (BYOD).
It is recommended that customer’s create custom Standard Data Entities as opposed to the out-of-box
Standard Data Entities that are delivered with D365 to create the BYOD. The out-of-box Standard Entities
were developed with data import in mind, not data export and reporting. For example, the out-of-box
Standard Entities include ALL the underlying attributes within a table. In a reporting scenario, one would
not need all the fields within all the required tables. Further, the out-of-box Standard Entities are not set
6
Release 8.1 which is not yet available, is expected to address this limitation. This white paper will be updated
when this is available and verified.

12. 12 | P a g e
up for incremental load. In a real world scenario, we will want the BYOD to load incrementally, especially
as the underlying transactional dataset grows. Further, the out-of-box Standard Entities have been de-
normalized, which will create data redundancies within the BYOD and cause other issues as addressed
below.
Either way, the creation of custom Standard Entities is quite simple (as compared to creating aggregate
entities), however it does require an X++ developer, SDLC (Software Development Life Cycle) and
deployment like any other D365 modification. The Standard Entity should be architected to meet the
specific needs of the customer. And it is recommended to design for the future (and often unknown)
reporting and analytics needs of the business, vs taking a one-off kind of approach.
A more normalized data set within BYOD supports future scalability, flexibility, and a reduction of data
and query redundancies, and results in more efficient data storage, reduced cost and reduced risk.
Aligning the Standard Entities to the underlying OLTP tables promotes flexibility and data transformation
transparency if the BYOD is to be used as a data source to support a more structured data modeling effort
– such as, but not limited to, a data warehouse scenario. This approach makes it much easier for IT staff
to build SQL based reports for other needs outside of the “current” report requirement, and reduces the
risk of “entity proliferation.”
If a transformed, de-normalized data set is used to push data to the BYOD, the data transformation is
“veiled” in the underlying code within D365, plus it results in data redundancy within the BYOD - which
could become a limitation over time. In addition, certain system fields such as RECID, etc. would not be
exposed, limiting the tables which can be joined to the de-normalized entity.
We also want to reduce the risk of the proliferation of data entities. For example, a customized entity
could be created for the specific report requirement, providing all the fields and logic necessary within
that one entity. That would not only result in data redundancy, but could lead to the proliferation of
single purpose entities, and wouldn’t give the customer the ability to easily write their own reports or
queries for other purposes. This is a significant risk in how customers may choose to meet specific
reporting requirements during the throes of a D365 F&O implementation.
If the customer requires an Enterprise Data Warehouse (“EDW”), BYOD will be used to facilitate the
transfer of information. BYOD does not connect via OData, which would be quite limiting with the larger
data requirements required to support transactional level table updates and data warehouse integration.
Enterprise Data Warehouse (“EDW”)
Organizations that have a high level of data diversity, such as multiple line of business systems, additional
ERP applications, additional applications interfaced with D365 F&O, or that have complex data and
analytical requirements, an Enterprise Data Warehouse may be part of the overall reporting and analytics
strategy.
The EDW may be platformed in Azure SQL, Azure Data Warehouse, SQL Server or a variety of other
potential platforms. The EDW becomes an IT-controlled and managed, governed corporate data set that
serves the broader reporting and analytical needs of the organization. The EDW will store transactional
level details, and become the one source of the truth for building semantic models or serving structured,
simplified and harmonized data to tools like PowerBI, Excel or even SSRS. The EDW data architecture is
designed to optimize reporting (i.e. read operations), not transaction processing (i.e., write operations),
which is a completely different framework for storing data.
The benefits of the EDW are:

13. 13 | P a g e
 If multiple source systems are in play that require data harmonization for the purpose of
reporting, transforming this data through more standard Microsoft ETL capabilities will result in
less risk, less cost and a higher degree of adaptability (required for BI).
 Creating reports and analytics sourced from a structured, simplified and harmonized data set
will allow more mainstream users to explore the data and build data literacy, allowing more
individuals in the organization to obtain business value from it. The result is that reports are
simpler to build, empowering the average user to dig into the data, build their own reports,
analyze new information, and make discoveries not thought of previously.
 Generating reports and analytics sourced from a structured, simplified and harmonized data set
will allow reports to run more quickly and efficiently.
 Common data transformations such as standard costing, currency conversions, unit of measure
conversions, and other business approved and validated calculations are all built into the EDW,
ensuring that reports are truly displaying the expected results, versus having multiple reports
implement the various conversions and calculations in differing ways. This ensures data quality
and consistency throughout.
 The Dimensional Model design of the EDW allows for the implementation of slowly changing
dimensions, displaying the state of the various transactions and attributes exactly as they were
at that point in time.
 Allows for better snap shot capabilities, such as inventory snapshots, account payable aging
snapshots, sales pipeline snapshots, etc.
 Decoupling the data management platform that serves reporting & analytics from the
transactional system that serves day-to-day transaction processing allows the BI journey to
evolve in a more agile manner.
 As data literacy grows, key models evolve and requirements are better defined. Implementing
select corporate BI data models within the D365 platform will be easier, resulting in less rework,
cost and risk.
Lastly, the EDW does not replace the operational reporting and embedded analytics within D365 F&O. It
augments it, and in some cases, will enhance it.
D. In Context of Your D365 F&O Implementation
Now that we have most of the technical considerations explained, let’s consider all this in terms of your
D365 F&O ERP implementation.
The primary goal of your D365 F&O implementation may be to implement a flexible, cloud-based
enterprise business application that enables the organization to adapt to changing business needs, fuel
innovation and take advantage of technical advancements. Part of this may even be to improve data
literacy throughout your organization or to even establish a foundation for a future analytics program.
Implementing a new ERP system consumes significant resources: time, money and overall energy of the
business. During the implementation project, your team and the overall business will be very focused on
the basic blocking and tackling of business process transformation and marching towards a “go-live” date.
After all, when the new system in turned on, you will need to be ready to take customer orders, ship
products and invoice your customers.
But we also know there will be baseline reporting capabilities required to be in place from Day One.

14. 14 | P a g e
Foundational decisions should be made at this stage and since there are different ways to achieve the
same result, one might want to consider the bigger picture verses making reporting decisions one report
requirement at a time (such as “which reporting tool?” and “where is the data sourced?”). We want to
avoid making short term decisions at the expense of serving long term goals.
Further, BI fuels much excitement with your business leaders, and it may be easy to get side tracked
with “BI” requests. It will be important to keep your eye on the ball implementing a new transaction
processing system, manage expectations and cost, and avoid future surprises.
Assessing the Landscape and Setting Expectations
When D365 F&O is put into production, the business will not want to step back from where they are at
today with reporting and analytics. So, it is important to understand the organization’s current level of BI
Maturity, Application Landscape, as well as the Organizational Alignment that serve the business’
reporting & analytics needs. And then consider these in terms of D365 go-live goals and future end-state
goals.
For each question below, consider these in terms of current state, at D365 F&O go-live, and aspired end
state:
BI Maturity
1. What is scale of your analytical capability?
Individual (s)
Departmental
Enterprise
2. What is the use of data in the organization (all may apply)?
Corporate Reporting
Ad-Hoc/ Exploratory
Dashboards & Visualizations
Advanced Analytics (predictive, AI)
3. What is your Data Infrastructure?
Reporting from transactional systems only
Spreadsheets
Independent Data Marts
Enterprise Data Warehouse
Big Data Eco System
4. How does your organization think about data (“Data Culture”)
Tactical
Mission Critical
Strategic
Application Landscape
 How many source systems or other data sources are required?
 Is there a need to merge, or harmonize data from multiple source systems?
 To what extent will you need to harmonize historical transactional data with D365 data?
 Are applications running on-premise, in the cloud or both?
 What Report authoring tools are/will be used?

15. 15 | P a g e
Organizational Alignment
1. What is the business geography?
Single location
Multi location – US
Multi location – North America
Multi location - Global
2. Who is the Business Executive champion for delivering analytics within the organization?
CEO
CFO
VP – Business Unit
CIO
3. Is there a Data & Analytics team (BI Competency Center)?
4. Who manages and controls Master Data, does this occur in a systematic way, or ad hoc?
5. What is the break out of mainstream users (expecting IT to author reports) vs the Business Analysts
& Super Users (desiring a more ad hoc approach for reporting)? And is there a goal to trend towards
the latter?
6. What is the overall level of data literacy within the organization?

16. 16 | P a g e
Building Reporting & Analytics Requirements within your D365 F&O Phase I Implementation
The business users require information to execute their jobs, to make decisions, to report to governmental
agencies, etc. Sometimes this information is critical to day-to-day operations of the business, regardless
of the ERP system used or where that information comes from. The next step then is to inventory the
current reporting & analytical needs of the business. The goal here is to not reproduce every report that
exists in the legacy ERP environment. The goal is to understand at a high level, the holistic informational
requirements of the business, especially but not exclusively as it relates to the Phase I D365 go-live. At
this point, we are not considering the optimization of enterprise analytics, we are looking to meet the
critical and must-have requirements for the Phase I implementation.
The following is a list of important attributes to understand about each informational requirement. Once
the inventory is built and these attributes known, a recommendation can be made as to where the data
is sourced (curated) and what report authoring tools are best.
For each reporting or informational requirement, identify:
1. Usage – Individual, Departmental, Business Unit, Enterprise
2. Output Type – Document, Paginated Report, Excel, No Print/Screen (i.e., PowerBI, D365 Grid)
3. Info Type – Statutory, Operational, Analytic, Exploratory
4. Data set size – Data sets over 10,000 records should be noted
5. Level of Complexity – Joining data from multiple areas within D365 or multiple systems or complex
calculations?
6. Single source D365 or multi-source data?
7. If Multi-source, name Sources.
8. Priority – critical for Phase I go-live, must-have, or nice-to-have?
9. Frequency – how often is the report run? Multiple times a day? Once a day? Once a month?
10. Data Refresh (Currency) – up to the minute, 15 minutes, 4 hours or EoD (end of day)
If taken as a whole, we can minimize ambiguity and put a winning strategy in place that will meet
expectations and maximize time and investment returns, while building a solid foundation for a future,
more comprehensive analytics program.
Fullscope’s BI Accelerator
Fullscope is committed to delivering on the promise of embedded analytics within D365 F&O. We also
recognize that some clients will have a high level of data diversity and/or more complex data
requirements. Fullscope’s BI Accelerator is a data management solution that helps D365 F&O clients
curate D365 F&O data, as well as harmonize it with other sources in preparation for reporting and
analytics.
1. 100% Microsoft Stack
2. Azure or On-Premise
3. Baseline BYOD (including Standard Entities) for supporting an Enterprise Data Warehouse
architecture
4. ETL Automation for agile delivery of your BI solution, and a short learning curve to promote self-
sufficiency
5. Baseline D365 Enterprise Data Warehouse to jump start your project
6. Supports ALL report authoring tools that can consume SQL, SSAS OLAP or SSAS Tabular data
7. Affordable with a high ROI

17. 17 | P a g e
E. Updates and Feedback
This white paper has been written based on currently available capabilities of Microsoft Dynamics 365
Finance & Operations. Product updates and enhancements are consistently being pushed out to the
market. Therefore, look for regular updates to this document.
Feedback may be sent directly to gina.pabalan@fullscope.com, or find me on LinkedIn.