Companion Guide for course 81060AE

Configuration in Microsoft Dynamics 365

for Sales and Customer Service

Table of Contents
Module 01: Configuring Dynamics 365......................................................................................................2

Course Overview...................................................................................................................................2
Module Overview..................................................................................................................................4
Configuring Dynamics 365.....................................................................................................................4
Security................................................................................................................................................13
User Management...............................................................................................................................16
Email System Settings and Configuration............................................................................................19
Teams..................................................................................................................................................22
Module Review....................................................................................................................................24
Test Your Knowledge Questions:.........................................................................................................24
Module 02: The Dynamics 365 Security Model.......................................................................................26

Module Overview................................................................................................................................26
Purpose of the Security Model............................................................................................................27
Security Roles Explained......................................................................................................................27
Defining Permissions...........................................................................................................................28
Privileges.............................................................................................................................................29
Access Levels.......................................................................................................................................31
Options for creating Security Roles.....................................................................................................33
Security Roles and Business Units.......................................................................................................34
Assigning Security Roles......................................................................................................................35
Multiple Security Roles........................................................................................................................36
Security Roles: Layered Approach......................................................................................................37
Teams and Security Roles....................................................................................................................38
Module Review....................................................................................................................................39
Test Your Knowledge Questions:.........................................................................................................39
Module 03: Implementing Hierarchical Security.....................................................................................41

Module Overview................................................................................................................................41
Hierarchy Security...............................................................................................................................41
Managerial Hierarchy Security............................................................................................................43
Positional Hierarchy Security...............................................................................................................44
Module Review....................................................................................................................................45
Module 04: Knowledge Management.....................................................................................................46

Module Overview................................................................................................................................46
The Big Picture.....................................................................................................................................47
Searching the Knowledge Base............................................................................................................48
 Enabling Knowledge Search.................................................................................................................49
Module Review....................................................................................................................................52
Test Your Knowledge Questions:.........................................................................................................53
Module 05: Introduction to Processes....................................................................................................56

Module Overview................................................................................................................................56
Processes and Automation..................................................................................................................56
Business Process Flows........................................................................................................................60
Workflow Basics..................................................................................................................................61
Creating a Basic Workflow...................................................................................................................62
Convert a Workflow............................................................................................................................67
Module Review....................................................................................................................................69
Test Your Knowledge Questions..........................................................................................................70
Module 06: Business Process Flows........................................................................................................71

Module Overview................................................................................................................................71
What are Business Process Flows?......................................................................................................72
Enabling Business Process Flows.........................................................................................................72
Steps, Stages, and Categories..............................................................................................................76
Working with Multiple Entities............................................................................................................76
Conditional Branching.........................................................................................................................77
Create a Business Process Flows.........................................................................................................78
Mobile Task Flows...............................................................................................................................80
Module Review....................................................................................................................................82
Test Your Knowledge Questions..........................................................................................................83
Module 07: Dynamics 365 and Office 365...............................................................................................85

Module Overview................................................................................................................................85
Integration Options.............................................................................................................................86
Folder Tracking....................................................................................................................................86
Exchange Folder Mapping...................................................................................................................88
Types of Office Group 365 Groups Integrations..................................................................................89
SharePoint Integration Overview........................................................................................................91
OneNote in Dynamics 365...................................................................................................................95
Module Review....................................................................................................................................96
Test Your Knowledge Questions..........................................................................................................97
Course Review.....................................................................................................................................98
Module 01: Configuring Dynamics 365
Course Overview

Hello and welcome to Course No. 81060, Configuring Dynamics 365. My name
is Derik Bormann, and I will be your instructor. So this is actually the
companion course to customizing Microsoft Dynamics 365. So over the
course of this course, we want to just talk about the concepts around
what do you do when configuring the application. So a lot of this stuff
is going to go hand in hand with some of the baseline customization
principles that you'll be working with as part of your Dynamics 365
organization. So we want to look at topics that include just an overview
of how the configuration process works in Dynamics 365, so what are some
of the administrative settings, business settings, and items that you'll
be looking at. We also want to spend some time going in and really
looking at the security model as a whole, so how are you setting up
things like business units and users and teams and how do those work in
conjunction with things like security roles and access levels and
privileges so you can define not only what the users are doing inside the
application or able to do inside the application but also what's going to
be presented to them and what they're going to be able to see as they're
working through. We're also going to introduce the hierarchical security
options. So if you need a little bit more security based around who that
person is and what specific people they supervise inside an organization,
you can implement hierarchical security either at a managerial level or
at a position level to give yourself a little bit more flexibility around
your security structure. We're also going to talk about how the
knowledge management process works from a configuration standpoint.
Because when you think about how knowledge management works, it's not
necessarily just about service anymore. Knowledge management plays a
role in any number of different facets of an application, whether you're
doing employee self-serve, whether you're doing customer self-serve,
gamification, any number of different situations. So we want to talk
specifically about how that knowledge management piece relates to
Dynamics 365 and what the setup procedures are around that. We're also
going to look at processes and introduce you to some of the different
workflows and dialog capabilities inside the application. Now, there are
other courses out there that delve a little bit more into these types of
things, but we want to talk specifically on how they relate to a Dynamics
365 organization and what some of the baseline processes are that you'll
use as you're working forward. We're also going to look at business
process flows. And one of the exciting things that's been released with
Dynamics 365 is the ability to use kind of a visual designer on your
business process flow. So we'll look at how those are set up, how you
tie those two specific entities, what some of the requirements are and
how that structure of that business process flow might affect what users
are seeing as they're navigating through the application. And then
finally we're going to start looking at how Dynamics 365 and Office 365
work together. That line between the two individual applications is
really starting to kind of get blurred when you start talking about
OneDrive integration and SharePoint integration and even bringing in
things like OneNote and Yammer and some of the those things. So we want
to talk about some of the baseline things that you'll set up from a
configuration process inside the application as well. So all of this is
going to be kind of combined together with some of the customization
stuff that's available in other courses to really help you build and
structure a nice Dynamics 365 organization that you can use for yourself,
your customers, or any situation moving forward.

Module Overview
So in this module we want to start looking at some of the baseline
building blocks that you're going to use for configuring your
environment. It's more than just going in and defining how you're going
to do SharePoint integration and some of the those things. You really
want to understand what your business is going to be using Dynamics 365
as for a whole. How are your records coming into the application? Are
they going to be imported in from other sources? If so, how are you
going to handle requirements around records, how are you going to handle
that import process, how are you going to handle duplicate detection? If
you're working in an environment where you need to have people really
consistently looking at who's making changes and what changes were made,
are you going to enable auditing? How are your fiscal year settings
aligned with some of the goal situations that you would be working with?
And so we really want to take a look at how that all plays together as
well as some of the baseline functionality around setting up your overall
users and baseline security structure inside the application. So in this
module we're going to just look at kind of an overview as far as
configuring Dynamics 365, talk about some of the different areas of the
application that you can go in and some of the baseline settings that are
available inside there. We're going to introduce the concept of business
units from a Dynamics 365 standpoint and really looking at how those
business units are going to be the cornerstone for what you're going to
do from a security infrastructure inside the application. We're going to
talk a little bit about user management and setting up email
configuration for your individual users. So, again, user management,
depending upon the type of deployment that you're working with,
specifically from a Dynamics 365 standpoint, is really going to start
with Office 365, setting up your users inside that application, assigning
them Dynamics 365 licenses and then going into the application and
assigning them specific security roles to ensure that they can use the
application, and then depending upon what you're working with, how you're
going to go out and set up email configuration and set up mailboxes so
people can send and receive email regardless of how they're using email
inside the application. And then we'll also talk just a little bit about
how you use teams to extend functionality. Because in a lot of cases
it's not necessarily just going to be a user that's going to be working
with this individual information, it might be a team of users. You might
have people collaborating on an opportunity. And so in those situations,
what does the team structure look like and how are those teams going to
translate into what you would be looking at inside the application.
Configuring Dynamics 365
So every Dynamics 365 organization that you work with is going to have
some unique business settings that you can tweak per environment that
you're working through. And so what I want to do is talk just a little
bit about what those items are. Now, many of these, when you start
talking about some of the data management settings, collaboration
settings and document management settings, many of these we'll actually
get into in much more detail throughout the course of this actual course
itself, but I want to just start with kind of an overview as far as where
some of the baseline items will be that you'll be working with. And
those really break down into kind of the five areas that you see here.
You've got your administrative settings, which is really going to have
more of your generalized setup areas for the organization that you're
working with. This is going to have things like subscription management
if you're working with with Dynamics 365 online. This is going to have
some of your auto number settings. This is also going to have some of
your baseline system settings that you can go in and configure inside the
application itself. When we start talking about business management
settings, we're talking about anything that is specific to the business
itself. And a lot of the items that you'll see in here are going to
correlate with things like fiscal year settings and items like that.
We'll also talk a little bit about data management settings, and this is
where you can handle things like turning on sample data, this is where
you can some of the duplicate detection options that are available inside
the application as well as working with things like document management
for SharePoint, OneNote integration. And then we'll talk about some of
the collaboration settings that are available specifically when we start
talking about Yammer and social engagement integration and some of those
items. Now, on top of that, we'll also start looking at things like
security, we'll start looking at things like auditing. But this is kind
of an overview in regards to what some of the baseline items that you
would be seeing. So let's first just talk about your administrative
settings configuration. So all of your administrative items that you're
going to set up are going to be organization specific. So you do need to
keep in mind that these are -- some of these items do transfer over as
part of the solution process, but many of these have to be set up and
configured from inside the application. And so this is going to be
things like system settings. And we'll take you in here in just a second
and show you from a demonstration standpoint what you might do inside the
system settings scenario. This is where you can also look to see
notifications and resources that are available to you, workflows and
items that are taking place inside the organization as well as auto
number settings. Now, Dynamics 365 doesn't necessarily have a
traditional auto number setting as much as it does for specialized items
like cases and campaigns where they use a very specific numbering
convention. You do have a little bit of flexibility over how you're
going to control what that numbering convention looks like, but this
gives you a little baseline capabilities to see what you want to do with
that as far as going through. Now, the other option that you'll see is
your business management settings. Now, you don't do as much with
business management settings as we have in the past with this
application, just because a lot of the things have become standalone
features, but each organization will have kind of its own unique set of
business operation procedures and policies that they may need to
configure. Now, couple of things that you want to look at from this
business management setting. This is usually your company setup-type
situation, so when are you closed from an organization standpoint, what
services do you provide if you're using service scheduling, where are you
providing your services out of. Probably the biggest ones that you want
to look at in here from an application standpoint are going to be things
like your fiscal year settings, your sites, your currencies, your goal
metrics. Those are going to be some of the baseline items as well as the
automatic record and configuration rules. Kind of what we usually tell
people on this is a good rule of thumb is this is usually stuff that you
kind of set up initially as far as your organization goes and then you
just kind of adjust it as necessary. So if your fiscal year settings
change, you come in and you kind of set those up. Or if you're going to
be doing some different goal tracking functionality, you would then go in
and set up some different goal metrics based upon what it is that you're
trying to accomplish. Now, the other thing to remember with this, and
we'll talk more about this when we get into security roles, is business
management settings are really an administrative-type situation. So you
do have to have the appropriate rights inside your organization to be
able to facilitate this. And that's usually done through security role
setup inside the application. Data management is where you can handle
how the data is actually going to be interacted with inside the
application. And, again, we'll take you in here in just a few minutes
and show you a couple of demonstrations on this, but some of the biggest
ones would be like your duplicate detection settings. So, for example,
if you want to limit the potential for somebody entering the same account
into the application more than once, the duplicate detection rules and
settings are where you can actually go in and define what those rules
look like, are you doing a comparison on the account name and email
address, or are you taking into consideration the account number, what
are going to be the fields that you're going to use to define whether or
not this is a duplicate record inside the application itself. And the
nice thing about the duplicate detection settings is this is also where
you would have the capabilities to go in and actually run this at kind of
a high level. So instead of having it plug that information in as the
information is being entered, you could just do kind of a manual
duplicate detection job to see if there's any existing duplicates based
upon how you've configured information moving forward. This is also
where you can handle some of your data maps. So a lot of times what
you'll be doing is importing information into the application. And when
you're importing information in, depending upon where it's coming from,
maybe like an Excel spreadsheet or something like that, you may or may
not know how you want to put that information or what specific fields you
want to put that information into inside Dynamics 365. This allows you
to set up reusable mappings that you can use for any imports that you'll
be doing as part of the application. And then once those imports have
actually been run, the import area is where you can go in an actually
see, OK, what's the status of that import job, how many records have been
imported in, am I having any issues, am I having any items that I need to
be aware of as part of that situation. This is also where you'll be able
to do things like bulk delete. If you want to do kind of a mass delete
on records, you can set up kind of reusable job criteria that you want to
work with and then delete this information accordingly. This is also
where you can go in and turn on or off sample data. So if you're trying
to get just an overview as far as what's available inside the
application, sample data is kind of a nice way to do that because it will
already have some accounts and some cases and some opportunities set up
in there, but then obviously once you're ready to go, typically you come
in and kind of turn that process off, as well as things like ready-to-use
business processes. And we'll talk more about business process flows
when we get into the business process module. A couple of things that
you'll want to just keep in mind when you start talking about duplicate
detection and data import. Duplicate detection you have to be a little
careful of to make sure that you don't have very generic rules when
you're creating it. So try to find rules that are going to be more
specific. I want to look at a combination of the account name, the
account number and the email address. If it's just, you know, an email
address or just an account name, sometimes if they're too generic, you'll
get a lot of potential duplicate records coming into the application
where they may or may not specifically be duplicate records. And that
really can frustrate your users when they're working through it. So just
make sure, and we'll talk a little bit about this, as you set this
information up, make sure that you set this information up as specific as
possible. And also keep in mind that when you are setting up duplicate
detection jobs as far as scheduling to see if there are duplicates in the
system, you do have the capabilities to schedule those, but you can only
schedule those between 7 and 365 days. Now, as far as the data import
works, there's a lot of ways to get information inside a Dynamics 365
environment. Data import is really good for small volume-type situations
where you have data that's reasonably clean, there isn't a lot of
maintenance that has to be done on that situation. If you have to do a
lot of data that maybe has to be mapped or parsed or something like that,
there's different utilities out there that would give you the
capabilities to do that. Think of data import as very simplistic, I'm
only working with text files, CSV files, XML spreadsheets as far as
putting information in. If I have multiple files, I can actually put
those into a ZIP file to move them through, but I am really looking more
at just kind of small-based information when I'm going through. And I
also want to keep in mind that any information that I'm brining into
there from an individual file standpoint can be no more than 8 megabytes
in size. So as long as you're remembering some of those kind of key
facts from a data import perspective, the data import can be a really
nice utility to get you started and kind of moving in the right direction
from that standpoint. Another option that you have, and we'll delve into
this as part of the demo as well, is auditing. Now, auditing is nice if
you want to make sure that people -- who's making what changes inside the
system. Not only can you control what's being audited inside the
application, but once auditing has been turned on, you can actually go
into the logs and you can see who made what change at what time. Now,
auditing is one of those things where it has to be kind of turned on at a
few different levels. It has to be enabled for the entire organization
first. Once it's enabled for the entire organization, then you basically
go in and specify what specific entities you want to audit inside the
application. So I want to audit the account entity or the contact
entity. And then once you've enabled it at an entity level, then the
fields will actually start getting edited based upon -- or audited based
upon what items we've chosen for each individual field. And, again,
we'll go in and do just a little bit of a demo here in a few minutes so
you can see kind of how auditing works. The big thing to remember with
auditing is I wouldn't call this like a compliant solution. I would call
this as I want to have a snapshot in regards to who's made what change on
what day and what that change was. If I really need to go in and start
controlling things from a compliance perspective, auditing isn't
necessarily the best solution for that, but it can act as a very nice
starting point to get you moving in the right direction as far as keeping
track of what changes are being made inside the system. Now, we're going
to spend a lot of time on document management towards the end of this
course, but this is where you're really going to start getting in and
configuring your integration with SharePoint. Now, there's two types of
SharePoint integration that's supported. There is client-side SharePoint
integration and then there's server-side SharePoint integration. Now,
from a server-side perspective, that's also going to give you some
additional functionality such as OneNote integration, OneDrive
integration, Delve integration. Those give you a lot more flexibility,
and that's where you're really starting to see, from a trend perspective,
people moving. But, again, we want to at least mention here's where you
have the capabilities to turn on SharePoint integration. So if you want
to have a document library that's associated with a specific record
inside the application, this is where you can turn that on and define
what those functionalities look like. And then you have the ability to
actually go out and do some additional extensive integration with those
if you're a developer. But we're going to talk more about some of the
baseline functionalities, specifically when we get more into the Office
365 and Dynamics 365 integration module. And then, finally, the other
aspect that really starts to come into a Dynamics 365 organization is
this whole concept of collaboration. You know, do I want to bring
information in from other areas. A good example of that is the activity
feed in CRM that kind of tells you who's done what inside an individual
record inside the application. So one of the things that you have the
capabilities to do is actually replace that activity feed with like an
integration to a Yammer enterprise subscription. And this is where you
can go in and you can actually configure and use Yammer groups inside the
Dynamics 365 subscription. And these could be public groups, private
groups. We'll talk more about what that process looks like again when we
get into the Office 365 integration module, as well as we could talk
about things like social engagement and how you tie some of that
information together. But this is kind of a quick little overview in
regards to some of the baseline areas that you would be seeing from a con
configuration inside the application standpoint. So let's take a little
bit of time and just kind of explore what some of these baseline
configuration options look like inside the application. So as you can
see, we're kind of at your main screen that you would see when you open
up a Dynamics 365 subscription. But we're going to just go ahead and
we're going to head into settings first. So when I click on settings, I
can see there's a lot of different options. There's some around kind of
business management. This is going to have my templates as well as some
of my product catalog information. I've got my customizations area,
which is really going to be more from a customization perspective. But
then I get into things like my system area which is going to have my
administration and my document management, my auditing, email
configuration, more of the baseline functionality that you would be
looking at inside the organization. Now, let's first foremost kind of
start with the administration option. So I'm going to click on
administration, and I can see this is where that has some of the baseline
options that we've kind of talked about. Now, this is a Dynamics 365
Online environment. So one of the first areas that we can see in here is
subscription management. So this is where I can go in if I need to
purchase additional licenses for users, if I want to set up payment
plans, if I want to assign licenses to users or just have kind of an
overall look at my Dynamics 365 subscription. This is where I can do
that. Now, in order to actually be able to facilitate some of those
tasks, typically I would have to be a system administrator on my Office
365 subscription as well in order to be able to work through that. But
that's where I could go in and manage some of my subscription-based
functionality. The other thing that you'll see in here is my system
settings. And this is probably the biggest one that I wanted to show you
inside here because this is where I can manage kind of the overall system
settings for the application as a whole. This is going to have things
like just kind of general usage as far as am I going to allow IM
information; what is going to be my currency precision; if I want to do
blocked file extensions for attachments, which options do I want to work
with from there; if I have my own Bing Maps functionality, this is where
I can enable Bing Maps integration; if I want to do telephony with like
Skype or Skype for Business, this is where I can facilitate that from
kind of a click-to-dial functionality. So my general settings is going
to have a lot of kind of my custom help information. This is what's
going to have my integration with social engagement, whether or not users
see the welcome screen. This is just kind of the generalized information
that you would see inside the application itself. Now, the other thing
that you're going to see in here is your email integration. And we'll
talk more about email here in just a little bit. But this is where as an
organization I can set up kind of my default items for the organization
as far as how we're going to handle email processing, am I going to have
people using Outlook to handle email processing, am I going to be user
server-side synchronization or even the email router to a certain degree,
what are some of my options around that when I'm working through it.
When I start getting into things like reporting, couple of things that
you'll see in here is this is where I can classify my reports and define
how I want my reporting structure to work. But this is also where I
would have the capabilities to turn on Power BI visuals. So one of the
things that's now available with Dynamics 365 is the ability to associate
this and attach this to a Power BI subscription. And once you attach
this to a Power BI subscription, you now have the capabilities to take
tiles and items that are inside Power BI and surface them inside Dynamics
365 dashboards. And then in order to be able to facilitate and do that,
you would have to turn this functionality on. So this would be an option
where you would enable this, and now you would be able to consume that
information inside your organization. This is also going to have just
kind of generalized situations around goals and goal tracking, how often
you want your goals to be rolled up; your sales information, whether or
not -- how records are going to interact with that information. This is
also where you can work with your preview functionality. If you want to
do mobile client settings for your organization, this is where you can
set up kind of on-demand metadata syncing. This is where also if you
have any preview functionality that you would want to turn on from an
organization standpoint, this is where you could enable any of the
specific preview functionality, things like Organization Insights,
Cortana for Dynamics 365, some of your app design modules, so your new
application designer that ships as part of Dynamics 365, the overall
functionality that you would be looking at. So now in here from our
standpoint, if I just come down into here and I want to say that we're
going to see the Dynamics 365 message, we're just going to turn that off,
and then we'll just go ahead and turn off the welcome screen as well, and
then we can go ahead and click on OK. So these are just kind of my
default functionalities as far as system settings. So I would definitely
highly recommend setting some of this information up as you're moving
forward. Also from in here, this is where if I wanted to do Yammer
configuration as well as social engagement configuration, this is where I
could facilitate some of that as well. Now, we'll show you that in a
little bit more detail when we get into the Office 365 Dynamics 365
module. But let's go ahead and let's look at the business management
piece here as well. So if I click on business management, this is where
I can see kind of my fiscal year settings. So if I want to go ahead and
click on fiscal year settings, this is where I can define where I'm going
to be using that, primarily from a goal-tracking perspective. But this
gives me the capabilities to see what is going to be my fiscal year, what
do I want to use from an abbreviation standpoint, am I do more on kind of
a quarterly basis from a fiscal year standpoint, am I at monthly, how am
I defining what these situations are, and then how do I want this
information to display inside the application. Again, if you're doing
anything in regards to goals or items around goal tracking, the fiscal
year settings here really give you a lot of flexibility to be able to
kind of define and configure that. The other option that we talked a
little bit about was the data management process. And let's go ahead and
take a look at the data management process inside the application. So
I'm going to go into settings and data management. And probably the
biggest things that you'll see in here, like I said, is your imports,
your data maps, but your duplicate detection settings. And so if you're
looking at how you want to handle duplicate records inside the
application, this is where I can define what those look like inside my
organization. So when I go into my duplicate detection settings, this is
where I can actually set up kind of my default rules. So when do I want
the duplicate detection functionality to work at from inside the
application? Do I want it to take place when a record is created or
updated, do I want to look at it when the Dynamics 365 for Outlook goes
from offline to online, or do I want to handle it during the data import?
I can really just turn this functionality on from an organization
standpoint, and then any one of these combinations I can define how I
want to set this information up. And this is very nice, you know, I
would look at a little bit in regards to maybe initially, particularly if
you're coming in from an older system that you didn't have a lot of
duplicate detection options on, maybe you turn it off for import
initially so you can get the data into the environment and then you can
kind of configure your duplicate detection rules from there. And then
one of the options that you see over here on the side is this duplicate
detection jobs. And this is where I could kind of manually come in and
run those duplicate detection jobs if necessary. Now, the rules
themselves, if I cancel out of here and go into the rules, the rules
themselves are where I can define for specific entities what that process
looks like. So this is where I can see for the account perspective what
specific fields are we going to be looking at and trying to map out to
try to determine which one of these individual items is moving forward.
So, for example, let's just go ahead and open up this option here. So I
can see in here that this is going out and it's looking for accounts with
the same account name, it's basing the information on the account entity,
and it's matching it on the account record as well. So you defined kind
of a base record type and a matching record type. And then you come down
into here and you would specify for each individual option what specific
scenario you would want to look at. So in this case we're looking at the
account name field and we're looking for an exact match. And so if it
has an exact match, if spelling is exactly the same, it's going to deem
that as a matched record inside the application. Now, one of the things
that you'll see in here is you have to publish these. So even though you
define these individual rules and items, you cannot or they will not take
into effect into the system until you specifically publish them. Now,
let's just look at this from another aspect. So I'm going to go ahead
and just create a new one here. And I'll see that I have different
record types that I can choose from. So in this case I'm going to go
ahead and I'll choose account. I'll look for a matching record type of
account. I'm going to call this Derik's sample. And then I'll come down
into here and I'll pick what specific field I want to work with. So in
this case we want to look for account name and we want to look for either
exact match, same first characters or last characters. Let's do exact
match. And then let's come down here and also do email address. And
we'll do it exact match on this as well. Now, this is an additive
situation. So as I define each one of these items, it's going to be
looking at each one as a whole and then defining those specific
situations from a matching perspective in here. So this just gives me a
little bit of flexibility. Once I'm ready to deploy this, now I can go
ahead and hit save and close, then I could publish this rule, and this
would now take live in effect inside the system itself. Let's also take
a look at the auditing situation. So I'm going to just close out of my
role here, and I'm going to go into settings and I'm going to go into
auditing. So this is where you have all of your auditing capabilities
inside a Dynamics 365 organization. Now, the big thing to remember with
auditing is auditing is really kind of a three-tier scenario. It has to
be enabled at kind of three levels before you can actually go in and use
it inside the application. So the first area that you see in here is the
global audit settings. So when I go ahead and click on global audit
settings, this is really just going to take me to the auditing tab inside
system settings. And so this is where I now have the capabilities to
determine what it is that I want to audit inside the application. So the
first thing that I have to do is I have to start auditing. And when I
start auditing, now I can define what specific items inside the
application I want to audit. Now, one of the first options I have here
is audit user access. So this is where I can kind of audit who's going
in and accessing what information inside the application. And this is
really just kind of an all-or-none situation when you're setting this up.
The next option that you see in here is the individual entities or areas.
So these are really just broken down by those areas inside CRM. So when
you think about things like common entities, this is going to be things
like your account, your contact, your lead, your product, things that are
going to be used throughout the application itself. They're not
necessarily functionality specific. So they're not sales specific or
marketing specific. When you start talking about sales-related entities,
now we're getting into things that are sales specific -- opportunities,
quotes, orders, invoices. Now, what I can do here is I can just check
this box here, and if I check this box, it's automatically going to go in
and set each one of these items that you see here -- account, contact,
goal metric, lead -- all of this information to auditable. Now, that
isn't necessarily what you always want. So the other option that you
have is you can just turn this on and then at an individual entity-by-
entity basis, you could actually go in and then start auditing some of
those individual fields and entities. Now, I'm going to for right now
just go ahead and uncheck common entities, just turn on auditing at an
application level. Then I'll go ahead and click on OK. Then I'm going
to come into this entity and audit field settings. And this is where I
will click on kind of this option. And really this is just going to open
up kind of my customizations area inside the application. And so this is
where I can define for what specific entities I want to work with,
whether or not I want to enable auditing. So, for example, if I come
over to the account entity and I click on the account entity, this will
open up the entity definition for the account entity. And one of the
options that we'll see in here is auditing. And so once I turn on
auditing at an account level, now I will actually be auditing any fields
inside the application that have been set for auditing. So now I come
down into data services and I enable auditing, and now what this kind of
tells me here is really all the fields inside this particular option are
going to be enabled for auditing. So by default, once you turn it on at
a system level and then an entity level, you're really auditing
everything for that particular entity. If I wanted to, I could come into
here, and then I would have the capabilities to come down into the
individual fields -- let me save this here real quick. I could then come
into the individual fields, and these individual fields will tell me
whether or not they're actually being audited as part of the application.
Now, again, most fields will be audited. There's going to be some fields
like lookup fields and some of those things that just by sheer nature
aren't necessarily audited, but most fields will be audited. Now, the
way this auditing works is it only flags for an audit record if
information in that specific field has changed. So even though it's set
up for auditing, if somebody hasn't gone in and actually done something
to that particular field, that information will not be included in the
audit record itself. Now, I'm going to maximize this, and I can see
right in here where it says audit status enabled, this is what's showing
me what specific fields are being enabled for auditing. If I don't want
to, for example, audit the city field, I could go ahead, double click on
this, it will open up the field definition, I could just basically set
this from auditing enabled to auditing disabled, and then it will not
audit this information, even if it changes inside the application. Now,
the other option that I could do is I could just select multiple fields,
and then once I select multiple fields, then I have an option in here to
hit edit, and this will open up kind of a generalize process, and this is
where I could turn on or disable auditing for all of the selected fields
that I have. But the big thing to remember is once you have auditing
turned on, then it's going to go out and anytime a change is made, it's
going to register that inside the system. And then this audit summary
view will then show you an overall list of everything that's happened
inside the application. So when somebody's made changes, when somebody's
added an entity, any of those types of things, so you could see
specifically what's happened inside the application. Now, again, use
auditing kind of to your best situation. I would really recommend -- it
does take up a fair amount of system resources at time, so if you are
going to audit, make sure that you are very targeted in whatever it is
that you are auditing. But auditing can be a very nice way to just get
kind of a snapshot view in regards to what's taking place. Now, the
final piece to this configuration area is your document management. And,
again, we'll get into this in much more detail as we move forward, but
this is where if you want to set up like your SharePoint integration,
this is where we can define if we're going to use server-based SharePoint
integration or just kind of the list component as a whole, and this is
where we can actually set up OneNote integration, OneDrive integration.
And, again, when we get into the Dynamics 365, Office 365 area, we'll
show you these. But these are just some baseline configuration things
that you can do as an organization to kind of get the initial thing set
up and ready to go as you start moving forward.

Security
So one of the first things that you have to look at from a Dynamics 365
perspective is security. And when we talk about security, there's a lot
of factors that play into security as a whole. Those are going to be
things like who are your users, how are they logging into the system,
what records should they have access to withinside the application
itself, are you going to have groups of users or teams that are going to
be able to go in and either own records together or be used to facilitate
other functionality inside the application like record sharing and field
security profiles. These are all different aspects that you need to kind
of keep in mind, as well as security roles and business unit settings and
hierarchical settings. These are all aspects that really tie into the
overall underlying security of how a Dynamics 365 implementation is going
to take place. So if you go into settings and security, it will take you
right to this tab. And this is where you can really manage all facets of
the security structure that you're going to be working with as part of
the application. So over the rest of this module and into subsequent
modules, we're going to spend a lot of time inside this area here
defining all the different necessary points from a security structure
standpoint. Now, one of the first things that you have to kind of keep
in mind when you start talking about security is what are called business
units. And so a business unit is really a framework for how your
organization is going to be structured as a whole. And a business unit
contains the underlying core security principles for your application.
So it's going to typically consist of users, teams, and security roles.
And the combination of those kind of three elements are really going to
what's be used to define whether or not this user or a specific user has
access to all records inside a Dynamics 365 deployment or just a specific
subset of records inside a Dynamics 365 deployment. The nice thing about
these business units is these are also what's going to define kind of the
security boundaries. And so this is what's really going to determine
whether or not I can see my records or other people's records inside the
application. Now, when we start talking about business units, there's
really two types of business units in a Dynamics 365 environment.
There's what's called the root business unit, and so that's really the
top-level business unit. You'll see that on the next slide here in just
a second. But that's the one that gets created automatically when an
organization is deployed, and this is going to be kind of the top
underlying structure of your organization. And then from there you're
going have what are called child business units. And child business
units will basically represent other business units inside your
hierarchy. I always like to tell people think of it like an organization
chart. At an organization chart, you might have these different top-tier
items that you'll be looking at and then the individual departments that
kind of work their way down. It's that same similar concept. It doesn't
necessarily have to match your organization chart, it might be something
based upon different items inside your system, but it's kind of a nice
starting point that you can be working with. Now, let me explain that in
a little bit more detail. So this is kind of your root business unit.
So let's just say, for example, that I've installed and created a
Dynamics 365 organization for Adventure Works Cycles. When I do that,
it's going to create the root business unit for Adventure Works Cycles
that I can see inside the application. Now, because this is my
underlying root business unit, the big thing to remember is this always
has to be the top-tier business unit in my organization. I cannot have
any other business units that are on top of this or that are parents of
this particular item. The other thing is this always has to be enabled
from an application standpoint. So I do not have the capabilities to go
in and disable this or anything like that. Now, I can rename it. If I
don't want to call it Adventure Works Cycles, I certainly could call it
something else, but it has to exist and it has to be the top-tier option
that I would be working with. From there I can start creating child
business units. And so this is a real good example of where you might
see from a child business perspective. Now I've got different
departments. I've got my sales department, I've got my marketing
department, and then I've got my service department. But think of it as
however your organization structure might be set up. It might be
territories. You might have the northern territory, the southern
territory, east and west. You might have regions, you might have North
America, you might have EMEA, Asia, those types of different situations.
Every organization is going to be a little bit different. So you really
have to define, OK, what's my underlying structure for how we're going to
compartmentalize these individual groups of users and teams, and then you
can name these business units accordingly. And so the nice thing about
these business units is even if you set them up initially, if you decide,
OK, sales isn't really what I want to call this, I can always come back
later and I can rename them. I can always disable them or I can delete
them, and I can move them around. So like you'll see here, I also have
-- underneath sales I have channel sales and I have consumer sales, and
under service I have support and I have projects. The concept being here
that consumer sales is going to have all of the users and/or teams that
work specifically in consumer sales, channel sales is going to have all
the users and teams that work in channel sales and so on and so forth,
and sales might consist of my managers for the individual channel sales,
consumer sales area. These will now be the boundaries that will be
defined from a security standpoint inside the application. Now, if I
wanted to, I could always move channel sales somewhere else, if I felt
like that was a necessary part of the application, but this is where I
can really start setting up and defining what this security structure
looks like as a whole from inside my Dynamics organization. So let's go
ahead and take a look at the security information. And, again, we're
going to spend a lot of time in this area between this module and the
next several modules. But we'll go ahead and we'll go into settings and
we'll go into security. And so we can see I have my users, my teams.
Let's first talk about the business units. And realistically, if you're
new to Dynamics 365 and you're looking to kind of set up a secure
structure, business units is where you want to start. You want to make
sure that you have your business units defined first because when you
create new users and new items inside the application, those users are
going to have to be associated with a specific business unit. You always
can move users from one business unit to another; however, it's not
necessary -- there's additional things that sometimes have to happen. So
it's always easiest if you can have the business units defined first, and
then you can always go in and kind of create users from there and then
start associating them with specific business units inside the
application. Now, in this case, I'll just go ahead and click on business
units, and I can see that I have kind of a baseline business unit for my
organization, so this one just happens to be a Dynamics 365 instance that
has kind of a numeric number next to it. This is where I could now go in
and start kind of defining different business units underneath here. So
the first thing that I'm going to do is since this is my root business
unit is I can go ahead and I can click on new. And we'll just kind of
create that same structure that we just saw on the previous slide. So
I'm going to go ahead and create a new business unit called sales. And I
don't need a ton of information here. I can add some additional
information like phone numbers and address if I want to. But
realistically the only thing that I have to have here is the name of the
business unit and then what the parent business is going to be. All the
other information is really more from just kind of a reporting
capabilities inside the application. So here I've got sales, I'm going
to go ahead and hit this save and new button, and this is going to create
another new business unit that I can use, and I'll just call this one
service, and then I'll create another one called marketing. So we'll
call this service and save and new, and then I will create one called
channel sales and consumer sales. Now, on this consumer sales, I'm going
to go ahead and click on my parent business unit. And I'm going to click
on look up more records. And I'm actually going to change this consumer
sales to use sales as the parent business unit. So now I can see that
the parent business unit has been assigned to sales. Now I'll go ahead
and hit save and close. Now, I didn't do that when I created the initial
channel sales. And so I realistically would probably have wanted channel
sales to be part of the sales scenario. So one of the things that I can
do after the fact is I can click on channel sales, I can go to more
actions, and there's an option here to change parent business unit. I
click on change parent business unit, pick the business unit I want to
work with, and now I can go ahead and choose sales, and that will re-
parent this particular item for me. So this is a great way that, you
know, as you're setting this information up, you can kind of define how
you want this information to work. So, again, I'll just go ahead and
I'll add one more here for service. We'll call this portals. And I'll
set this parent business unit here as service and then save and close.
But this is a very important aspect and kind of the first critical piece
to what you're doing from a security structure. Once your business units
are in place, then you can go in and start handling the next tier to
this, which is going to be your users, teams, and then ultimately start
defining security access based upon security roles and other individual
items within the application.

User Management
Ultimately the people accessing the application are going to be what are
called users. And when you talk about user authentication from a
Dynamics 365 perspective, there's really two ways that that's kind of
handled. It's always handled through an external authentication
provider, but if you're still kind of using an on-premise deployment, it
uses your Active Directory for your local instance to authenticate that
user to Dynamics 365. And then once they're authenticated, then it uses
the Dynamics 365 security model to access how they control what they're
doing inside the application. The other option, if you're using Dynamics
365 Online, is it uses the Office 365 authentication to authenticate the
user. Once they're authenticated, then, again, they have to be assigned
a specific security role, an item inside the application, to be able to
access it. So you do really need to kind of think about who your users
are going to be and making sure that your users are added to the
appropriate area so you can work with them. Now, from an on-premise
perspective, if you're using kind of a traditional aspect, that will use
their domain account. So they will have kind of an Active Directory
account that will be created. So you have to add them into Active
Directory. Once you add them into Active Directory, then you can go
ahead and add them into Dynamics 365. Now, there's a couple of different
ways that you can do that. You can either add individual users just by
going in and clicking on the new button, defining what their Active
Directory login is. It will pick that information up work, and then you
can work with it from there, or there's kind of a wizard that allows you
to go in and select multiple users from your organization and then add
them and deploy them as part of the application. But either way you do
have to assign those users and associate them with a Dynamics 365
standpoint. And it is more of a manual process, and when you create the
user, you have to define whether or not they belong to what specific
business unit and then typically have to assign them a security role.
Now, we're not going to mess with on-premise too much at this point.
We're really going to focus on online because that's, from a Dynamics 365
standpoint, where you're seeing a lot more of the deployments take place.
And so let's just talk about kind of that online perspective when you're
working with it. So, again, every user that's going to be accessing
Dynamics 365 Online has to have an Office 365 account. And so all of the
authentication is done through that Office 365 account. So you do have
to go in and add them as an Office 365 user first. Now, the next piece
to this is you don't physically go into CR -- or into Dynamics 365 and
add them as a user. What you actually have to do is you have to go in
and assign them a Dynamics 365 license through the portal. And then once
you do that, then you will start to see them inside Dynamics 365, and
then you can basically start moving them around. And when you do that,
they will automatically belong to the root business unit inside the
organization. You can switch them to whichever business unit you want.
And then they will also not necessarily have a security role associated
with them. You will have to add a security role. But we'll show you
what that process look likes, and then we'll talk a little bit more about
the security role access here in just a second. So let's first look at
how you would add a user and set them up to be a Dynamics 365 user. So
first thing you're going to do is you're going to go to
portal.office.com, and you're going to log in to your Office 365
administrative center using your Office 365 admin credential. So
obviously you do need to be a Office 365 system admin in order to be able
to facilitate this functionality. But once you log in to your
administrative screen, you're going to see basically the administrative
center that you see here. The first option that you're going to see is
your users area. So this is where you can go in and add specific users
to your organization. So when you click on active users, it will show
you all of your individual users, and now all you have to do is hit add.
And when you hit add, it will ask you for user credentials that you want
to define. So in this case we'll just go ahead and call this person Tony
Smith, give him a username. Now as I go through, I have some generalized
information about what I can do with him. So if I wanted to kind of work
through generalized contact information, I could add that. The password,
this is where I can define what I want their password to be inside the
application. I can either have the system auto generate the password for
them or I can create the password automatically for them. And I will
just go ahead and create the password for them. And then I will uncheck
in this case make the user change their password just so we kind of have
it as we're working through. Then I've got roles. This is where I can
define different roles for the Office 365 administrator rights. Now, in
this case, it has nothing to do with what we're doing from a Dynamics 365
perspective, so I could just leave them as kind of a user. But if they
were going to do need to do some administrative tasks inside Office 365,
this is where I could define those options. In this case we'll just kind
of leave it from here. The biggest thing that you have to look at is
what you're looking at from a product standpoint. And so one of the
options you're going to see down here is your Dynamics 365 licensing. So
you'll come down into here, you'll pick your options for your Dynamics
365 licensing, you'll see that it does have all of your kind of
additional options like marketing and social engagement and those
options. Those you can just kind of leave on by default. Those are all
based upon your actual subscription options that you've chosen. Then you
can go ahead and hit add. And once you add, this will create the user,
this will then send out the passwords and do everything that you need to
do from that perspective. But this will create the user, make sure that
they're ready to go inside the application. And then it will eventually
create them inside your Dynamics 365 organization. It takes a few
minutes for them to actually show up inside Dynamics 365. But once
you've got them set up, they will then eventually show up in there and
you can assign them a security role. Now, let's flip that a little bit
and look at what that process looks like inside Dynamics 365. So now I'm
going to come over into Dynamics 365, I'm going to go into settings and
security again. And I'm going to go over into users. Now, I don't
necessarily see Tony at this point, and that's fine. It takes a little
bit of time sometimes for that information to proceed over. But one of
the things that I can see is as users are being added into this, there
are different security roles that I could look at to kind of see who's
working through options. And one of the options that I see here are
users with no security roles assigned. And so now that I've clicked on
users with no security roles assigned, Tony has now shown up in here
because it's propagated across. So now I can go ahead and assign Tony a
security role. Now, we'll talk a little bit about what security roles
are here in a little bit, but this is where now Tony is ready to go, he's
a part of a business unit, you can see he's a part of our core business
unit. If I wanted to, I could -- from this perspective, I could go out
and I could change his business unit to be a different business unit
inside the application. So I could say he's actually going to be a
member of sales. This will then change his business unit. And then I
can assign them to a security role based upon those options. But this
gives me kind of a nice starting point to create those users and then
assign them security roles inside the application. A few other things
just to kind of remember when it comes to users. Probably one of the
biggest areas that we get questions on when we start kind of doing this
is particularly with newer organizations and newer people is you do not
have the ability to delete users. And that's very intentional. Because,
if you think about it, users can own records inside the application, and
if you delete a user, you might now have potentially all of these
orphaned users inside the application. And so one of the things to
remember is you can disable users and you can prevent users from actually
logging into the system by disabling users. From an Office 365
perspective, if you don't want them to have a license anymore, you still
need to go into the Office 365 administrative area and remove their
licensing. But disabling a user will prevent them from accessing the
system. So, remember, if you have somebody that you no longer need to
have access, you can't delete them, you do have to physically disable
them and then go in and remove the license from there. As you saw what
we did with Tony, I can change the business unit, I can move a user or a
team from one business unit to another. One thing to remember, and we'll
talk more about this when we get into the security module here -- or the
security role module here in a little bit, all security roles that are
associated with that user are removed. And so when you move somebody
from one business unit to another, they really don't have any access to
the organization until you assign them a security role. Even if they
already had a security role in their previous business unit, that's
removed. Now, the process that we did of changing the business unit was
pretty quick. Be aware that if you have somebody who's been in your
organization for a while and now you change them from one business unit
to another, that can take a fair amount of time. I've seen it take up to
five, ten minutes, depending upon how many records they own and other
factors inside the organization. So I do recommend that if you are going
to change somebody's business unit that's been around for a while,
probably try to do it during off-peak hours or at a scenario where
they're not going to be logged in. Because the other thing that takes
place is if they're currently logged in when you change their business
unit, A, that will also increase the length of time that it takes to do
that, but as soon as that process is complete, now they'll be locked out
of the system because they won't have that new security role. So you
definitely want to, if you're going to work with users and change their
business units, do it off-peak situations. It makes it much easier. And
then the other situation is if you're using Dynamics 365 Online, you can
federate it with a local domain account. So instead of using like, you
know, Derik at, you know, test.onmicrosoft.com, if I have a local
microsoft.com domain that I want to use, I can do that. There's some
additional setup that has to be done. You have to take their local
Active Directory and you have to sync it with Azure Active Directory in
order to be able to facilitate that. But the nice thing about that is
now I can use my local domain to sign on with my Dynamics 365 Online
account. So there's a lot of different options around, you know, user
standpoints and creating them. Just be aware that, depending upon what
environment you're working with, whether it's on line or on-premise,
there's different setup and configurations options that you might need to
take into consideration.

Email System Settings and Configuration

Another aspect that you need to keep in mind when you start talking about
users and configuration from inside the application is the whole concept
of email. So you think about how you might use email in a Dynamics 365
perspective. Obviously you might have users who are sending and
receiving emails to prospective customers as you're working through it,
but you might also have situations where you start talking about users or
queues sending and receiving emails as part of the application. So one
of the first things that you have to do is you have to do kind of your
email configuration. And so there's a few different options that are
involved with email configuration inside a Dynamics 365 implementation.
The first option is really setting up what are called your email servers
profiles. So this is where you define what type of email server you're
going to be used to process information, particularly when you start
talking about server-side synchronization. And server-side syncing is
what's going to allow you to do things like Exchange folder syncing.
This is what's going to give you a little bit more around some of your
more advanced email processing situations. This is where you might be
seeing people who historically use the email router transitioning over
into server-side synchronization. The nice thing about the email profile
is you define what the server profile is, then you can define defaults
for your organization. So then you can go into actually your
configuration settings and you can define as an organization as a whole
how you want to handle email processing. Then you can go in and you
actually start defining mailbox information and what user is going to use
what information from a mailbox perspective. The other option that
you'll see in here is server-side synchronization processing. As you've
enabled server-side syncing, this is where you would also have the
capabilities to go in and define and see what's taking place from a
performance perspective. And if you were using the email router and you
decided to transition over into server-side sync, this is where you would
also have the capabilities to kind of migrate some of those processes.
So what I want to do next is just kind of take you into the application
and show you how the email configuration piece works inside the
application. So if I go into settings and email configuration, the first
area that I'll see in here is my email server profiles. And so this is
where I can define the different email server profiles that I'm working
with from inside my organization. So the first thing that I see in here
is Microsoft Exchange Online. And the reason why this one has been
precreated is because I'm using Dynamics 365 Online with an Office 365
subscription and Exchange Online. So the good thing is is if that's your
typical environment that you're working with, you don't have to go in and
configure a server profile. If you're using kind of an on-premise
version and you have an on-premise Exchange Server, you would have to
create and define a server profile that you would want to work with.
Now, in this case, we'll just go ahead and open up this generalized
server profile. And so what I can see is here it tells me what type of
server that I'm working with. And so this is where I could define if
it's an Exchange Server, if it's a POP server, but this is where I can
define what specific items I want to work with. And then depending upon
what the situation is, I will also have the ability to define server
addresses, so what is the URL of the server I want to work with. But
being that this is an Exchange Online, I don't necessarily have to define
a ton of information around this, but this is where I can set up the
individual profile and define how that information is going to work. You
have to have at least one profile set up in order for the organization to
work. Once you have your profile set up, then you can start getting into
the individual configuration as part of the application. Now, there's a
couple of things that you want to consider. There's the individual
mailbox perspective, and then there's the actual organization defaults as
a whole. So if you remember when we were talking about administration
and we went into some of the admin settings earlier, we had the ability
to go in and look at that email area. This is where I can define kind of
defaults for my organization around email processing as a whole. Now,
this is taking just a little bit, so let's just go ahead and go into
administration. So if I go into email configuration settings, this is
where I can define my organization default. So the first thing that it
says here is how do I want to handle configuring email processing. So as
an organization, I can determine whether or not I want to use server-side
synchronization or the Dynamics 365 email router. Now, realistically
you're starting to see most organizations transition to server-side
synchronization just because of the flexibility that it offers. There
are going to be situations at some point in time where potentially the
email router could be deprecated. But for the most part, as it exists
today, it's still a viable option, but most of the areas that you have
seen here are around server-side synchronization. So the first thing
that you have to say is what's the default profile that I want to use.
Now, we only have one server profile. That's that Exchange Online
profile that was created for us automatically. But if we had multiple
profiles, this is where I could specify kind of the default for the
organization and then decide how I want to handle incoming email
processing, outgoing, so on and so forth. So incoming email processing,
how do I want to handle that? Do I want to use Dynamics 365 for Outlook?
Do I want to use server-side synchronization or the email router? How do
I want to work with that? So you've got a couple of different options
when you start talking about incoming. Incoming you can use Outlook, you
can use server-side synchronization or email router, or you could use a
forwarding mailbox where it's being forwarded to one area first and then
email activities are being created from there. Typically speaking, most
of your users probably will be using the Outlook client in some
perspective. So you'll usually use incoming as Dynamics 365 for Outlook.
Outgoing, same type of situation except for obviously since it's outgoing
processing, we don't necessarily have the for mailbox option. So I can
either use 365 for Outlook or I can use server-side synchronization or
email router. This is specifically defined based upon what I've chosen
up here for processing email, which in this case I've set as server-side
synchronization. And then for appointments and tasks, it's kind of the
same thing. Typically what we recommend from a best practice standpoint,
usually if you're going to use the Outlook client, people will use their
incoming profile with Outlook, their outgoing with server-side
synchronization, and then their appointments, contacts and tasks as
Dynamics 365 for Outlook. If you're not using Outlook, then obviously
server-side synchronization or email router for both incoming, outgoing
as well as appointments and tasks works. And the reason why we recommend
if you're using the Outlook client to use server-side synchronization for
outgoing is because that way it will just process it automatically if
there's like a workflow that's generating an email. Otherwise that
person's Outlook physically has to be opened in order for it to process
that email. So you could run into situations where things aren't being
processed in a timely fashion because the person's not logged into
Outlook. It just kind of eliminates some of those different options
available when you're working through it. But in this situation, now I
have the capabilities, if I wanted to, to work with some of the other
functionalities as far as like folder-level tracking and some of those
options. But in this case we'll just go ahead and click on OK. And now
the final stage to this would be the mailbox processing. So this is
where I would go into my mailboxes. And as opposed to past situations
where all of the email information was managed inside the user account,
with Dynamics 365, each user or queue will have a specific mailbox record
associated with it. And so this is what's going to define their mailbox
associated with their user account. It's going to have their email
address and it's also going to have some of their generalized
information. Now, as you can see, it's got kind of my default
information for how it's going to be processing information. Each user
can have their stuff associated individually based upon who they are. So
for each user you can have an incoming, outgoing and tasks and
appointments option. If I wanted to, I could apply the default email
settings, and this would look at what whatever I had previously
configured and then adjust that accordingly. But in this case I can just
go ahead and set this to whatever I want for this user. Then I have to
go ahead and approve the email. And this is a very important step. If I
don't approve the email, then I run into situations where it doesn't
allow me to process that information as I'm moving forward. So the
approving the email is the first and foremost step in regards to working
through it. Once the email has been approved, then I can do what is
called test and enable mailbox. So you have to approve the email first,
then you go ahead and hit test and enable, and this will run a test and
just ensure that everything is going to work and make sure everything is
OK. And then you can go ahead and, once that's approved, then it will
start processing email. So that's why, if you remember there was a
couple of times where it said email has -- you have pending emails
because things haven't been approved, it won't process emails for a user
account until you test and enable the mailbox. So the first thing you
want to do is come in, make your changes to the profile, hit save. Once
you save it, then you can approve the email address. After the email
address has been approved, then you can test and enable. You saw that
first time when I hit approve I got a little bit of a message. That's
just because I didn't save it. Once you save the profile, you can
approve the mailbox and then do a test and enable. And once the test has
been done and processed, then it will come in here and refresh and tell
you that everything looks OK. And once you know that everything has
worked OK, then you can go ahead and start using and sending and
receiving email inside Dynamics 365.

Teams
Sometimes just using individual users is not really going to be conducive
to what it is that you want to accomplish in the application. And so
sometimes using teams can be a real beneficial option. What teams are
are groups of users that you're kind of categorizing together. So, for
example, you might have sales users and you might want to create a team
for sales users. And the reason why you would do that is now you go in,
assign security roles to that team to use for ownership scenarios. Let
me give you a good example of that around like enterprise-level accounts.
So you might -- if you're working at a traditional kind of small business
scenario, you might have one sales rep or one account executive that
manages a specific account. They're in charge, they're the owner. But
when you start talking about large-scale opportunities at an enterprise
level, you might have teams of people that are managing that account
together. So instead of assigning that account to an individual user and
then having to share it out with all the other subsequent team members,
you would be able to actually assign that account to a team. And now
everybody who's a member of that team can own that account together. And
now they can collaborate and they can work with information from there.
The teams can be used for a variety of different things. They can been
used for record sharing, they can be used for field security profiles.
They have a lot of different options that you can be working with when
you start talking about teams. Now, teams can just exist and you can
just use them for record sharing, or teams can actually have a security
role. Just like a user could have a security role, a team can have a
security role assigned to them that basically tells us how that
information is going to work when they're going through it so now these
individual team members can manage these items together. There's two
types of teams in a Dynamics 365 implementation. There's what are called
owner teams and there's what are called access teams. And so let's just
talk a little bit about what an owner team is versus an access team. So
an owner team is exactly what it would sound like. An owner team is a
group of users who will be owning records inside the application. So
instead of having just an individual user, you're going to have a group
of people owning a record together. Typically when you're using owner
teams, these are teams that you're going to know kind of who the members
are ahead of time. So you're going to know that the enterprise team
consists of these five people or the admin team consists of these five
people. So they're pretty static when you're creating them inside the
application. And they can be used from a reporting perspective. And
access team is a little bit different. An access team is basically
saying, you know, I don't necessarily know who's going to need access to
a specific record on any given time. So I want to be able to kind of
dynamically associate that with individual users. So what an access team
does is it uses a concept of a subgrid on an individual record, and as
you add members to that subgrid, it automatically creates this access
team and then adds and removes members of that team automatically. This
is great whenever you need kind of those dynamic capabilities and when
you have different rights that you might want to work with as part of
those. And we're going to show you just a little bit around both of
those. We won't necessarily show you the subgrid component, but we'll
talk about the access teams and the templates around each one of those as
part of the demonstration. So let's first just look at teams in general.
So I'm going to go ahead and I'm going to click on teams. And you'll see
that this shows me kind of all the different teams that are associated
with this organization. Now, when an item is created -- let me actually
switch this here. When an item is created, like a business unit, a team
is automatically created for that business unit. And those teams, and
that's where you see this all teams here, those teams you can't really
manage memberships on. The memberships of those teams are automatically
controlled from within Dynamics 365. So as I add users to the sales
business unit or the service business unit or I remove users from those
business units, the application itself is going to kind of dynamically
control who is a member of those teams. So those I don't necessarily
have the capabilities to tweak. But I could create my own teams kind of
as necessary. So I could, for example, go into new, and it's going to
say, OK, what do I want to do here? I'm going to call this sample team.
I'm going to define who the administrator is going to be for this team,
and I'll just make myself the administrator. And then what is the team
type? Is it going to be an owner team or an access team? Typically
speaking, if you're going in and you're manually creating a team, it's
probably going to be an owner team. And the reason why it's going to be
an owner team is because these are going to be the teams that, generally
speaking, will create records. Usually with access teams, I mean, you
could define it as an access team, but when you start creating access
teams, it's much easier to use what are called access team templates to
kind of facilitate that. So in this case we'll just create this as an
owner team. Now I'll go ahead and hit save, and that will save the team.
And now I can add users. So in here where it says team members, now I
can come in here, I can hit add team, and now I could look to define who
are going to be the members of this team. So I'll add myself, maybe add
the CRM admin, and then I just kind of define my team members from here.
At any point, if I wanted to, I could convert this record to an access
team. I also could assign security roles. And we're not going to do a
bunch with security roles quite yet, just because we're going to revisit
those in the next module, but this is where if I wanted to this for truly
owning records, this is where I could define a security role associated
with this team. So that's an ownership team. Let me close out of here
real quick, and let's go back into security and access team templates.
An access team template is a little bit different. An access team
template is what you can use to kind of dynamically share records inside
the application. And so what ends up happening is you enable an entity
for access teams. So if you go into the settings and customizations and
you click on the entity definition, there's an option there that says
access teams, and you check the box for access teams. Then you can come
in here and create an access team template. And then what happens in
here when you create this template -- I'm going to just call this sample
template -- you pick the entities, so in this case it's only going to
show the entities that have access teams enabled, and then you pick what
rights you want them to have. So I want them to be able to read and I
want them to be able to write. And then I can hit save and close. And
so now what happens is whenever somebody is added to this subgrid or
whenever somebody is associated with this access team, they are going to
get write and edit -- write and read privileges to this particular
record. Now, we'll show you this, when we get into kind of another
module, we'll show you the actual practical application of this, but it's
something that has to be kind of modified on the form itself, but this is
at least the precursor to how you can set that up. You'll notice we're
not setting up the teams, we're just defining the templates. The teams
actually get created automatically when you add this subgrid that
references this access team template to a specific record.

Module Review
Dynamics 365 provides you with several different configuration screens
that you can use when you want to modify specific settings inside the
application, maybe like auto numbering for specific entities or working
with document management settings. Each of these options are
organization specific, which means that they only apply to the
organization that you're working in. However, a lot of these options can
be included in solutions when you're working with it and import it into
other environments and other scenarios. So the nice thing about using
your configuration settings is you really do have the capabilities to go
in, like with your duplicate detection, and set up how you want to handle
duplicate detection withinside the application. You also have that as a
baseline for your security principles inside the application. And this
is where you can start with kind of your cornerstone of security which is
business units, which are really the framework for how you want to handle
Dynamics 365 security inside the application. From there you then have
to go in and set up your users. So each user that you want to work with
will have to have a specific user account. The process for creating
users is going to differ slightly depending upon whether or not you're
doing online or on-premise customers, but regardless of what the method
is, once the user is authenticated to the application, then the Dynamics
365 security module is going to take over, which we're actually going to
talk a little bit more about on the next module from that perspective.
As you're working through it, typically speaking, you will see that
access and control is generally handled at a user level. However, there
are situations where teams can come into play. And the nice thing with
teams is they do give you the capabilities to actually have a little bit
more flexibility on how you want to handle who owns specific records
inside the application as well as how you want to facilitate sharing data
amongst individual users as well.

Test Your Knowledge Questions:

1. Which of the following options are available when creating a Duplicate Detection Job? (Check
all that Apply)

 It can be scheduled. *
 It can delete duplicates.
  It can send Notification. *
 It can be created for any entity.

Explanation: When creating a duplicate detection job it can only be created from entities that
have duplicate detection enabled and have at least one published rule. The Duplicate
Detection job itself. cannot actually delete records.
Reference: Configuring Dynamics 365

2. Which of the following entities does not have the ability to configure auto-number from within
Settings – Administration – Auto Numbering?

 Accounts. *
 Cases.
 Campaigns.
 Orders.

Explanation: Dynamic s 365’s Auto-number settings are located under Settings –

Administration – Auto Numbering. The feature only applies to Contracts, Cases, Articles,
Quotes, Orders, Invoices, and Campaigns. No other entities can be added.
Reference: Configuring Dynamics 365

3. Which of the following statements are true about the root business unit in Dynamics 365?
(Check All that Apply)

 It cannot be disabled. *
 It cannot be deleted. *
 It can be renamed. *
 It can have a parent business unit.

Explanation: The Root Business unit is the main business unit for an organization. It is created
when the organization is created and will receive the name of the organization. It cannot be
disabled or deleted and cannot have a parent business unit attached to it, as it needs to be the
top level business unit. It can be renamed if needed.
Reference: Business Units

4. Which of the following statements about teams in Dynamics 365 are true? (Check all that
Apply)

 Each team must belong to a business unit. *

 Team members must all come from the same business unit.
 Each business unit has a default team that is created. You cannot add/remove users
to it. *
  Dynamics 365 teams can own records. *

Explanation: Every team that is created in Dynamics 365 must be associated with a business
unit, but the members of the team can come from any business unit.
Reference: Teams

5. CRM has three synchronization methods available for syncing emails, contacts, appts., and
tasks. It is possible to use multiple methods for syncing. Which of the following configurations
are valid? (Check all that Apply)

 A user’s mailbox, can use the Outlook client for incoming email, and appts., tasks,
contacts, and Server-side sync for outgoing *
 A user’s mailbox, can use the Server-side Syncing for incoming email, and appts.,
tasks, contacts, and Outlook for outgoing Mail *
 A user’s mailbox, can use the Outlook client for incoming email, and appts., tasks,
contacts, and Email Router sync for outgoing mail *
 A user’s mailbox, can use Server-side Sync for incoming email, and appts., tasks,
contacts, and Email Router sync for outgoing mail

Explanation: Organizations can either process email using Server-side Syncing or Email Router.
It is not possible to use both for processing

Module 02: The Dynamics 365 Security Model

Module Overview
We started laying the groundwork a little bit in Module 1 for the topics
that we're going to discuss here. But security is a really big aspect of
how you're going to handle your 365 or your Dynamics 365 implementations.
If you have a poorly designed security structure, that's not only going
to cause problems from maybe having the wrong people have access to
information, but it also could really put the information in the wrong
hands which could have some very serious consequences as you're moving
forward. So we talked a little bit about in the previous module this
whole concept of business units and using business units as your
structure for your organization. In this module, what I want to do is I
want to expand on that a little bit more and I want to start talking
about the remaining items that are involved in a 365 application
security. So we're going to start talking a little bit about the
security model and what is the intent of the security model inside
Dynamics 365. So not only how does it work to control access to data but
also how it controls access to just what people can see inside the
application, do they have access to get to sales or service and whatnot
as you're moving forward. We're also going to look at how we work with
security roles and how to create security roles and how the different
concepts of access levels and privileges work to control what people have
access to. And then we're also going to expand kind of on the users and
the team stuff that we talked about in the last module and really look at
how they work with security roles and how the combination of having
somebody be an individual user and a member of a team and then having
that associated with a security role truly can give you a lot of
different options around who can do what inside the application.

Purpose of the Security Model

As we talked about on the previous slide, the purpose of the security
model is to do more than just provide record access. It's also really
going to define what specific actions that a user can take on a specific
record based upon who they are. So it controls access. So it looks at
who you are, and it also looks at who owns that record. So it says, OK,
this record is owned by Derik, and you're Derik, you should have access
to it. Or this record is owned by Derik but you're not Derik, should you
have access to it. So it really looks at who you are and determines
based upon who you are and other factors whether or not you should be
able to physically go into that record. The other thing that it does is
it controls access to specific UI elements inside the application. So,
for example, you can do what are called role-based forms where it can
look at what specific security role is associated with your account and
now determine what version of a form for an account you should be able to
see. Or dashboards. Maybe you should only have certain dashboards
available to you if you're a salesperson. And if you're a service person
that has a service security role associated with it, now you should have
these different dashboards. So it really looks at who you are and
determines whether or not you can actually perform specific
functionalities or what items should be presented to you. The other
thing that it does is it controls access to specific features. So, for
example, you might be a company that puts their account representatives
on like a probationary period for six months and says, OK, for the first
six months that you're with us, we're going to give you very limited
capabilities to actually do anything with the data. For example, I'm not
going to let you export the information to Excel because if I do that,
maybe you can now leave and go be with our competitor or something like
that. So the other thing that's nice with these security roles is I
could control what users can do, can they -- do they have access to use
the mobile application, can they print this information. So I can look
at specific features of the application and limit what they can do from
within there. And then the other thing that's nice with the entire kind
of concept of the security model is it really does simplify what users
are going to see from within the application. Because if I don't have
access to contacts or I don't have access to cases inside the
application, I'm just not even going to see them. So from a navigational
standpoint, it also tailors what people are being presented with on the
screen. And if you don't have the ability to work with that specific
option or you don't have privileges to work with that specific option, it
just doesn't render. So it makes it much easier for people to only focus
on the subset of information in the context in which they are working in
order to see exactly what they need to work with.
Security Roles Explained
So as we talked about, a security role is the baseline functionality for
who has access to do what inside the application. So it looks at who you
are as a user or a member of a team that you belong to, and then it
defines what you can do. So what it does is it actually associates
permissions. And those permissions are actually defined by using what
are called privileges and access levels. Now, we're going to talk about
both privileges and access levels here just in a little bit, but the
privilege at its basic scenario says as a user, you have the ability to
delete accounts. An access level says to what degree can you perform
that functionality. So I can delete accounts, but can I only delete
accounts that I own or can I delete accounts that are owned by other
people. And so these are where you now really start to delve into what
people can do. Now, every user, as we've kind of talked about moving
forward, has to have at least one security role associated with them.
Without a security role, they can't access the application, even though
they already belong to a business unit. Now, you could do a couple of
different situations when you start assigning security -- you know,
assigning users to security roles. You can just associate the user with
a security role. You can actually go in and create new security roles
and then assign them to those security roles. There's different options
for working with users on security roles. And we'll talk more about what
those different options are as we move through and start working with it.
Out of the box, there's several security roles that are already a part of
the system from a Dynamics 365 standpoint. And these are some of your
more common roles. So these are going to be things like sales manager,
salesperson, marketing professional, all of these different roles that
you might normally see. Now, you have the ability, if you want to, to
kind of use those to get you up and running as quickly as possible, or
you can actually go in and kind of rename those and modify the specific
privileges and access levels in each one of those to fit your
organizational needs. So you have a lot of tailoring options available.
You can use the ones that are there, you can modify the ones that are
there, or you could just create a whole bunch of new ones based upon
whatever your specific needs are and then define the security structure
from there when you're going through. The only one that you really don't
have the capabilities to mess with a whole lot is the system
administrator role. The system administrator role by default will give
anybody who has that role pretty much complete access to do anything
within the application. Now, obviously you're not going to give every
single user the system admin role, but you do have to have at least one
person who has the system admin role. If you try to remove that one
person, the system will not let you do that. So everybody has to have at
least one security role. And the system will have at least one person
who will be assigned the system administrator role, and that role does
not have any modification capabilities. Now, as far as working with the
roles, and we'll show you this, you're really just going to go into that
settings and security and security roles and then start modifying those
to fit your specific needs.
Defining Permissions
So let's look at these security roles a little bit. So I'm going to go
into settings, and I went into security, and now I went into security
roles. And so these are those out-of-the-box security roles that we
talked about that you'll see. And then depending upon, you know, if you
use some of the preferred solutions that are out there, additional
security roles might get added to the system. But these are typically
the out-of-the-box security roles that you would see in kind of a
standard CRM -- or a Dynamics 365 implementation. Let's just open up,
for example, the salesperson security role. So I'm going to go ahead and
open that up. We'll maximize this. So it tells me what role it is and
it tells me what business unit it belongs to. And we'll talk a little
bit more about roles and business units here in just a little bit. And
then across the top you're going to see different tabs, and these tabs
are going to represent different types of records inside the
organization. So obviously like your core records are going to be things
that aren't necessarily module specific. These are going to be things
like your accounts and your contacts and your opportunities. These are
going to be more of your entity-based permissions. And so these are one
of the first things that you'll see is there's this concept of entity
permissions which allow you to control privileges and access levels at an
entity level. And as I go across, I can see from a marketing perspective
I have campaign, marketing list, then I get into orders, invoices. These
are more of broken out by module. These aren't necessarily going to
change. These are all built-in functionality around the application.
The privileges and the actual depth to which people can do stuff, that
can be modified. But what's actually presented in this screen, that's
not necessarily modifiable from an application standpoint. Now, the
other thing that you'll see, if I scroll down here, is I get into things
called like miscellaneous privileges or task-based privileges. Most of
these entity-based privileges allow me to really go down to a very depth
or very detailed situation where this person can create a record, delete
a record or update a record, and I can define five or six different
levels on regards to how I want them to be able to work with that. Down
here on these miscellaneous, these are basically just yes or no
functionality. Can they print, can they export to Excel, can they work
with Outlook, what are some of their different options around being able
to access these options. So you'll see some of these privacy-related
options, which are basically called task-based privileges, which are
truly just kind of yes or no functionality. So each tab will have
entity-level permissions and then kind of task-based privileges, which
will be kind of your yes or no based upon what that functionality is.
The only other option that you're going to see in here is this custom
entities option. As you start adding custom entities to the application,
so if you've gone into the customization course and you've learned how to
add entities and fields, as you started adding custom entities, they will
show up in here. And remember that by default when a new custom entity
is added, nobody other than people who have the system administrator
security role associated with them will actually have access. So you do
need to come in after the fact for every security role and grant access
to the different privileges and access levels, which we will talk a
little bit about and show you a little bit about here in just a couple of
seconds.
Privileges
So in the previous example, we saw the concept of security roles and we
saw the different little circles that you can click on to determine who
should have access to what. Let's now dive into that in a little bit
more detail and explain what those circles kind of mean. So there's a
couple of different elements at play here. There's the concept of what
are called privileges, and then there's a concept of what are called
access levels. Think of privileges as really the most basic unit of
security inside the application itself. So they define what I can do for
each entity on the system. So, for example, can I create a contact, can
I go in and can I look at accounts inside the system, do I have the
capabilities to delete cases. That's what we're talking about from a
privilege perspective, is at an entity level what can I do with that
particular entity, can I update, can I delete, what are my different
options. So you have to start with looking at the privileges first.
Now, let's dive into these privileges a little bit and let's look at this
from kind of a security role standpoint. So if you see here I have my
account entity. So my account entity really has eight different
privileges that are associated with it. Can I create an account record
in the system, can I see it, can I edit it or write to it, can I delete
it, then I've got append, append to, which we'll talk about here in a
couple seconds, can I assign and account to another user, and then can I
share an account. So these are your basic privileges. Now, you'll
notice that some of these entities don't necessarily have all of the
privileges available to them. Some have all; some have less. It just
kind of depends. What typically kind of defines that is the ownership of
the entity. So is this a user-owned entity versus an organization-owned
entity. If it's a user owned organization entity you typically will have
a few more privileges associated with it as opposed to just some of the
out-of-the-box functionality or owner-based functionality. So these are
kind of your baseline options that you would see from a privilege
perspective. Now, let's delve into these in just a little bit more
detail and talk about what some of the different options are. So we
talked about create. That one makes a lot of sense. Can I create a
record for that particular entity, so can I create a new account. Read,
can I see it in the information. Write, can I edit, so can I edit
accounts within the application. Delete allows me to delete a record.
Let's talk about append and append to. So append basically means can I
attach this entity to other records. So, for example, you're going to
have this concept where you're going to have an account record inside
Dynamics 365. That account might have multiple contacts that you want to
associate with it. In order to be able to associate contacts with an
account, you have to have append privileges on the contact entity. So if
I don't have append privileges on the contact entity, I can't associate
contacts with other records. So I can't attach a contact to an
opportunity or to an account or to an order, so I have to have that in
order to attach that entity to other records. Append to privileges
basically means can I attach other records to this entity. So if you
think about it in that contact and account example, in order for me to be
able to associate a contact with an account, I have to have append to
privileges on the account record, which means that I can go ahead and I
can actually attach records to the account, but then I also have to have
append privileges on the contact rendered which says, OK, now I can
associate or I can attach contacts to other records. That combination of
those two items is what's going to allow me to attach contacts
specifically to the account record in the application. And that's one
area that sometimes gives people a little bit of confusion, is the append
and the append to, which one is which. And so let me show you that here
in just kind of another slide. So this is kind of your append versus
append to. So if you like kind of down on the bottom, this is
controlling what you would see kind of in the related areas of the record
itself. So if I have append, I guess that that indicates that items can
be attached to other records, so I can associate activities to other CRM
records. Append to indicates whether or not another record can be
attached to it, so an account can have cases, contacts, opportunities.
And what you're seeing in the application is a combination of both. So,
for example, I have append privileges on the account and -- or if I do
not have append privileges on the account entity, I really don't have the
ability to attach anything to it. I can't add activities, I can't add
social profiles, I can't add anything to it. If I have append privileges
to the account record but I do not have append privileges on the
documents, then I can attach stuff to the account. So I can see, you
know, Office 365 groups, activities, social profiles, but I can't see
documents because I don't have the abilities to associate documents with
any other records. So if I have append to privileges on the account
entity and I have append privileges on the documents entity, now you can
see that I can now add documents to the account record. So it's a
combination of both of those. And that's where you really need to look
at what your underlying needs are and then kind of define what you want
to do moving forward.

Access Levels
So as we mentioned, access levels work in conjunction with privileges.
So we just talked about privileges, can I create a record, can I update a
record, can I delete a record. Access levels define to what depth or
what degree I can perform that privilege for a specific record. So, for
example, I can create or I can delete accounts. Can I can delete
accounts only that I own, or can I delete accounts that are owned by
other people inside the organization. And, if so, to what degree can I
do that. So what happens with access levels is they're a combination of
a couple of different situations. They look at who you are and what the
record ownership is, and they also look at the business unit to which you
belong to as a user. And those two factors will now control to what
degree you can actually perform that privilege inside the application.
And so if you looked back at kind of those security access levels, you
saw that there was different circles with different kind of green circle,
yellow circle, half circle, those all constitute a different access
level. And we'll show you that here when we get into the application.
But let's first just look at access levels at a specific detail level.
So the first option that you can see is these are your different access
levels. You can see that you have none, you have user, business unit,
parents and then organizational business unit. So each one of these
represent to what degree you can perform a specific access or a specific
action inside the application. So it's a combination of who you are, who
owns the record, and what you want to do. So let's first look at this
from a none perspective. So none is pretty straightforward. If I don't
have the ability to do anything for that particular privilege, so, for
example, I have none set to delete accounts, I can't delete an account in
the system, regardless of who owns that account. And that's actually a
pretty common customization or a pretty common security measure, is
people will maybe force people to deactivate records instead of deleting
them and then they'll use some of the bulk delete functionality to go in
and control who -- when they're going to actually get deleted. The next
one that you have is user. So what user does is it says you can do this
particular privilege for any record that is owned by you or a team that
you are a member of or is shared with you or a team that you are a member
of. So, for example, if I have edit rights on opportunities at a user
level, that means that I can only edit opportunities that I own or I --
or are owned by a team that I'm a member of or have been shared with me
or a team that I'm a member of. Any other opportunity in the system, if
somebody else owns it, I can't touch it. Then you get into business
unit. So now business unit says basically you have all of the same
access levels from a user access standpoint but it also allows you to
work with records that are owned or shared with users in your same
business unit. So if I have read -- if I have read rights on
opportunities at a business unit level, I basically can go in and see any
opportunities that are owned by me, a team that I'm a member of, or
anybody who is in the same business unit as me or has been shared with
the same business unit, records that are in the same business unit. So
if we're in the same business unit, I have access to those records. If
they're in the support business unit, I don't have access to those
particular records. Parent/child gives you business unit access plus the
ability to work with records that are owned or shared with users in any
subordinate business unit to your business unit. So if I'm in the sales
business unit and I have parent/child, I would now have the ability to
see all accounts in the system that are owned by me, anybody in the
projects business unit, support business unit or sales business unit. I
can't cease marketing or service because they're not a subordinate
business unit to my perspective. So the more you give them, the more
access options that I have. And then finally we have organization. From
an organization standpoint, now if I have organization access, it doesn't
matter what business unit that belongs to. So if I have read access on
accounts, I can see every account in the system if it's assigned at an
organization level with no access based upon who they are. So you really
need to look at this inside your implementation and determine what
specific option is going to be best for you based upon what it is you're
trying to accomplish. So we're back in the application on the
salesperson security role. So we've talked about privileges and access
levels. Let's kind of look at those in action now. So you can see down
here on the bottom where I have this key, this is my different access
levels assigned for that option. So, for example, for a create, let's
actually do delete on the account entity. Right now it's set to user
access which means that I can delete any accounts that are owned by me in
the system. If I don't want anybody to be able to delete accounts, I can
basically go ahead and just kind of click on these individual circles
until it gets to the permission level that I want them to be able to
have. So in this point, OK, I cannot delete any accounts and in any
situation. From a share and assign standpoint, I want to only be able to
share records if I own them or assign records if I own them. From a read
perspective, I should be able to see all accounts in the system. From an
edit perspective, I want to only be able to see accounts in the system if
they are owned by somebody in the same business unit as myself or myself.
And then append to I'll set at organization and append I'll set at
organization. So this is where you now would have to come in for each
option and kind of define what specific permissions you want them to
have. Now, you'll notice that there's a lot of different circles that
you can click on in order to facilitate that. There are some shortcuts
in the system to make that a little bit easier. One of the options I can
do is I can kind of click on account, and as I click on account, it will
kind of adjust the circles. And then as they get to the same level, as I
click on it again, it kind of adjusts them all simultaneously. And as
they all get to the same point, eventually I get to the point where I can
just adjust them all individually. This is kind of a nice option if
you're just trying to universally set permissions for a specific entity.
You can kind of set them to however you want and then kind of work with
information from there. So this is kind of a neat way that you can kind
of facilitate that relatively easily. You can also do it at a privilege
level, like I can go into a privilege level and I could do the same
thing. And then as I click on those individual circles, it will just
kind of adjust. Now, you'll notice that some of these only have a couple
of different options. That is directly related to some of the ownership
options, but it at least gives you the ability to move through those.
And then, finally, if you go over into like the individual permissions,
these are the same thing. I can either just kind of set these to yes or
no and then work from there. But you have to do kind of a combination of
each one of those options to determine which one you want to work best
when you're moving forward.

Options for creating Security Roles

One of the questions you kind of have to ask yourself when you're working
with these security roles is how do you want to edit and create them. As
you saw when we were kind of doing the last demo, there's a lot of little
circles there. So sometimes people run into a situation where, OK, how
am I going to create the security role. I can create a new security role
from scratch. So, for example, I could click on new, and let's just call
this Derik's role. Now, when I do that, if I click on core records, I
can see that every single option in here is set to none. So this would
be one of those situations where now you would really have to kind of
come in and set up this different security structure based upon how you
want it to work. Now, I'm going to show you a few different examples of
why you might do this here in just a little bit, but, as you can see,
there would be a lot of clicking that would have to be done to kind of
facilitate how I want this process to work. So this an option, but, as
you can see, there would be a lot of setup on this depending upon how
detailed you wanted to get with each individual permission. One of the
other options that you have when it comes to creating security roles, and
I will just kind of leave this one here for just a second, would be to
take an existing security role, and there is -- and actually one of the
options that you would have on that security role is to go to actions and
choose copy role. And what happens when you go into actions and copy
role is it is actually going to create a copy of that salesperson
security role. Now I'm going to go ahead and I'm going to call this new
salesperson. Now, when I do that, it opens up the role, creates the
role, but it basically just makes a copy of the existing salesperson
security role. So all the permissions have now been defined. So now all
I would have to do is make the modifications in here that would make this
particular situation unique. And we mentioned kind of at the top of the
lesson that might be from a new person's standpoint not letting them
export information or go mobile. So then I could go into business
management, and maybe in here I'm not going to let them go offline, I'm
not going to let them print, use the app, use mobile, export, mail merge.
Basically any of this stuff I'm not going to necessarily let them have
access to. So now I could just adjust this slightly. I still have the
same type of situation, I just don't necessarily have to worry about
recreating everything from scratch. So there's a lot of different
options. Now, the other option would basically be you could just rename
any existing security role and then adjust the permissions accordingly.
So depending upon what your specific needs are inside your organization,
there's a lot of different options for how you want to adjust the
security.

Security Roles and Business Units

So the other consideration to kind of keep in mind is this concept of
security role and business units. Because as you remember when we were
talking about access levels, one of the biggest things we talked about
was you can set access levels at a business unit level and say, OK, you
only have access to do this particular item on records that you own or
are owned by users in the same business unit. So security roles work in
much the same situation. Security roles are actually created at a
business unit level. And so when you create a security -- a security
role, that security role actually has a business unit that is associated
with it. And when you assign user security roles, those users must be
assigned security roles that represent the business unit that they belong
to. So what's kind of neat about that is when I create a security role,
all of the different subsequent business units will inherit that same
security role. So, for example, if I were to go ahead and create at the
root business unit level a social manager role, when I create that social
manager role at the root business unit, the system says, OK, well, since
sales support and projects are all a part of that same business unit or
that same business unit structure, I am going to create that same social
manager business role at each one of those levels. Now, the big thing to
remember is when it creates those roles at those subsequent levels, you
can't edit those. Those are what are called inherited roles. So you can
only make a change to that role at the root business unit level. But
when you make that change, it will subsequently transfer down into all of
the subsequent options that you're working with. But you do have the
capabilities to go in and create new roles at any business unit level.
And when you do that, those subsequent roles will transfer down into the
options. But, again, as you have to remember is the user can only be
assigned a role that belongs to the same business unit that they are a
member of. And when you move somebody from one business unit to another
business unit, it actually removes all of their security roles associated
with their account. Even though that security role might exist in that
same business unit, it doesn't assume that just because it has a role
with the same name that it's indeed the same thing. So remember that if
you switch somebody's business unit, they're going to have all their
other security roles removed and therefore they might not have access to
the application. So let's look at that inside the application a little
bit. So you can see here that up in the top of the security roles it
says business unit. And so it shows me all of the different business
units that I have in my application. When I click on sales, it shows me
the security roles that I have underneath that specific business unit.
Now, the difference here is, for example, if I open up salesperson, I can
see that this is an inherited role and I really can't make any changes to
it. It tells me that in order for me to make changes to this I would
have to subsequently make the changes at the top level. And so this is
an important thing to note, too, as you guys are creating these different
business units. If you want to create security roles that are business
unit specific, you certainly can do that by going in and selecting the
specific business unit you want to work with. So in this case sales, I
could then come in, click on new, I'm going to call this sales -- let's
call this CSR for customer service rep person, representative. And then
I'm just going to go into service and I'm just going to give them full
access to the case entity. Now I can go ahead and I can hit save and
close. Realize I did this in the sales org, but that's OK. Now, when I
look at that, I can see that in the sales area, there is my CSR option.
If I go into here and I look at channel sales, I have the same thing.
It's transferred down and it's kind of moved over. Now, the other reason
I kind of showed you that is I could now go into service. And when I go
into service, I would now have the capabilities to also add kind of a
different option that I would want to work with and then define what
those specific options would be in here and then work with items from
there. But this gives us the capabilities to kind of start setting these
up. But just remember that each business unit will have different
versions of the security roles and just because you're working with one
specific option in there you aren't necessarily going to see that across
the board. And that's kind of what you're seeing from this standpoint.

Assigning Security Roles

When it comes time to assign a security role, you can do it a couple of
different ways. You can do it on kind of an individual user by user
basis, or you could select multiple users or even multiple teams, and you
could assign security roles from there. From a single user perspective,
basically you select the user you want to work with, and then there's a
manage roles option. And when you click on manage roles, it will open up
all the different security roles that are available for that user based
upon the business unit that they belong to, and then you can select
basically what role they should or should not have just by using
checkboxes. The other option that you would be looking at would be for
multiple users. Now, the difference with multiple users is you can
select multiple users and you can add different roles for multiple users;
however, when you select multiple users, the existing roles that those
users have are not shown. So you don't have the ability to remove a role
from multiple users. Unfortunately, removing a role has to be done kind
of on an individual user-by-user basis, but assigning you can do multiple
ones. And we'll hop into the app here real quick and we'll show you what
that looks like. So, for example, I can go into my user record and I can
select my user record, and now you'll see that I have an option here to
say manage roles. When I click on manage roles, it'll show me all the
roles that are associated with this user account. I basically just
select whatever specific roles I want them to have in the application,
and then I kind of click on OK. Now, for multiple users, it's really the
same thing. The only difference that you're going to notice -- for
example, if I click on CRM admin and myself and I hit manage roles -- is
now none of those roles have anything associated with them. Because it
doesn't -- each of us might have different roles that we use, so it can't
show us specifically what roles are assigned. But I can use this as kind
of a universal scenario to assign people specific privileges or items
within that role. Now, again, it will tell me that it didn't work, and
that's more than likely because we've already had options that were
associated with that. But this is where I could go in and kind of select
those and then pick what specific options you want to do. The big thing
is keep in mind what business unit people belong to as you're working
through. The other thing to keep in mind is if you wanted to switch
somebody's business unit, so, for example, let's say we have Tony here,
we've talked about this a couple of times, but if I switch Tony's
business unit, so I come in here and I switch Tony's business unit --
actually, let's do one quick thing here. Let's open up Tony. Let's give
Tony a security role, so let's make him a salesperson. And now if I
click on Tony and I go into manage roles again, because I just have one
selected, I can see that Tony is a salesperson. If I switch his business
unit, so I click on change business unit and I switch his business unit
to a different business unit, once this process is complete, and, again,
it shouldn't take terribly long here because he doesn't own any records,
but if he did, it could take a little while, now if I go into Tony and I
click on manage roles, I can see that he does not have any security roles
associated with him. Because, again, it doesn't assume that just because
you had that security role in one business unit that you should have it
in the other. Now I can reassign him as a salesperson, click on OK, and
now if Tony were to try to log back into the system, he would have the
ability to do so.

Multiple Security Roles

As you saw when we were going through the demo a little bit, I have the
ability to associate a user or a team with more than one security role.
And that's not a problem. Because if you think about it from just a
normal day-to-day business perspective, particularly in smaller
organizations, you might have users that wear a lot of different hats.
They're not only a salesperson but they're also a marketing person so
they need to have marketing-level access to specific records inside the
application. When you start talking about working with multiple security
roles, that can be done. What you have to remember, though, is when
somebody has more than one security role associated with their account,
the combination of privileges and access levels uses what's called kind
of the least restrictive method. So let me show you that here a little
bit on kind of this slide here that we'd be looking at. So let's just
say I have a security role that is called like baseline. So it's the
baseline security role that every single person that accesses Dynamics
365 uses, and that baseline security role gives everybody organizational
read access to accounts so they can see all accounts in the system, they
can only edit accounts that they own, and they can only assign accounts
that they own to other users. So that's -- and then from a case
standpoint, they have the ability to see all cases that belong to users
kind of in the same business unit that they belong to. Then I'm going to
go ahead and I'm going to add another security role to this person called
the salesperson. And by adding that security role to this person called
salesperson, that security role has business unit access to read
opportunities and then user-level access to write and assign
opportunities, and it doesn't have any access to accounts and cases. So
by adding both of those security roles together, what ends up happening
is I get kind of a trickle-down effect. So it looks at the -- all of the
different permissions and it kind of moves them in together, and that
combination is what ultimately is going to give them access to the
account. So now for that particular person, they basically have read
access to all accounts at an organization level, the ability to edit and
assign accounts that they own, all of the salesperson access to the
opportunity stuff, as well as the ability to work with cases at a
business unit level. And so this is a great way that you can start using
these security roles as kind of stacking privileges to give people
additional levels of options based upon what you want to do. So it looks
at all the security roles, and it's kind of a combination of both.

Security Roles: Layered Approach

So this -- by this layered approach or that method gives you kind of a
unique opportunity. So you remember when we talked about when we created
a new security role, everything comes in with really no permissions to
find. And so sometimes what you'll see people do inside organizations is
they'll use this layered approach where they'll have a bunch of different
security roles that only have specific permissions to entities based upon
what they're trying to do. So you have a salesperson security role that
has no access to any of the service stuff but it has the appropriate
access defined for a salesperson to all the sales stuff, so to accounts,
opportunities, so on and so forth. And by doing that, now you can just
as people get promotions or as people have different needs inside your
organization, you can now start layering these different security roles
on top of each other and now they start to get a combination of each one
of those security roles put together and get the least restrictive
permissions. So this is a very common approach that you'll sometimes see
people do. So, for example, I have my baseline, which we talked about
earlier, I have my salesperson, so now they're also going to be acting as
their sales manager. So from a sales manager perspective, I want them to
have specific access. So as a sales manager, I now have the ability to
assign accounts for anybody in my same business unit, but it isn't
necessarily going to give me any additional rights to read or edit
accounts. It's going to give me full-blown parent/child business unit
access for opportunities, and then it gives me organization access to
read cases as well as the ability to edit cases in my same business unit.
So now by doing that and adding that specific situation, it takes all of
those individual permissions, it cascades them down, and now you can see
that that combination of each one of those is what's ultimately showing
up. So now from a salesperson perspective, when it added it in, it threw
in and added the salesperson stuff on top of it, then it looked at the
least restrictive permissions for each one that they've been assigned.
So the least restrictive for read access on account is the organization
at an account level. It's user for write, it's parent/child for assign,
because that was what the sales manager was, and then it keeps trickling
that information down, and that's ultimately what's going to give them
the final access. So this is one way that you'll see people do that, is
they'll create a bunch of different smaller security roles and then just
stack them. Now, the other option you could do is you could just do a
nonlayered approach where you have a salesperson and you have a sales
manager. The salesperson has all of the individual permissions
associated with what a salesperson would need; the sales manager has all
the different permissions that a sales manager would need. Now, if I was
a salesperson and I'd been promoted to a sales manager, you simply remove
the salesperson security role from my account and make me a sales
manager. You could do either one. Neither one is a wrong approach, it's
really just a matter of looking at what is the right approach for you as
an organization and then kind of defining which one you want to use
moving forward.

Teams and Security Roles

The final piece to this is team. So we had mentioned that you can use
teams as kind of a way to allow groups of users to own records inside the
application. Now, one of the things is when you create a team, you don't
necessarily have to assign a security role to that team. However, if you
want that team to be able to own records, so I want users to actually --
to be able to assign that record to a team and every member of that team
to be able to own those records, you can do that. In order to do that or
in order to assign ownership, you have to associate it with a security
role. So when you create a team, just like any other situation, a team
has to be associated with a business unit because it's that's kind of
what it uses for privileges of working through it. However, even though
that team has to belong to a business unit, team members can come from
any business unit in the application. So this is where you can sometimes
get around that business unit structure where you can basically say, OK,
I have this team called management and this management team exists in the
marketing business unit. Members of this team are coming from sales,
portals, all sorts of different scenarios. But when you assign the
security role, now it looks at all of those different options and it uses
that same scenario. It's the least restrictive access level to all
record types for that specific business unit that's going to give them
access. So this is where you can really now start to give people
additional scenarios. So if they have a user-level access to something
and now they have team that gives them more access, that team scenario
will now give them additional privileges that they may or may not have.
Just like if you were stacking individual security roles. Same thing is
true if you were doing it as a user level as well as a team level. So if
you remember that sample security role that we created earlier, that
sample security role now exists in the Dynamics preview business unit.
If I select the security role, I have the ability to go up into -- or
this team, I have the ability to go up into manage roles, and I can now
assign this team a security role. And as soon as I do that, now any
member who is a part of that team, regardless of what business unit that
that team member resides in, will now get those permissions that are
associated with it. So now you have the ability to really extend this
functionality out and work with it on kind of a larger scale. So in
theory a user just has to have a security role associated with their
account. So I've even seen situations where somebody is a member of a
team; that team has a security role associated with their account; that
user now has access even though they don't necessarily have a specific
security role associated with their user account. They do have a
security role because they have it associated with the team that they
belong to. And this, by using these combinations of things, is where you
can really start to extrapolate a lot of different options across the
board at an entity level. Now, the final piece to this is obviously
depending upon what your situation is when you start working with
security roles and different items. If for some reason you have a
security role that doesn't necessarily exist or need to exist, obviously
you can remove the security role associated with that scenario. It's not
going to necessarily hurt anything from a system perspective. Just
remember that if there are users that are in that security role that
don't have any other security roles associated with their account, they
will not have access to the system anymore. So you do need to make sure
that any of those users who would require access have now been assigned a
specific security role in another instance.

Module Review
So the Dynamics 365 security model is a critical component in any good
implementation because that's what you're really going to use to make
sure that you're controlling access to whatever it is, whether it's data,
features, UI elements, whatever the options are. Now, as part of that
security situation, the security roles themselves use a combination of
different access levels and privileges to control the specific access to
what they're looking at. So you really need to look at, OK, who is this
user, what are they going to be doing within the context of the
application. And as you're going through that and now you know, OK, this
is Derik, Derik needs access to these subsets of records, that's where
you're going to have to define, OK, here's the privileges and here's the
access levels when they're working through it. Now, that usually gives
you the capabilities to handle most situations when you're working
through it, but remember that sometimes you may want to go in and assign
multiple security roles. And if you assign multiple security roles to
that person's job description, that will then use a least restrictive
model that basically says what is going to give them the most access to
what they need to be able to do based upon the common -- the common
security roles that they have associated with it. And from that
perspective, now they have the ability to go in and work through the
option. So it's really a matter of determining who that user is, what
data they need to have access to and what or how many different
positional options they might have within your organization to truly
determine what types of security roles and the combinations of security
roles that they might need to access the data.

Test Your Knowledge Questions:

1. Which of the following is not an access level setting for a security roles privilege?

 Business Unit.
 User.
 Organization.
 Global. *
 None.

Explanation: Dynamics 365 has 5 different access levels that can be associated with entity
privileges. They are None, User, Business Unit, Parent Child BU, and Organization.
Reference: Access Levels

2. Which of the following statements is true of a security role created in the root business unit?
(Check all that apply)

 All other business units will inherit this role

 The role only applies the root business unit
 The role can be edited in any business unit it exists in
 The role can be edited only in the root business unit
 The role can be moved to any other business unit

Explanation: Each role is created at a business unit level. Roles created in a business unit are
automatically inherited by each of its child Business units. Roles can only be edited in the
business unit that they were created in.
Reference: Access Levels (Security Roles and Business Units)

3. A user has two security roles assigned to them. The first allows them to read accounts, delete
contacts, and edit opportunities. The second does not allow them delete contacts, but allows
them update accounts. Which of the following statements are true? (Select all that apply)

 The user cannot delete contacts.

 The user can update accounts. *
 The user can edit opportunities. *
 The user can only read accounts.
 The user can delete contacts. *

Explanation: When a user is assigned to multiple roles. Their access to the record is a
combination of the least restrictive access level defined for each privilege that is defined for
each entity in the application.
Reference: Multiple Security Roles
 5. You want to move a user to a different business unit. Which of the following statements are
true? (Check all that apply)

 The user will receive all security roles in the new BU they had in the old BU.
 The user will lose any security roles that were assigned to the Them in the previous
BU. *
 You cannot move a user from one business unit to another.
 You must assign a new security role to the user in the new BU. *
 Any records owned the individual user, will still be owned by the user. *

Explanation: Every user must have at least one security role attached to their account in order
to access data. When a user is removed from their current business unit, all security roles that
the user had in that BU are also removed. Dynamics 365 does not transfer or copy existing
security roles to the new business unit. At least one security role will need to be added for the
user to access data.
Reference: User Management

Module 03: Implementing Hierarchical Security

Module Overview
In the last module we talked about really the basics when you start
defining a security structure from a Dynamics 365 perspective. And we
talked about how you're going to use business units and how you're going
to use security roles in combination with those business units to define
what specific privileges and access levels that people might have. And
one of the big things that we saw in that last module was everything
works within the context of business units. It's all based upon who you
are and what business unit you belong to. And in most situations, that
does allow for a combination of most security instances that you might
have. Sometimes, though, you run into situations where the business unit
structure just isn't always going to fit. And so that's where you can
use different options to be able to maybe extend that existing CRM
security model out to have a little bit more granular access. And that's
where this concept of what is called hierarchical security comes into
play. And so what we want to do in this module is talk just a little bit
about what is Dynamics 365 hierarchical security, how does it differ from
kind of your existing security module or options that you would see
inside a Dynamics 365 implementation. And it's really not different as
much as it is complementary. It's kind of an additional security piece
that you can bring on top of it. So we're going to look at what that is,
we'll talk a little bit about how it's configured and what some of the
options are for configuration, and then we'll talk about the two options
that play into fact when you start talking about hierarchical security,
and that's the managerial security as well as the positional security.
And each one of those can now be used to kind of extend your existing
security structure out and just accommodate a few more options as you're
moving forward.
Hierarchy Security
So as we talked about on the first slide, what is hierarchical security?
And really it's an extension of the existing Dynamics 365 security model.
And it allows you a little bit more granular access to records because
what it basically does is it looks at who you are and where your position
is within the company's hierarchy of your organization. So let's --
before we kind of get into the configuration and talk about it, let's
look at it from kind of a typical organization where you have like your
C-level executives, those C-level executives might have managers that
report to them, and then those managers might have salespeople that
report to them. So when you start talking about having access, it would
make sense that as a C-level executive I should be able to see and maybe
even to some degree manipulate most of the information that my sales
managers have access to that they're working with. So I would have
read/write access to all of my sales manager information. Well, since my
sales managers have people that report to them, ultimately they're part
of that hierarchy, I should at least have visibility into what those
other people are doing. And so from a managerial standpoint, it doesn't
necessarily look at it as much at an entity level as it does look at it
who you are and who you supervise as part of your organization. Now,
it's not a replacement to the existing business unit security model, it's
kind of an extension onto that and you have to use it in conjunction with
the existing business unit options that you would be working with. But
on top of that, now you say, OK, I want this to be used and I, based upon
what my position is within the organization, I want to have additional
visibility into all of my subordinates' account, contacts, opportunities,
so on and so forth. And so it's an easier way to apply permission to a
bunch of different entities without having to go in and specifically
assign privileges and options. Now, it's an opt-in feature. So as you
can see here on the screen, it's something that you really have to opt in
for. So you have to go in and enable hierarchical security modeling at
an application level. There's two options, and we'll talk about both of
these here in just a couple of seconds. There's managerial hierarchy and
then there's custom position hierarchy. You can only use one or the
other. Managerial is based upon who the manager is for a specific
record; custom position hierarchy is based upon a new entity called
positions that is associated with each user in the deployment. So you
have to define who's managers of who or what position people have within
your organization. And then each one of these options has kind of a
depth option that you can set. So from within the organization I can
say, OK, that I want a hierarchy to go down three levels. So I've got C
level, I've got C execs, I've got managers, and I've got individual
people. Those are my three tiers. It does support up to a hundred
different levels. What we usually tell people around the hierarchical
security stuff is try to keep it at no more than four. And we'll talk
about why that is as we move through, but you can start to see a little
bit of a performance issue when you start moving forward. Now, each one
of these, as you're enabling these, will actually basically give you
access to all of the subsequent entities inside the application. You
also have the ability to exclude entities from the hierarchy. And I'll
show you that when we get into some of the individualized situations as
well. Let's look at each one of the manager and positional hierarchies
in a little bit more detail. So from a managerial perspective, the
manager has to reside in the same business unit or the parent business
unit of the people or person that they are directly or indirectly
managing. So, for example, if I am working with subordinate people and I
need access to all of their stuff, I at least have to be in the parent
business unit of the item that I'm working with. It follows that same
business unit model structure that you'd be working with. Positional is
a little bit different. Positional doesn't use a direct report model.
What it actually does is it has a position that is associated with each
person, and each one of those positions has kind of a direct and indirect
report associated with them. And then what's nice about the positional
security is you can go across business units and you can go into
different areas. So they are -- they do extend the existing security
model. Managerial still honors some of that same kind of business unit
structure as far as parent/child access, whereas positional is going to
give you more access to expand across different business units. And
we'll talk, like I said, a little bit about each one of these in a little
bit more detail. But, again, you have to kind of choose which one you
want to use, if any, because you only have one option when you are
implementing hierarchical security, either manager or positional. You
can't use both.

Managerial Hierarchy Security

If you elect to go the managerial route from a security standpoint, the
big thing to remember is it uses more of kind of a direct reporting
structure. And so it's all based on the manager field on the system user
entity inside Dynamics 365. So, for example, if you look at kind of the
visual here, we had this concept of the VP of sales. And so the VP of
sales is going to have direct reports that report directly to them, which
in this case would be sales managers. And so from an application
perspective, the VP of sales really should have access from an editable
perspective to all of their direct reports. So the sales managers would
be considered a direct report. So because of that, as the VP of sales,
you're going to have the ability to edit, read, append, append to,
basically work with and manipulate all of your direct reports'
information. Now, underneath your direct reports, like you can see for
the sales managers, we have one of the sales managers that has a sales
staff that's associated with them. Well, those still technically in line
with that VP of sales hierarchy so I should still have access to their
data. Now, I'm not necessarily going to have direct edit access to their
information because technically they are not a direct report, they're a
nondirect report. So I'm only going to be able to see the information
for the sales users. And so what we would do in this managerial-type
situation is you would go out and define for each person within your
organization this person's manager is this person, this person's manager
is this person, and you define that all the way up the chain. And so
anybody who's directly underneath you, you can modify and edit their
information. And then, subsequently, anybody who falls underneath those
people are considered a nondirect report. So you have visibility, you
just don't necessarily have edit capabilities. So let's look at this
inside the app. So if I go into settings and security, I'm going to go
into hierarchical security or hierarchy security and we're just going to
kind of configure this first at kind of a managerial level, and then
we'll go ahead and look at it in another demo from a positional
standpoint. So the first thing that we're going to do when this opens up
is we have to enable the functionality inside the application. And once
the functionality is enabled, then we have to kind of define what model
we're going to use. So in here I'm going to go ahead and I'm going to
enable hierarchy security, and I'm going to configure or set this up from
kind of a managerial hierarchy standpoint. So this is where I can go in
and I can hit configure, and this is going to take me into the
application where I can now start to kind of define what this option is.
So this is each user within the organization. So let's just, for
example, open up Tony. So we're going to say that from Tony's
perspective Tony's manager is myself maybe. So we'll go ahead and we'll
scroll down into here. Let's switch this to user. And right here
underneath the organization information is the manager. So we're going
to say that Tony's manager is myself. Then we'll go ahead and save the
changes. And then I can go ahead and close out of here. And then we'll
say that from myself, my manager is the CRM admin. So we'll go ahead and
open up my user record, scroll down into my user information and set the
manager as CRM admin. So now from this application perspective, the CRM
admin is going to have the ability to edit and modify any of my
information based upon the managerial hierarchy, and I'm going to have
that same access to Tony's. The CRM admin is going to have read-only
access to Tony's information, because he is in the same hierarchy, he is
considered an indirect report. And that's really what you would do from
a configuration perspective inside the app. Now, this is where the
hierarchy option comes into play. I have the depth set to three. You
would normally, depending upon how you want to go through, up to a
hundred is what your options are, but, as I mentioned, you really want to
target more about four. And the reason behind that is think about how
many records each one of those individual people could have. Tony could
have 15 or 20 different records that he has to work with. And if I've
got five or six different people that I manage, now that's 20 times five
or six, now you're getting into a hundred different records. And if the
CRM admin now has 10 or 15 people that they manage, now you start
multiplying all those together and you can see that it's very easily
getting into the thousands of records that this additional level of
security has to be applied to which then means that you could potentially
have some slight performance issues particularly when you start getting
higher up in the hierarchy. So now your sea-level people trying to look
at information could experience slowdowns. So keep that targeted rate at
about the four area if you can. Now, the other thing is by default I am
going to have access to all of Tony's information. If there are specific
entities in here that I don't want somebody to have access to, this is
where I could select that entity, add it to the excluded entities, and
now that removes it from the hierarchy. So the nice thing about the
hierarchy is I'm getting direct access and the ability to work with all
of that information for anybody who reports directly to me.

Positional Hierarchy Security

From a positional standpoint, it's a little bit different. Because now
we're saying, you know what? I don't necessarily care who your manager
is. What I more or less care about is what is your title, so what is
your job functionality inside my organization. And so from that
standpoint, now you're just giving everybody a position. So you would go
in and configure the positional hierarchy for your organization. So you
would say, OK, my VP of sales and service report to my CEO, my managers
report to my VP of sales, my salespeople report to my sales manager. I
don't necessarily care which sales manager, I just know that they report
to my sales managers. And because of that, in this case now you would
have a situation where sales managers are basically direct reports of the
VP of sales. So because of that, the VP of sales would have read/write,
append, append to access to all of the sales manager information. And as
you work your way down the chain, your nondirect reports, which would
basically be your salespeople, I would have read-only access to within
those contacts. So these are people that I don't necessarily report to
on a day-to-day basis, but they're still part of my chain. Now, let's
look and see what that looks like inside the app. So if I set this at
custom position hierarchy and now I hit configure, this is a little bit
different. So now what I'm going to do is I'm going to define what those
positions look like inside my organization. So, for example, I'm going
to go ahead and just create a new position. I'm going to call this my
CEO. And I'm going to save and close. Or actually I can hit save. Now,
in this situation, this is where I would have to say who are the people
that have that position. Now, I could have five, six, seven people in
this position if I wanted to. In this case, we'll just go ahead and add
the CRM admin to this position. And then I will close out of here. And
then we'll add a new position. We'll call this VP sales, and we'll say
that the parent position is the CEO and save. And in this case maybe
we'll just add myself to that. And then we would continue this process.
We'll add one more. We'll call this one managers or sales managers. And
we'll do the same thing, we'll add a couple of different users to this
one, so we'll say sales managers. And we'll make the parent position the
VP of sales. We'll save it. And we'll add Tony Smith. And then we'll
just do one more. Call this sales. And the users in this position are
Train User 1 and Train User 2. Now, the advantage to this is the fact
that I'm saying I don't necessarily care who the users are, but this is
the organizational structure that I want to work with. And now the
advantage to this also is the fact that this is also going to use -- this
is also going to use kind of nonbusiness unit territory situation. So it
doesn't matter who belongs to what business unit. If they are considered
a salesperson and they're in sales in that situation, they are considered
a direct report to anybody who is a sales manager. Doesn't matter what
business unit those sales managers belong to. So now any sales manager
would now have access to any salesperson's information. And so this is
where now you can really take this on top of what you already have from a
security structure and really give yourself some more specialized
circumstances where you can start using this and applying this when
you're moving forward.

Module Review
When it comes to using security from a Dynamics 365 standpoint, sometimes
you're going to just find that the out-of-the-box business unit security
role structure isn't going to give you everything that you need to have
from within the context of that application. And so you may find that
you need to extend that functionality out just a little bit to be able to
facilitate that. And that's really where the hierarchy security can come
into play. Because it gives you the ability to actually have a little
bit more granular access to what it is that you want to do. You can base
it more off of positional or managerial access now providing more
detailed access to all of the entities that those direct reports or
nondirect reports might have from within the context of the application.
Now, remember, there's two types, there's the managerial and there's the
positional. With managerial access, the managers do have to reside in
the same business unit or at least in a parent business unit of the
person who is directly or indirectly reporting to them or who they
manage. But as soon as you have access to those individual situations,
if they're a direct report, you have complete read/write access; if
they're an indirect report, you are going to have read-only access to the
information. With positional security, you do have the capabilities now
to span business units. It's the same concept. It's whoever is directly
reporting or indirectly reporting to you, but it's more at a what
position have you been assigned within the application itself. The big
thing to remember is while the application does allow you to have up to a
hundred levels in the hierarchy, they really only recommend going no more
than four deep because there's additional filtering that has to be
processed in order for that to work, and the additional processing, based
upon how many people you manage, could have some performance implications
on the people higher up in the chain. But it's still an excellent model,
particularly positional if you need to span multiple business units, to
just provide a nice extension to the already flexible functionality
that's there from a security standpoint within Dynamics 365.

Module 04: Knowledge Management

Module Overview
So, historically speaking, when people have thought about knowledge
management, they've really thought about it in the concept of service. I
have internal employees who need to be able to search our knowledge
management to find resolutions to cases or items that they're working
through. And over the course of time, knowledge management has really
evolved into not only just internal self-service for employees but it's
also really come into kind of a self-service functionality for your
customers as well. And so as you're doing more and more Dynamics 365
implementations, you're going to see that knowledge management ends up
being one of those kind of key pieces. And it's not necessarily just a
service-based functionality anymore. And that's what we always thought
was real important for us, to really examine how that configuration
process looks like and what does knowledge management look like in terms
of Dynamics 365. So as you're configuring these implementations, you can
come up with a clear, defined strategy on how you want to use knowledge
management moving forward. So in this module, what we want to do is talk
just a little bit about how did we get here, what are some of the
knowledge options that are available from a Dynamics 365 perspective, not
only today but also as we're moving forward, because there's been some
changes on some things that are coming that could affect how you're
moving forward within the context of handling knowledge and knowledge
integration. We're going to talk just a little bit about the new kind of
updated knowledge articles that were introduced in a previous version but
now have kind of transferred over into Dynamics 365 and what advantage
that's going to give you. We're not necessarily going to talk a lot
about the creation of the articles per se as much as just the
configuration elements around them and what some of the options are that
are available when you start looking at how you're going to set some of
that functionality up. We want to talk a little bit about knowledge
searching and showing you how you can enable knowledge searching across
entities and not necessarily just associate knowledge articles with the
case entity anymore but how can I expand on that functionality and maybe
transfer that over into the account or the opportunity or a contact,
depending upon what the situation might be, or, more realistically,
probably a custom entity depending upon what type of delivery mechanism
you're working with. And then just have the conversation about how does
external access fit into what you might be wanting to do moving forward
with these knowledge articles so you have a definite plan where if you're
going to be surfacing this on like a CRM portal or some maybe other
external provider what that process looks like so you can work through
that as you're moving forward.

The Big Picture

Let's first talk about the big picture from a knowledge management
perspective. Obviously it all starts with articles. You're going to
create different knowledge-based articles inside your deployment that are
going to be used across the board in a variety of different situations.
Now, historically those have always been associated with cases, but as we
talked about at kind of the top of the module, it really could come into
any different type of scenario. You may be using custom entities to
reflect some type of business that you're working with, and allowing
knowledge-based articles to be able to facilitate those options might be
a nice situation from that standpoint. Maybe you handle shipping
information and you associate shipping information with orders and so now
you want to be able to surface knowledge-based articles on the order
entity to be able to look at shipping issues that may have arised.
However you're kind of working through that process, ultimately what's
end up happening is you need to surface that information through entities
so people can search that information. And you also want to get
intelligent over time. So as people start to search those individual
items, what's taking place, what's happening inside there that's going to
constitute different situations. So the search results that you're
getting back are more intelligent as you're going through. And we want
to be able to do things like automation, to be able to handle custom
approval processes and work things through but also be able to handle
when items are published up into our knowledge base but when maybe they
expire so they're no longer valid. And we want to look at things like
portal access to understand that more and more customers and more and
more consumers are going to want to be able to consume that information
directly through a portal. And then ultimately we want to be able to
measure how useful these articles are; are people taking advantage of
them, are they entering the -- are they finding that information, is an
article being used a lot or not very much. Are there ways that we could
better how we push that information across. And so it's important to
understand that from a knowledge management standpoint there's all these
different facets that really play into what it is that you're doing.
Now, let's just talk a little bit about what knowledge management looks
like from a Dynamics 365 perspective. Now, if you think back to kind of
the traditional Dynamics CRM days, there was always this concept of
articles, that were traditional, quote/unquote, CRM articles that were
available. They worked for very limited types of situations, but they
didn't have a lot of searching capabilities, the editor was somewhat
limited, there wasn't any real options around expiration or any of those
things. So you really didn't have a lot of the analytics that you would
hope to have from an application standpoint. So then a few versions back
they introduced Parature integration. Now, I want to mention Parature
integration because Parature integration is still a viable option with
Dynamics 365. As long as you're using Dynamics 365 Online and you have
it associated with a Parature instance, you can integrate the
applications together and use Parature's knowledge management
functionality inside the application. Now, one of the things that I want
to kind of caution or talk a little bit about is from a Parature
perspective, Parature, in regards to how the application functions today,
is slowly starting to be phased out. So there is not going to be any new
Parature options available from a subscription standpoint. So while I
want to mention Parature from a standpoint of if you're an existing
customer with a Parature subscription, that will continue to be supported
as long as Parature is in existence from a CRM perspective. But moving
forward with Dynamics 365, there's really going to be this transition to
the true Dynamics 365 knowledge articles. And the nice thing about the
Dynamics 365 knowledge articles is they do support things like major and
minor versions. They do have search analytic capabilities where you can
actually configure it to search for individual records based upon what
people are typing into the searching title when they're working with it.
You do have the capability, if you have your own custom portal or if you
have a portal that you're working with through Dynamics 365, you can
actually publish that information up to an external portal and make those
knowledge articles available to customers who are surfacing through them.
You have the ability to do things like delay when items are being
published. You can set up archiving and expirations. You can do
translations. So you can create an article in multiple languages. And
then based upon the person that is trying to work through that article,
if that article is available in their native language, it will actually
make it available for those processes as well. And not to mention the
fact that it has a more intensified WYSIWYG Editor that you can use to
really embed more images and links into the article and really make the
article more user friendly from a design standpoint. But as you publish
these articles out and people start using these articles in the real
world, you have a full set of analytics that you can now come into and
capture and determine how that process has been working and what people
are doing. So it really gives you kind of a nice mechanism that you can
use as you're moving forward to really manage those options. But from an
application and an integration standpoint, the Dynamics 365
implementation right now does allow you to do integration with your
traditional -- or with your current Dynamics 365 knowledge articles as
well as maybe integrate with a Parature implementation if need be.
Searching the Knowledge Base
So what are some of the advantages to using knowledge functionality and
knowledge searching functionality inside Dynamics 365? So as you can see
kind of on the screen shot, right in here on your task period, I have KB
Records and this allows me inline searching of my knowledge base directly
from the context of any record within CRM ... or within Dynamics 365
that's been enabled for knowledge management. So traditionally this
would be things like the case entity, but as we've talked about, it
really could be any entity that you wanted to work with. The nice thing
about the searching functionality is, again, depending upon what your
implementation is, you can search Dynamics 365 records or Parature
records if need be, but it does support multiple languages. So based
upon what your native language is, if the knowledge article exists in
that native language, when you're searching for that information inside
here, it'll actually give you the capabilities to see those knowledge
articles in your native language. There's also a language filter in here
that allows you to switch that information to different language options.
So if you do find ... if your native language is English, but you want to
be able to send that article to somebody that speaks Spanish, as long as
the article exists in Spanish, there are mechanisms in place that you
could go ahead and facilitate sending that information out. The nice
thing about this is, this also gives you the capabilities to search as
you type. Now, typically it's going to use the case title, but when you
start talking about Azure analytics and text analytics and machine
learning, over time it can get more intelligent based upon specific
fields and it can now start to communicate back to your results based
upon multiple fields and understand kind of key phrases and do more kind
of fuzzy matching, as opposed to some of the exact matching functionality
that it typically does, but that's kind of an additional piece that you
have the ability to surface. So what you can do is, now once you've
facilitated that article and you've done a search for that article inside
the application, now you can just look at that article in the context of
the record itself. You could open that up into a separate window if need
be and analyze it from there, but you also would now have the
capabilities to email that article or a link to that article to external
customers. So if it surfaced out on your portal and you wanted to be
able to link that item together, you could do that. Or if you wanted to
associate that record with a specific Dynamics 365 record, you would be
able to do that as well, and now you get that analytics piece. So now I
can see how many active cases or active orders or whatever the item might
be are actually using those search results inside ... or using that
knowledge article inside the context of the application. So it really
becomes a powerful tool to provide those baseline analytics for your
customers when they're working through.

Enabling Knowledge Search

So I'd like to spend just a little bit of time showing you how to enable
and configure the knowledge searching functionality from within a
Dynamics 365 implementation. Now, I mentioned kind of at the top of the
module that historically you see knowledge management really associated
with service-based functionality and capabilities, but it's really
morphed into other entities across the board as well. With that being
said, you still access it through kind of the service management
settings, and so I want to talk just a little bit about how that process
looks like. The nice thing about knowledge management functionality is
there's kind of a two-tier process. You can either enable it on an
entity definition itself or you can enable it through kind of the
knowledge searching functionality, but then you have to specify how you
want to use it. So again, it supports either Dynamics 365 or currently
Parature, if you have an existing Parature instance, but you have to pick
one or the other. Remember that, moving forward, Dynamics 365 is really
going to be the preferred method, and if you are trying to connect with
any kind of on premise type situation, Dynamics 365 is really your only
option from a knowledge management perspective. But let's go ahead and
let's show you what that looks like inside the app itself. So I'm going
to go into settings and I'm going to go into service management. And if
I scroll down, I'll see underneath service management, about halfway down
I'll see a knowledge-based management option. And there's two options in
here. There's the embedded knowledge search functionality and then
there's the category functionality. So one of the things to remember,
particularly if you're going to be surfacing this information externally,
is you have the concept of being able to create kind of a category and a
category tree hierarchy that you can associate specific knowledge
articles with inside the application. And so what this categories allows
you to do is to go in and define what that categorical structure might
look like from an application standpoint. So I can define different
category numbers that might reflect different types of situations. So I
can see in here I have categories for defects, I have categories for
delivery issues, return items, and some of these are all going to
basically fall under different hierarchal options. So again, if I click
on the hierarchy for any one of these individual options, I can see the
hierarchy option that shows me where the delivery issues fits in kind of
the grand scheme of things. So I have a support hierarchy that's broken
down into defects, delivery issues, and then returns and exchanges. So I
can see my hierarchy in regards to how I'm working with it. What's nice
about this is, again, if I were to expose this externally through like a
portal, these categories are what are used to group individual items
together. So when I want to see those options, I can work through them
very specifically just by using and selecting the category. So each
article can be associated a category. If I go back into knowledge
management and I go into embedded knowledge search, this is where I can
configure the functionality. Now, there's a two-tier process to be able
to determine how you want to configure this functionality. I can just go
straight into here, and eventually once it kind of loads up, it'll show
me all the different entities that are available to be used within the
knowledge searching functionality, or I can go into a specific entity
definition itself. So I can go into settings and customizations and I
can enable a functionality for knowledge search as well. Either way,
it's ultimately going to give me the same end result. So in here I can
see that here's all my different entities, I can see that the case entity
has been enabled for knowledge search at this point. If I wanted to, I
could also go ahead and maybe associate it with the order and I could
also associate it with the account entity, which would now mean that I
have the option to be able to facilitate that information inside the
application. The next thing I have to define is, where am I going to be
pulling these knowledge articles from? So down here you'll see that this
is that knowledge solution option. I can choose either Dynamics 365 or
again, if I'm an existing Parature customer, I can choose Parature, and
then I just have to connect the Parature instance with the appropriate
account ID and department ID. These are all available from a Parature
perspective. Realistically, you're going to probably do this more often
than not just through Dynamics 365. This now gives you the capabilities
to go out and link this and associate this with a specific item. Now, I
also could use an external portal, and in this external portal, if I had
an address for the portal that I wanted to work with, I could use that
URL format basically just by pointing to where I want those knowledge
articles to be stored inside the application. In this case I'm not
necessarily going to associate it with an external portal, but this does
give me the capabilities, if need be, to be able to facilitate that. And
as long as I have my configuration stuff set up, if I'm utilizing like
portal capabilities, I do have the capabilities with portal capabilities
for CRM to really just kind of set it up from this perspective. It
automatically feeds it into here. I don't even necessarily have to use
the external portal address if I don't want to. Then I can go ahead and
I can hit next. It's going to determine that I've got everything set up
and I've enabled it for my specific entities that I want to work with,
and now I can go ahead and hit finish. So now from this perspective,
everything is set up from a searching criteria. So now I have to
determine how I want to use this within the context of the application
itself. And so you'll notice that we did enable it for orders and we
also enabled it for accounts. So the next tier to this is you would
actually want to go into the entity that you work with and kind of
configure the knowledge searching functionality for that specific entity.
So I'm going to just go ahead and close out of here. I'm going to go
into settings and I'm going to go into customizations and we're going to
customize the system, and we'll go into entities and accounts and we'll
open up the account form. So once I've opened up the form, now I can
surface kind of my knowledge functionality. Now, remember that from a
Dynamics 365 perspective, you have kind of your traditional web client
option that you can use for displaying and working with information
inside the application, but you also have the interactive experience.
And so if you have an entity like the account entity that's been enabled
for the interactive experience, you do have to make sure that you're
going in and working with those individual subgrids and options and that
you're turning on the functionality for any form that's going to be used
to interface with the application. So if I, for example, were to come
into here and I were to open up the account form, this is where I can
configure kind of my account-based functionality for the individual
elements that I want to work with. So one of the options that you'll see
under here is the knowledge-based search. So this is my knowledge-based
search functionality that I can bring into kind of any tab or environment
that I want to work with. In this case we'll just go ahead and click on
the knowledge-based search control and it'll open up that functionality
inside the application. So in this case, we're going to just go ahead
and call this knowledge search. Now it's going to ask me as far as what
are some of the different options that I want to work with. So how do I
want to filter this information? Do I only want to look at published
knowledge-based articles? Do I only want to look at approved? Do I want
to look at all draft articles? What are the options that I want to look
at when searching my situation? So again, I may have some articles that
are kind of ready to go and that I've published that are out there. I
may have some that are still kind of in approval state. So you can
define which ones you actually want to surface to your users, and then
using the checkbox option here, you do have the capabilities to define
whether or not the users can override that. You also have the ability to
define your language filter. So in here I can determine whether or not I
want the user to use their default language or if I have other user
options I want to work with. I also can have the user change the filter
language. So again, if my native language is English, but I'm working
with someone who primarily speaks German, I would be able to look to see
what articles are available in German, and if there's a German version of
that article, I would now be able to surface that as part of my search
results. The other situation that I can do in here is I can also turn on
different suggestions. So again, the whole concept of as I'm typing
functionality, this is where I can turn on kind of record suggestions.
So in here I would have the capabilities to define this based upon a
specific field value. So what field value do I want to use? And then I
can associate that field value with a specific item. And then I also
would have the capabilities to determine ratings on knowledge-based
articles and allow people to actually rate those individual situations
based upon specific fields as far as how people are working with it. So
I could work through and rate individual items from those situations.
But for right now, we'll just kind of leave it at this point. The nice
thing about this automatic suggestions is, this is also where some of the
machine analytics and machine learning, the text analytics functionality
comes into play. Because I could also, once I work through some of that
functionality, replace this field value with like a machine learning
definition and be able to use that to facilitate how that process looks
in the application. But here, you would go in and set this up for each
individual element that you want to work with, and once you've kind of
defined that knowledge search functionality and you've created that
option, now you just kind of position that to wherever you want it to go
on your specific form, and then you can save and publish your form and
then that will surface it inside the application so you can use it moving
forward. So in this case I'll just move it up here just a little bit.
We'll go ahead and save and publish, and then once this is published, now
I can go back into per se an account and I could see that that knowledge
functionality would be available directly in there, based upon if I have
any published articles or items that I've worked with. So I can close
out of here, I can close out of here. I could now go into sales and
accounts, open up a specific account, and now I can see options based
upon these situations. So here it's plugging in information based upon
the actual name of the item, but I could go in and type in different
elements. It'll search those options based upon those options. This is
where I can see my different relevance options and then work with
information from there. Now, we don't have a lot of published articles
at this point, but it gives you the idea to see the concept in regards to
what you could do here.
Module Review
So it's important to understand, if you are going to be using knowledge
management in any capacity, how that's ultimately going to be delivered.
Are you using it just strictly internally for internal users to access
some of that information or are you looking at external users coming in
through some type of portal methodology to be able to facilitate that?
Regardless of how it's going to be used, there's always that concept of
what are we trying to track, where do we want it to be available, how do
we want it to be associated with different items? And so by using
Dynamics 365, we have a lot of flexibility to determine how we build
these knowledge articles, when they're pushed out to the application so
they're available for people to work with, but ultimately how we track
analytics moving forward. So from a Dynamics 365 perspective, keep in
mind that if you do have a current Parature subscription, it's very easy
to link that information to a Dynamics 365 instance for better
consumption, but remember that that's ultimately something that's going
to be moving away at some point. And so realistically, using the
internal Dynamics 365 knowledge based instances do allow you to configure
that for searching and associate those searching results with really any
entity inside the application. The other option that's nice when you
start talking about knowledge management capabilities is categories, and
the category hierarchy structure can be defined to provide better
flexibility for how you want to be able to organize those knowledge
articles together as part of your implementation. And regardless of what
you're working with, all of that information can also ultimately be
exposed on an external portal. So now you have customers maybe coming
into a customer self-service portal to be able to work through that, but
you have several different configuration options that are available that
allow you when you're moving forward to be able to implement very robust
knowledge management solutions as part of your Dynamics 365
implementation.

Test Your Knowledge Questions:

1. You going to use Dynamics 365’s Positional Hierarchical Security feature. Your
organization uses the following positional structure.

 Sales People report to Territory Sales Managers

 Territory Sales Managers report to Regional Sales Managers
 Regional Managers report to VP of Sales
 VP of Sales report to the CEO

Which of the following Statements are true about the VP of Sales access to other records?
(Check all the Apply)

 A VP of Sales can read and modify Regional Managers Data *

 A VP of Sales can only read Regional Managers Data
 A VP of Sales can only read Sales People’s Data *
 A VP of Sales can read and modify Territory Sales Managers Data
 A VP of Sales can only read Territory Sales Managers Data *
Explanation: Dynamics 365’s Hierarchical Security features uses a Direct and Indirect Report
Model. When Positional Security is implemented, a user will receive Read and Modify access
to anyone the reports directly to their position. They will receive only read access to anyone
who indirectly reports to them. Example. CEO can Read and Edit VP’s data, but can only see
Managers data, because they report to the VP.
Reference: Positional Security

2. Which of the following statements about Dynamics 365 are correct? (Check all the Apply)

 The Positional Model can be used across Business Units

 The Managerial Model can be used across Business Units *
 You can use both Managerial and Positional Security at the same time
 You are granted either read or read and edit access to all entities in your hierarchy
*
Explanation: The only Hierarchy Structure that will span business units is positional security.
Since Managerial Security is still associated with specific accounts, everyone need to be in the
same Business Unit. You can only use one or the other, they both cannot be enabled at the
same time for your organization. You are granted access to all the entities that and owned by
people in your hierarchy
Reference: Hierarchy Security
Module 4
1. You have enabled Dynamics 365’s Knowledge Search Functionality for the Account entity.
Users are stating that they can search for Articles from the Web Client, but not inside of
Interactive Service Hub (ISH). What is the most likely cause of the problem?

 You are only allowed to use Knowledge Search from the traditional web app and not
ISH.
 The knowledge article, was marked to not display in ISH.
 You did not add the search control to the ISH form. *
 The knowledge article has not been published.

Explanation: The Knowledge Search control must be added to any form that it needs to be
displayed on. Since Interactive service hub has it’s own form, it the control is not added to the
form it will not be available.

2. You are going to publish Knowledge Articles up to an external portal. You need to supply a
valid URL on the portal ensure the articles are posted correctly. Which of the URL would
should you use?

 https://companyportal.com/knowledgebase/{kbarticle}
 https://companyportal.com/knowledgebase/{articlenum}
 https://companyportal.com/knowledgebase/
 https://companyportal.com/knowledgebase/{kbnum} *

Explanation: You need to provide a placeholder for the article to be created, and the
placeholder that is used is. {kbnum}
Module 05: Introduction to Processes
Module Overview
So up until this point, we've been talking about some of the baseline
configuration stuff that you would be looking at in regards to the
organization. The other thing that you have to kind of consider as far
as configuration and items go is how you're going to handle processes,
what are some of the automated situations that come into an environment
that you're working with. And so that's the ability to actually go in
and automate what people are doing to really provide them with a very
simplistic or one of a kind experience when they're working through it.
Now, processes are not necessarily the primary focus of this course and
there are courses that do specifically target processes. I do think it's
very important to understand what processes are available inside Dynamics
365 and what are some of the basic design concepts around them. The
types of processes that you're actually going to build and implement
inside your organization are going to be specific to what it is that
you're doing, and oftentimes the business processes or the business logic
that you have are going to reflect those different decisions. So what we
want to do in this particular module is just take a look at the different
processes that are available in Dynamics 365 and talk a little bit about
business process flows. Now, in the next module we'll get into business
process flows in a lot more detail, but just to understand what they're
used for, get into workflows and talk about where workflows fit into the
grand scheme of things, and also understanding how you will create
different types of workflows, whether it be a realtime workflow or what's
called a behind the scenes or background workflow inside the application.
We'll look at dialogs and where dialogs would be used inside your
instance, as well as custom actions, and then we want to show you just
how to create a Dynamics 365 workflow inside the application, so you
understand what's working through those individual situations.

Processes and Automation

As you're building and defining how people are going to interact with the
application, a lot of times you'll have different processes or procedures
that can very well be assisted by using Dynamics 365 processes. Now,
there's a lot of different ones and each one of them really fit a
different gap when you start talking about the grand scheme of the
application, but some of the ones that you would look at and some of the
key ones that we'll talk about over the course of this module are things
like business process flows. If you think about a business process flow,
it's really a process that you might have that might span multiple
entities within the application. So if you think about kind of like an
onboarding process or a lead to order process, it's going to start with a
lead, there's going to be several different things that you have to do
within the context of that lead, and then you'll ultimately qualify that
lead into an opportunity, and then you will do some different steps
inside that opportunity to hopefully ultimately move it into an order and
then into an invoice, and a business process flow can really help kind of
define what that procedural element looks like as you're moving forward.
You also have the concept of workflows, and workflows are really just
kind of automatic procedures that run either in the background or in real
time, depending upon what you need them to accomplish. So, for example,
maybe you want to create a follow-up task after an opportunity has been
created that reminds the salesperson that this opportunity's going to
close four days from now. So you set up a workflow that automatically,
four days before the opportunity's scheduled to close, creates a task
that reminds the person they need to follow up or call this particular
individual based upon those items. And then the other ones you might see
is like maybe a custom action, and a custom action is more kind of a
higher-end situation, but it basically allows you to create kind of your
own custom transactional API, maybe for like escalating a case or
something that could be executed through workflow actions. And we'll
talk just a little bit about each one of these in a little bit more
detail. Now, the first one we'll talk about is business process flows.
Now, we're going to get into business process flows a lot more in the
next module. So I'm not going to spend a ton of time on it here, but
really it's kind of what we talked about at the top of the last slide.
It's a guided process that may involve one or more entities or records
inside Dynamics 365, and what it does is it breaks those things down into
different stages. So, for example, you have the qualify stage that might
be associated with the lead entity. Once you've qualified that lead, now
it moves over into an opportunity that might have different stages that
are associated with that opportunity. I need to develop the opportunity
and define what specific products and/or services I'm going to do. Then
I may need to actually move on to the next stage, which would be
proposing. And during each one of those stages, there's going to be
specific steps that define what it is that I have to do as I'm working
through those. And what's nice about business process flows is,
obviously they're a guided process, but they also give you the
capabilities to make certain things as part of those business process
flows required. So as people are moving forward, they have to complete
certain elements before they can go on to additional steps. And like I
said, we'll talk more about business process flows in the next module.
Workflows are another key aspect to what you would be looking at. Now,
if you think about workflows from a simplistic standpoint, think of them
almost like a macro. I have something that I want to take place when X,
Y and Z is considered true. So they look at a specific situation and
then they run in those situations based upon criteria that we specify.
Now, what's kind of nice about these workflows is there's a lot of
different ways that we can execute them. We can have them tied to a
specific event. So, for example, when an opportunity is created in the
system, I want to evaluate certain criteria based upon when this
opportunity was created, and if this criteria is true, now I'm going to
go ahead and I'm going to fire this event inside the application. Or
they could be more of an on demand type situation, where based upon a
certain situation the user just pushes a button and then fires the
workflow automatically. Now, typically speaking, when you've talked
about Dynamics 365 workflows in the past, they've always been what are
called background workflows, which basically means that they're going to
kind of run in the background, which would allow the user to continue to
use the application while that workflow is executing. So, for example,
if you wanted to create a task or a phone call activity for you inside
the application, that's best to have that run in the background, because
otherwise we would prevent the user from moving forward. If it's a
background scenario, it creates that activity. Once that activity is
available, it shows up inside the UI and the user can use it. Sometimes
you need more immediate feedback. Sometimes maybe you need a value and a
specific field to change and you don't necessarily want the user to have
that take place or to be able to move on until that particular situation
has taken place. And in those situations, you can create what are called
realtime workflows and they almost work like a plugin. They're going to
fire inside the application UI and the user's not going to be able to do
anything with them until they finish. And we're going to show you kind
of an example of different workflows as we move through this module. As
I said, the background workflows are the ones you're going to see most
often. These are the ones that are going to be kind of triggered
automatically based upon maybe when a record is created or when a record
status changes, but they will run behind the scenes. So the user will be
able to still use this option and kind of work with it from there. This
is really nice, like I said, in that opportunity scenario where maybe I
want to create a follow-up phone call to call this person four days
before the opportunity closes. I could have a wait condition that says
wait until four days before the estimated close date on the opportunity,
then create this phone call task, so the person remembers that they need
to call this person back, or send them an email to remind them that they
need to call this person back. So it basically just sits there and kind
of runs in the background, but the user can still use the application and
kind of function as necessary when they're working through it. The
realtime is a little different scope. This says whatever I'm doing, I
will need to provide this feedback kind of immediately to the user as
they're going forward. So the major difference here is, instead of being
able to kind of still use the application, I really have to wait until
I've done something or until it's done. So the user's blocked and they
can't move forward. What's nice about this is, this does allow you to
control a little bit in regards to who the workflow is going to execute
as. Traditional background workflows will always execute as kind of the
owner of the workflow or the person who's created it, whereas realtime
workflows can either execute as the owner of the workflow or they can
execute in the context of the user that caused that workflow to fire.
Now, the only major thing you have to remember with realtime workflows
is, they may impact system performance or at the very least they may give
you the perception of an impact on system performance. If you already
have a slower system, causing somebody to have to wait for something to
take place might draw their attention to the fact that you have a slower
situation, whereas background workflows just execute. They may take a
few minutes to execute, but the user's not going to necessarily notice
that, because they can still continue to work through the application.
And we'll show you that a little bit when we get into the concept of
realtime workflows versus traditional workflows. Dialogs are more of a
script-type situation. So if you think about almost like somebody in a
call center, somebody's going to call in and you're going to open up kind
of a script and you're going to ask them a series of questions, and then
based upon how they answer those questions, they're going to be directed
into different areas. And so what happens with dialogs is they're
actually, like I said, presented a script that asks them a question and
then they use what are called prompts and responses to actually enter
that information in. So somebody asks me a question, I put my response
into a specific area, the application is available to analyze that
response, and then based upon that response, actually do something inside
the application. Now, the biggest difference between dialogs and
workflows is workflows can kind of trigger automatically, whereas a
dialog almost always has to be initiated as an on-demand process. But
the nice thing about dialogs is it uses the same functionality and the
same workflow evaluation features that a traditional workflow uses. The
only major difference is, they've got this concept of variables and input
parameter arguments that you can use to facilitate how you want users to
interact directly with that dialog. So the biggest difference with
dialogs versus workflows is dialogs don't necessarily have a waiting
condition either. Dialogs, once they're initiated, the user has to
interact with those dialogs and finish those dialogs before they can move
on. Dialogs traditionally don't get used as much as some of the other
options, particularly when you start talking about workflows and items,
but they do provide kind of a nice alternative anywhere where you really
need to have a very specific step-by-step or scripted process that
somebody needs to follow in order to move through the application. Now,
the other one that you have are custom actions. So custom actions are
situations that allow you to invoke functionality via API call. So if
you think about it ... we'll just kind of give you an example here. You
might have a scenario where you ship orders to different countries or you
ship orders to different states, and what a custom action would allow you
to do is to capture a variety of different input parameters. So, for
example, maybe we don't ship certain types of products to certain
countries or we don't ship certain types of products to certain states
based upon regulations that we might have. What a custom action allows
me to do is to declaratively define what those situations are where I
wouldn't necessarily ship that information. So I'm not going to ship
this product if this product contains environmental impact situations. I
can't ship it overseas for that situation. So what I can do is I can
create a series of input parameters that allow me to capture exactly what
it is that I'm doing. So what is the product that I'm trying to sell and
what is the state and the country that I'm trying to ship that to? And
it'll evaluate those items together and it'll say OK, the product is this
product which has environmental impacts, but it's going to this state,
which is fine because they allow us to ship that situation. So it
captures that information as input parameters, and then from an output
parameter, it basically tells us yes or no, we can ship that information.
And so what's nice about these custom actions is, these allow people who
have a very deep understanding of what your business logic is to build
these within the application. Now, the cool thing about these custom
actions is they can be run and invoked many different ways. They can be
invoked from JavaScript if you want them to, they can be invoked through
a workflow, but they will raise a specific message within the application
as well. So you also could have a scenario where maybe you want a plug-
in to execute based upon when this allow shipping custom action is
actually constituted within the application. The other thing that's nice
with these custom actions is they can be associated with a specific
entity or they can be what are considered global custom actions, which
means they're not necessarily attached to a specific entity. So now I
could grab custom input parameters from different entities within the
application, and so the other thing that this provides is a little bit
more flexibility over our traditional workflow where you almost always
have to have them associated with a specific entity inside the
application.

Business Process Flows

So how do these fit in or when might you use them from inside a Dynamics
365 application? So let's take a look at business process flows first.
Traditional, like a case resolution process. So a new case is maybe
going to be submitted via a phone call. Eventually that case is going to
be ... or that phone call is going to be converted into a case and then
you're going to work that case through the different resolution process,
and at each phase or stage of that resolution process, there are steps
that need to be done, and so a business process flow is a great way to
guide people through them. The same type of situation from an insurance
quoting standpoint. There's different checks and balances options that I
have to capture during that insurance quoting process. So based upon
where I'm at, there's items that I have to facilitate moving through.
It's also nice with sales processes or training tools. If you've got new
users, you want to make sure that you're kind of guiding them through the
way that you do business. Really if you think about it from a business
process flow standpoint, anywhere you have an outcome that you want to
achieve and there's very specific measurable steps and stages that define
how you get to that outcome, a business process flow works great from
those perspectives. Now, the other option will be workflows. So a
workflow where you might see those is any time you want to trigger
automatic communication. I gave the example of a follow-up phone call or
I want to create a follow-up task, but realistically there might be
scenarios where based upon what was entered into a specific record, I
want to evaluate certain situations. So maybe somebody has modified an
account inside the application. I want to check to see if they've
changed this field or this field, and if they have, based upon that,
maybe there's other information inside that record that I need to update,
so maybe I want to go ahead and make some updates to a record. Any time
you have manipulation of the application that you want to be able to have
happen automatically, a workflow is a great way to be able to facilitate
that. Dialogs work really good for any type of scripted scenario. So
obviously agent scripts work very well, but also maybe you need to
capture missing data. So maybe a lead has been entered into the
application, but you're missing like an address and a phone number.
Well, a dialog could be initiated to be able to look at that lead, figure
out what specific fields are missing data, prompt the user to ask for
those options and then capture that missing data, and then once they
complete that situation, it would then go ahead and plug that missing
data into that lead. Or I've also seen them done for billing errors and
adjustments. Somebody's disputing a billing situation, you have a dialog
that pops up. It says OK, what is the reason for the billing error?
Here's the reason. What was the original amount? It pulls in from that
record, it determines what the original amount was, and then it goes out
and allows you to determine what the new amount is and then apply that
from there. So anywhere you really need kind of a guided process to send
people through. And then from a custom action standpoint, any time maybe
you're doing custom approval situations. We've seen people do them even
for like sports organizations with ticket brokering situations, where
they supply a situation that says here's the date of the game that I'm
looking for, here's the number of tickets that we're looking for, here's
the price range that we're looking for, and now we have a custom action
that maybe executes a plug-in inside the application that goes out to a
ticket brokering software and says here's all the items that meet that
criteria, and now you have access to this for five minutes to determine
whether or not you actually want to select those seats. Those are the
kind of examples of where you might see some of these different elements
come into play as part of the application.

Workflow Basics
So the next thing I'd like to do is actually take you in and just create
a workflow. But before we do that, let's just talk about some of the
basic things that you have to understand around creating the workflow,
and then we'll get into the actual design elements and take you into the
designer. The first thing is, whenever you're creating a workflow, a
workflow has to be associated with a primary entity. So for example, if
I'm going to create a workflow that's going to trigger some type of
functionality based upon an opportunity being created, that opportunity
is going to be the primary or the triggering entity within the context of
that application. Now, the thing to remember with that entity ... that
entity's important, because that entity is going to define when that
workflow functions inside the application. And the biggest thing to
remember is, once you define what the entity is for a specific workflow,
you cannot make any changes. So once I say OK, this workflow's going to
be associated with the account entity, I can't change that when I'm
moving forward. The only real way that I would be able to facilitate
that would be by going in and creating a different workflow with a
different entity. Now, the other thing is, when you start talking about
workflows, again there's a couple of different types. There's the
background workflow and then there's the realtime workflows. Background
workflows can be triggered a couple of different ways. They can be
triggered automatically, so they can be triggered based upon something
happening in the application. Somebody's created a new record of that
entity type, somebody's gone in and assigned ownership, so they've
transferred that record from one user to another user. Maybe they've
gone in and edited specific fields. Those are examples of things that
could trigger this functionality automatically. The other option would
be to basically create it as an on demand workflow, where somebody has to
go up to the command bar, hit the button for running that workflow, and
that's going to execute the workflow itself. Now, the other option you
can do is what are called child workflows, where I could actually
initiate a workflow through another workflow. So you sometimes will see
this done from like an opportunity perspective, where maybe I have a
concept of a large-scale and a small-scale opportunity. I have a
specific triggering functionality that I want to do if an opportunity has
an estimated value of more than $50,000 and I have a specific thing that
I want to do if it has an estimated value of under $50,000. So I might
create a workflow that just evaluates what's the estimated revenue for
that opportunity, and if it's more than a hundred thousand, it's going to
trigger the high-end workflow. If it's less than a hundred thousand or
less than 50,000 or whatever that threshold is, it might trigger the low-
end workflow. And that's a real common way that not only can you make
triggering and streamlining this process a little bit more effectively,
but because you have a bunch of smaller workflows running within the
context of the application, it can also make troubleshooting a lot
easier, because now you can see what specific workflow is causing the
issue and you can go more targeted on those individual steps. Whereas if
you have one workflow that's got a bunch of different steps, sometimes it
gets a little harder to really pinpoint exactly where that process is
where you're having the breakdown. Now, the other thing to remember is
each workflow that you create, particularly if it is a background
workflow, will have an owner. And in background workflows, when that
workflow executes, it's going to execute as that person. So for example,
if I create a workflow that multiple people might use in the application,
that's fine, but when that workflow runs as a background workflow, it's
going to execute as me. And so there are some design things that you
have to keep in mind as you're setting these individual situations up
inside the application.

Creating a Basic Workflow

So the easiest way to actually walk through this is just to go in and
create a workflow. Now, with that being said, there are ... if you refer
back to the documentation and to the slides that you can download as part
of this course, all of the information that we're going to talk about
here will be available in those slides, so you can reference them. It's
just easier to be able to kind of see it from the context of a demo. So
we're going to go ahead and just create kind of a basic workflow that
modifies some baseline information. So I'm going to just go ahead and go
into settings and processes, and so this is going to take me into my
process center. This is where if I wanted to create a business process
flow, if I wanted to create a dialog, a workflow, even a custom action,
this is where I would be able to facilitate that inside the application.
Now, it's going to show you a few different processes. It's going to
show you first and foremost the processes that you've kind of designed or
that you're the owner of, but then it's also going to give you the
capabilities if you wanted to switch and just see all processes that
would be in the application, you could switch it to those options and see
what specific processes are in the system, regardless of who's created
them. Now, these are just some business process flows that kind of ship
as part of the application itself that are automatically activated or not
activated, depending upon the situation. Now, we're just going to go
ahead and create kind of our own process. So I'm going to go ahead and
click on new, and it's going to ask me what do I want to call this, and
I'm just going to call this Sample Op Process. What is the category?
The category in this case is going to be a workflow. And then what is
the entity that I want to base this off of? So this is that thing that I
don't have the ability to change once I'm coming in here. So I'm going
to go ahead and just click on opportunity. Now, the thing that you'll
notice here is it's got an option that says, do you want to run this
workflow in the background? This is that kind of background based
workflow that we talked about and this is the default. If you wanted to,
I could uncheck this and this would now allow me to create what's called
a realtime workflow moving forward, but in this case we'll just go ahead
and kind of leave it as a background workflow. Now, the other option is,
as I'm working through this, I can create these as kind of workflow
templates and blank process templates, which would allow people to more
streamline the process of creating the information as they're moving
forward. Now, I'm not going to worry so much about that at this point.
We'll just go ahead and leave it as kind of a workflow with a blank
process, and then we'll go ahead and click on OK. So this is going to
open up and create my workflow that I can use to kind of define what I
want to work with. Now, again, down here where it says activate as and
it says process, this is where if I wanted to save this as a template to
make it available moving forward as a template, I certainly could, but in
this case we'll just go ahead and leave it as a process. The first
option that you'll see here is available to run. So right now it's
running as a background process based upon a triggering action that takes
place in the application. You'll notice that I have a couple of
different options here. I could have this run as an on demand process.
So this would basically mean that somebody would have to go up, push the
button to execute the application, and then have it take place. The
other option that I have is a child process, and this would mean that
this could now be executed through another workflow in the application.
Now, this is going to be a traditional asynchronous workflow; so that's
why run in the background is always going to be there. Right now it's
going to be triggering based upon only when a record is created, but if I
wanted to, I could also make it as on demand. So if somebody just checks
the button to actually run it, they could, or I could do it as a child
process, which means it could be created when a record is created or run
as a child process, or I could just uncheck this and just have it run as
a child workflow. Really, you just have to look at what the situation is
in regards to when you want this to run, and then that will allow you to
determine which one of the specific options you may need to check or not
check as you're moving forward. Now, the other thing that I want to draw
your attention to is the administration tab. So if you look up here on
the administration tab, this tells me that I am the owner of this
workflow. So typically when you create a workflow inside Dynamics 365,
you are going to be the owner of that workflow, which means that when it
executes, if there's any specific functionality that it's trying to do,
it's going to execute as you. So, therefore, any security settings or
anything like that that you may need to have in place, you need to make
sure that you are defining and setting up for the person who this
workflow is going to execute as. This is also a big deal when you start
thinking about the scope of the workflow itself. So for example, if I
come back to general, I can look over here on general and I can see that
there is a scope option that is associated with this workflow. And if I
click on the dropdown, I can see that the scope can be set to user,
business unit, parent/child business units, or organization. So if you
think about when we talked a little bit about security roles and
privileges and access levels, the scope is very much kind of the same
situation. So for example, if I leave the scope at user, which is the
default, it looks at who the owner of the workflow is. And so in this
situation, if this workflow is going to run whenever a new opportunity is
created and the scope is set to user, this is going to run whenever I
create a new opportunity inside the Dynamics 365 implementation. If
somebody else creates it, it's not going to execute. So you do need to
look at, when you are creating these workflows, when should this take
place. Should this take place only when a specific user is adding this
functionality or should this take place when somebody else inside your
organization is doing something? And that's where you can now define the
scope. So if I were to set this to business unit, now any time a user
who belongs in the same business unit as myself, since I'm the owner,
actually creates a record, then it's going to go ahead and constitute
that in the application. The one that you'll probably see most often
would be organization. So now from an organizational standpoint, anybody
who creates a new opportunity inside Dynamics 365 is going to have this
process run automatically within the system. Now, what I can do here is,
this is where I configure my triggering action. So right now it's when a
record is created, but I could do this when a record status changes. So
if somebody closes an opportunity, that's considered a status change.
Would I want this opportunity or would I want this workflow to execute?
Or maybe a record is assigned, so I have an opportunity that is
associated with my account, but now I'm going to go ahead and I'm going
to assign that opportunity to somebody else in the system. Do I want
this process flow to run? This would give me the capabilities to
facilitate that. And then finally, the other option that you would see
here would be record field changes. So in this situation when I go to
field changes, this is where I can actually look at specific fields
inside the application and say OK, if somebody modifies this field or
this field, now I want this workflow to execute. And this is really nice
particularly when you're looking at changing of individual situations,
because you wouldn't necessarily want this to run every time the record
is changed. You would only want it to run when specific fields have been
updated, and this now gives you the ability to kind of constitute when
that process or when that change might take place inside the system
itself. And then finally, the other option that you have is when a
record is deleted. So if somebody's going to delete a record inside the
application, what do I want to take place as I'm moving forward with
that. So this is where you would kind of define OK, what is going to be
the action or the situation where this workflow is going to take place?
And it's a combination of the different items that you'd be looking at.
In this case, we'll say we're going to let this run any time anybody
inside our organization is creating a new opportunity inside Dynamics
365. So now I can build my workflow. And so if I come down here, this
is my workflow edit area or design area, and one of the options that we
see in here is this add step concept. So when I click on add step, these
are the different steps that are available to me from a workflow
perspective, and I'm going to just scroll down here just a little bit, so
you can see this a little bit better. So the first thing that you'll see
is I have what are called check conditions and I have wait conditions.
So realistically maybe I want to check something out first. So when
somebody creates an opportunity, do I want to look at the estimated
revenue? And if the estimated revenue is above a specific amount, do I
want something to happen or do I not want something to happen? The nice
thing about the check condition scenario is I can add different
conditions. So I can say look to see if this condition is true. If this
condition is true, do this. If it's not, check to see if another
condition's true, and then I can start working my way down the process.
The other option that I have is a wait condition, and this is only
available because of the fact that this is a background workflow, but
this is now saying OK, I want you to wait for specific criteria to be
met, and then based upon that criteria, I want you to go ahead and
facilitate execution of something inside the application. Now, in this
case I'm going to just go ahead and say check condition, and now we're
going to configure our condition. So this is going to say check for
above 50,000 revenue. Now I'm going to click to configure my condition
and I'm going to say OK, if something takes place ... so in this case if
the opportunity has an estimated revenue, so I'm going to go down to
estimated revenue ... and if that estimated revenue is greater than or
equal to $50,000, I want to do something. So now I'm going to save and
close this condition, and now I have to define what it is that I want
them to do. So maybe in this case I just want to create a follow-up
phone call inside the application. So in this case, if the opportunity
is greater or equal to 50,000, I want to create a phone call. So I'm
going to click this option here that says select this row and click add
step. I'm going to add a step, and now I'm going to define whatever this
is that I want to do. So I could create a new record inside the
application, I could use update record, which would go in and update this
existing opportunity based upon my criteria, I could assign the record to
somebody else, I could send an email to somebody. If I had a child
workflow that I wanted to process or create, I could start a child
workflow. Maybe I have a custom action inside the application that I
want to execute, I could kind of do that as well. In this case, we'll
just go ahead and create a new record and we're going to specify what
type of record we want to create. So when I click on the drop-down arrow
here, I'm going to say that I want to create a phone call. So I'll find
the phone call entity, then I'm going to go ahead and hit set properties
and I'm going to define what specific scenario I want to create for this
phone call. So this phone call is just going to be called Follow-up
Call. The call is going to have to come from the owner of the
opportunity. Now, in this case the owner of the opportunity is going to
change based upon whoever created that opportunity in the system. So
this is where I can do what are called dynamic values. And so what I can
do in here is by selecting call-from, I can actually come over into
what's called form assistant, and this form assistant allows me to look
for specific information as part of the application. And so I'm going to
look at the opportunity, but I'm going to look at ... from an opportunity
perspective, I'm going to look at who this call might be coming from. So
this is where I could look at the owner or something to that situation.
So in this case I'm going to come down here and I'm going to look at the
owner of the opportunity and I'm going to look at the owner created by,
and now we're going to go ahead and hit add and OK, and this now says
that it's coming from the owner of the opportunity. Now I could say, who
am I calling? Well, I'm going to be calling the opportunity potential
customer. And so now I can hit add here, and then if I wanted to, I
could define a default value, but in this case we'll just hit add and
we'll hit OK, and now it's saying that we are calling the potential
customer who is set to this opportunity. And then what phone number do
we want to call? This is where I could now come in and I could look at
specific situations based upon who the customer is and I could define
maybe the phone number field that I wanted to work with. Or in this
case, I could come up here, I could now look at related records and I
could say OK, look at the account that's associated with this opportunity
and find the phone number that we want to call. So we'll come down into
here and we'll look at the phone number, and let's just say ... where's
my phone number field here? Here we go, we'll just do Address 1
telephone. So you pick your field. So in this case we'll just pick
Telephone 3, which is fine. We'll hit add and then OK, and now this
defines what the option is. So this is going to create a phone call,
it's going to call it from the person who created the opportunity, the
call is going to go to the potential customer, and it's going to use the
phone number that we've kind of specified to the situation. This is just
creating the activity inside the application. Now I'll go ahead and I'll
save and close this. So now I have to define what I want to do next.
Well, if it's less than 50,000, what's my next option? So this is where
I could now come up into here and select kind of this entire condition,
and now I can go up and hit add step and I can see that I have only a
couple options here. I could do another conditional branch or I could do
a default action. Whereas if I don't have the entire thing selected, if
I just have the step selected, now if I hit add step, I'm actually adding
another step to this particular part of the condition. So this is where
you have to be a little bit aware of what you have selected inside the
app. In this case, we're going to go ahead and add a default action that
just says if the estimated revenue is not more than $50,000, then all I
want you to do is we'll just say send an email. So in this case I'm
going to go ahead and add a step. I'm going to send an email. I'm going
to create a new email message. I'm going to hit set properties and I am
going to send this email from the owning user of the opportunity. I am
going to send it to the potential customer on the opportunity. The
subject is going to be follow up on opportunity, and we'll just put don't
forget to follow up on the ... and now I'm going to go into opportunity,
I'm going to switch this to topic, add, and OK. So now this is going to
create an email that's going to follow up with the name of the topic of
the opportunity automatically kind of pre-populated. And then I could
just go in and I could fill in any other additional information on this,
based upon the items that I wanted to. In this case, we'll just go ahead
and leave it at this. We'll go ahead and hit save and close, and now my
opportunity or my workflow associated with this option is created and
ready to go. Now, as you can see, this is a very simplistic situation,
but at the same point in time it does give me a variety of different
options available to it. So these can be as standard or as complex as
you want them to work with. Now, once you're done, you just go ahead and
you activate the workflow inside the system. So I'll go ahead and
activate this workflow. It'll ask me if I want to confirm the
activation. I'll say yep, go ahead and do that, and now this workflow is
ready to go. And you'll notice that I really can't make any changes to
it at this point. So now I'm going to go ahead and I'm going to just
close out of here, I'm going to go back into sales and opportunities.
I'm going to create a new opportunity inside the system and I'm going to
create this opportunity as a small-scale opportunity and have it send an
email to the individual person. Give this just a second. So now I'm
going to go back into and create a new opportunity. We'll call this
Derik's Sample, we'll associate it with a specific account, enter an
estimated revenue of $25,000 and an estimated close date of end of the
month. Now I'm going to go ahead and save and close this opportunity.
Now, the big thing to remember here is, this is what is considered a
background workflow. So this is not necessarily going to execute it in
real time. This is something that will take a minute or two before the
actual email activity would be generated in the application, which
normally would be fine, because in this situation I would more than
likely be moving onto something else and clicking onto another item
inside the application. However, if I open this back up and I go into
activities, there is that email activity. So here's that email that got
auto-created as part of that workflow process. So these workflows are
just an excellent way that if you have specific types of automation
processes you want to bring in, that you can go ahead and kind of
facilitate that inside the application.

Convert a Workflow
So in this situation, what do I want to take place? So it's the same
type of concept. The difference here is, what I want to do is I want to
hit convert to realtime workflow. So what this is going to do is rather
than having this run in the background, this is actually going to run in
a situation where it's going to run kind of automatically and it's going
to kind of prevent users from doing anything with it. So what you'll
notice here is I still have a lot of the same options. I can run this as
an on demand process if I wanted to. So it's still something I could
execute manually. I could also have this run as a child process, so I
could have this run within the context of another workflow. But now what
you'll notice is I have different options around how this automated
process works. So I still have kind of my same situations where I can
have it work when a record is created or when a status changes or
something is assigned, but the difference here is now I have the ability
to have this execute in different situations. And so you'll notice here
I still have my concept of scope, and we'll set this as organization just
like we did before, but now what this scope process refers to is what's
referred to as the database transaction process. So basically what this
means is, I could have this actually manipulate some of the information
as part of how the information is committed to the database, but I could
have it happen as part of that database transaction either before CRM
does its thing or after CRM does its thing, what's called kind of the
main platform operation. And now depending upon the type of situation
that it is, you have the ability to have it actually either occur after
or before the database transaction. We're not going to get into that a
whole lot, but the big thing to understand is, when a record is created,
you really have to have the record get created as part of the database
and then it will allow you to manipulate the information before it truly
commits it to the actual database, which is why after is the only option
you see when you choose create it. If I come down to record field
changes, I can actually have this manipulate either before the main
platform operation or after the main platform operation. So before CRM
kind of does its thing inside the database, do I want to tweak a couple
of values so those are being used prior to it actually going through and
doing it ... still part of the database transaction but just happening
before ... or do I want it to happen after? So like an auto number type
thing would happen after. The record has to almost be on the verge of
being created as part of that transaction, then it's going to go out and
determine what the most recent number is and use that as part of the auto
number situation. In this case, we'll just go ahead and have it run as
after. Now, you'll notice that when I go to record is deleted, the only
option I have is before. Because once kind of the initial operation of
CRM deletes that record as part of the transaction, none of that
information is going to be available for me to use and report back as
part of this process. So what before says is, if I want to capture some
of that information and put that into like an email or something like
that, letting somebody know that this record has been deleted, I would
have to capture that information before CRM does its thing. Otherwise, I
wouldn't have that information available to use as part of the option.
So each one of these has a little bit different triggering scope that
defines what takes place in here, but in this case I'm going to just go
ahead and say after the record is created. And now in this scenario, the
other difference that you'll see here is, how do I want this to execute?
So I'm going to have this perform some type of update or do something in
the application. Do I want this to perform the update as the owner of
the workflow or do I want this to perform the update as the person who
made the change inside the system and actually caused this functionality
to fire? In this case I would want to do it as the person who made the
change in the system and caused the functionality to fire. So I'm going
to leave it as this option. So now I'm going to go ahead and just add a
step and say OK, what do I want to do. So just like I had before, I have
my condition options. We'll give this just a second here. Scroll down
so you can see it a little bit better. I'm going to check condition and
I'm going to say if ... and we'll just look for a certain field here ...
if the account relationship type equals customer, I want to do something.
So in this case we'll go ahead and hit save and close. And what do I
want to do? In this case I'm going to go ahead and select row to add a
step, and in this case I'll go ahead and add a step and I'll say I want
to update the account record. So I'm going to click on update record.
It'll assume that because this was fired off of the account entity, that
this is the entity I want to update. That's totally fine. So I'm going
to go ahead and hit set properties, and I'm going to define what specific
fields I want to update inside the application itself. So in here, I
could go ahead and define what specific items I want to update. Now,
just for simplistic purposes within this scenario, I'm going to come down
in here and I'll set the industry to ... let's just say consulting, just
so you can kind of see how that process works. Normally I'd probably
have some other conditions in there, but in essence of time, you can kind
of get the idea. I'll hit save and close, and then I'm going to go up
and select my entire condition again. And at this point, I'm going to go
ahead and hit add step and I'm going to add a default action, and in this
case the default action is if they are not a customer or relationship
type is not set to customer, then all I'm going to do is add a step to
stop the workflow. Now, the major difference that you're going to notice
here is, this is going to take place in real time. So again, I'm going
to go ahead and activate this just like we did before. Once my process
is activated, now I'm going to go ahead and close out of here. I'm going
to go back into sales and account, I'm going to add a new account. We'll
call this sample account, set the relationship type to customer. Now if
I scroll down into my details, I can see that industry does not have
anything in it. I'm going to go ahead and save the record, put in an
account number, and now I can see after it saved it, consulting has been
pre-filled in. This is an example of the realtime scenario. Now,
there's a lot of other things that you can do with these realtime
situations. This would be where we could invoke custom actions, but you
need to really look at which one's going to work best for what you're
doing. Now, the real time is nice because you get that immediate
feedback, but remember that, again, if you have performance issues, stuff
like that, sometimes this can really highlight it. So really look at
what would be the use case and why you would want it to be real time
before you actually make it real time. I always like to tell people just
because you can make it real time doesn't mean it always has to be. But
these are two great ways that you can now start automating how that
process takes place. Now, the other thing that's really nice about these
workflows is, when I say a record is created, it doesn't have to be
created from within the user interface. It could be a record that gets
imported into the system and now it just evaluates certain criteria based
upon those options getting imported in and the workflow still executes
that information moving forward. So these workflows and dialogs and all
these different processes can be a real nice way to really automate and
start customizing and tailoring the application based upon what you want
to accomplish, based upon how the information's being either put in or
what the information is that's being put in.

Module Review
So as you can see, automation inside Dynamics 365 can be done many
different ways, based upon whatever it is that you are specifically
trying to accomplish. And the other consideration to that is really how
much interaction you want the user to have based upon what it is that
you're trying to accomplish. So you can really look at here's what I
want to take place and here's how I want to trigger that functionality to
define how you want your automation process to work. Workflows are a
great way when you're looking at automated triggers to be able to
facilitate commonly used processes inside the application and
specifically if you want them to be created by non-developers. Now, the
other option that you would have would be business process flows, where
you can use those as kind of a way to guide users based upon different
stages and steps that might work through multiple entities, but don't
forget about dialogs. Dialogs are nice because they're really more of
the wizard-based situation, where you click on a button and now you ask
people a series of questions, and based upon those different questions,
they will now interact and work with information from there. The big
thing that you want to really always keep in mind when you start working
through these situations is, they do allow you to manipulate data, they
do allow you to work with simplistic type functionality, but they also
give you the capabilities to work through different options. You just
want to make sure that you're always trying to find kind of a proper
balance, based upon what it is that you're trying to work with, just to
make sure that you're not over-automating, because you obviously can do
that as well. So they do give you a nice way to automate the system, but
just be aware of as you're using them, make sure you're targeting them
based upon the specific use cases that you want to work through.
Test Your Knowledge Questions
1. You would like to create a process that can be used to capture specific address information
that is missing on a lead. You want to find which information is missing, and then prompt the
user to enter it. Using the information entered you also need it to update the original record.
Which process would you mostly use to accomplish this?

 A Real-Time Workflow.
 A Dialog. *
 A Background Workflow.
 A Custom Action.
 A Business Process Flow

Explanation: Dialogs provide a wizard like experience where users are presented with screens
to capture information. They allow the user to interact with the pages through Prompts and
Responses. Based on the data captured Dynamics 365 can perform an action such as updating
Records.
Reference: Processes and Automation

2. You have created a workflow that should run every time a user creates a new lead in the
system. You have activated it and verified that it runs when you create a new lead. However,
the workflow does not run when any other user regardless of who they are creates a lead.
What is most likely the reason?

 You set the Scope of the workflow to organization.

 You set the Scope of the workflow to User. *
 You set the Scope of the workflow to Business Unit
 You Set the Scope of the workflow to Parent Child

Explanation: A workflow Scope can be set to one of four options:

User: (default) Runs only on records owned by the same user as the workflow owner
Business Unit: Runs on records owned by users in the same business unit as the workflow
owner
Parent: Child Business Unit Runs on records owned by users in the same or subordinate
business units as the workflow owner
Organization: Runs on any record owned by any user in the organization

Reference: Workflow Basics – Workflow Scope

3. Which of the following actions is available from Dialogs, but is not available for Workflows?

 Create Record.
 Perform Action.
 Change Status.
 Query Dynamics 365 Data. *
 Explanation: In addition to many of the standard actions that are available with Workflows,
Dialogs also provide the following options: Add Pages to capture Prompt and Responses,
Query Dynamics 365 Data, Link Child Dialog, they can also capture Input Arguments and
Variables.
Reference: Processes and Automation – Dialogs

Module 06: Business Process Flows

Module Overview
In the previous module, we talked about processes and using things like
workflows and dialogs, and we even touched a little bit on business
process flows. You know, a lot of organizations will have very specific
process that they use when they're trying to perform specific tasks. So,
for example, you might have a situation or a process that you use for
selling specific products or services that you're working with. The
thing about processes is, processes might be associated with one specific
record within the application, but they might also start with multiple
records inside the application. So, for example, it might start with a
lead and then it might move to an opportunity, and then from that
opportunity, it might specify a specific quote, and then once that
quote's been delivered, it might move to an order and then it might move
to an invoice. Regardless, each one of those situations will probably
have different stages associated with them, as well as different steps
that are working through it. So during that process, you want to make
sure that you understand what specific tasks are going to be
accomplished, because each one of those tasks may have a direct impact on
whether or not we win the deal within the application. So by using
business process flows, companies now have the ability to actually go in
and determine what needs to be accomplished during each one of those
phases, define whatever that specific criteria is, and allow you to move
forward. So in this module, what I want to do is really just provide you
more of an overview in regards to what business process flows are, but
also start going in and examining how the stages and the steps and the
different categories inside a business process flow will affect when
you're working through it. We're going to look at some of the different
cases where you might want to go different directions based upon
conditions that are met inside a business process flow. So if this takes
place, now we're going to go in this direction versus the other
direction. We're also going to talk a little bit about how workflows can
interact with business process flows and some of the options that are
available with some of the newly redesigned business process flow editors
that's a part of Dynamics 365, and then just look at options for
triggering business process flows based upon security roles and what
specific security role I might have associated with my CRM user record.

What are Business Process Flows?

So you remember we talked a little bit about it in a previous module.
Business process flows are processes that guide users through something
that's very common as part of your organization, and the nice thing about
business process flows is they may span multiple Dynamics 365 records.
So if you look at the bottom of this slide, this is a very good example
of what you would see from a business process flow perspective, is we
have a qualify stage, which means we're probably going to start with a
lead and we're going to qualify this lead into an opportunity. Once we
develop or once we've qualified this lead into an opportunity, now we're
going to go into the develop phase, and during that develop phase, we're
going to have specific things that we need to do to develop this
opportunity, to determine what specific items we want to try to sell this
person on. And then we would go into like the propose stage. Now,
what's nice about these business process flows as part of Dynamics 365 as
well is it does give you the capabilities to actually go in and look at
the opportunity or look at the process itself and see how long it's been
active. So if now you're starting to look at situations where things are
not getting resolved as quickly as you'd hoped or different items from
that scenario, we now have kind of a ticking symbol that determines to us
how long this process has been invoked within the application itself.
Now, what's neat about this is, as you can see within the qualify,
develop and propose stage, there's different steps that are basically in
there to kind of map what the user's trying to do. So within the propose
perspective, I need to identify who the sales team is and determine
whether or not I've done that, I need to develop the proposal, I need to
complete an internal review of that proposal, and then I need to present
that proposal to the customer. So as I'm going through and marking each
one of these individual things off of the list, I can actually make some
of these options required, therefore saying I can't close this particular
opportunity until I've completed every single one of these steps. So
particularly if you're looking at it from an onboarding process, it's
nice because now I can make sure that as a new person coming into my
organization, we can clearly define here's the five, six, or seven
different things that you need to accomplish before you can move forward
with whatever it is that we're trying to do, as we're kind of moving
these items through.

Enabling Business Process Flows

Before you can use business process flows for a specific entity, you do
have to enable it for the entity. So you do have to go in and define at
an entity level that this entity is able to be used and participate in
business process flows, and we'll show you that as part of the demo as
well. Now, what happens is, once you associate or say that an entity's
available to be used in business process flows, every business process
flow you create will start with a primary entity. So it's kind of like
when we talked about workflows in the previous module. You say OK,
here's the entity that this business process flow is going to be
associated with. Now, it's really just from a triggering perspective,
because once the entity ... or once the business process flow has been
triggered, that business process flow can span multiple entities within
the application itself. So what's nice about that is, OK, this might
start with a lead, but it can go from a lead to an opportunity, to an
order, and so on and so forth as part of the application. Now, as these
business process flows are being used and as people are executing the
information in these business process flows, all of the changes that are
being used are evaluated in real time. So as people are clicking on
things and as people are selecting options and stages are changing, it
will automatically make adjustments based upon how people are interacting
with that record. So you really truly do get realtime feedback as part
of the application. Now, there are out-of-the-box business process flows
that ship as part of the application and are enabled by default. A lot
of those are typically going to be associated with cases and
opportunities, and there's even several that are associated with the
knowledge management functionality in the application. Now, there's
additional business processes that you can turn on inside settings in
data management. There's ready to use business processes that you can
enable. This will turn on additional processes throughout the
application. Now, once they're enabled, you can't necessarily turn off
the set of business process flows, but if you ever decide that you don't
necessarily want to use them, you don't have to. You can deactivate a
business process flow if for whatever reason it's just not fitting your
needs anymore. Now, the nice thing with Dynamics 365 is they've actually
changed the business process flow editor from a previous version. So if
you have experience with business process flows, this is going to look
very different. Conceptually, it's still very much the same in regards
to how things are structured, but in the past it used a much more text-
driven editor as opposed to kind of the drag-and-drop editor that you'll
see here. So this process window now gives you the capabilities to drag
specific steps and conditions into the application, so you can really get
more of a dynamic flow in regards to what's taking place. So what you're
seeing here is kind of the standard lead to opportunity business process
flow. It starts with a lead ... that's going to be the qualifying
stage ... then it moves to an opportunity, which is the develop stage,
and then once the develop stage has been done, then it moves into a
propose stage, and what I can see in here is these individual numbers and
items that are associated with it. This tells me the number of steps
that each one of these stages has in the application. And then this
little circle option or kind of continuous rotation circle basically
tells me any workflows that I might have associated with each one of
these stages as well. And we'll get into this in much more detail here
in just a couple of minutes. So what you'll see here is just an overall
visual design that shows you how this business process flow is going to
function inside the application. Now, from a component standpoint,
there's a few different types of components that are associated with
business process flows and they're really kind of broken down into two
phases. There's the flow phase and then there's the composition phase.
Within the flow phase, you have your stages and your stages are what you
would consider those major or primary accomplishments within the
application. I'm going to qualify this lead, I'm going to develop this
opportunity, I'm going to propose this opportunity, I'm going to
create ... I'm going to create my order, or whatever that situation would
be. There's also conditions, and so these conditions allow you to branch
off into different stages based upon steps or items within the previous
stage. So let me give you a good example of where you might use
conditions. Maybe you're working for like an auto company and you have a
business process flow that goes through and one of the items that you
evaluated in regards to that business process flow is, are they buying a
new car or are they buying a used car? Well, if they're buying a new
car, odds are they're going to get that three-year, 36,000-mile warranty
on that new car. If they're buying a used car, now we want to maybe send
them to our after-market scenario and we want to try to sell them on one
of our service contracts. Once we've determined whether or not they want
to have a service contract, now we're going to go back into the business
process flow and try to determine financing, just like we would do for a
new car. And so this is where from a condition standpoint I could have
it kind of veer off into a different direction based upon something that
was selected and then move back into the business process flow once we've
defined how that process works. Now, within the flow, there's also what
are called the compositions and the compositions are the individual
items. So a stage will have steps and those steps are really just
Dynamics 365 fields within the application. So you saw in a previous
scenario did I determine who the decision-maker was, have we identified
the team that's associated with this. This now gives me the capabilities
to say here are the specific fields or steps that I need to fill out as
part of this business process flow. And then the other option that we
have is workflows. So now when I go into a specific stage or I exit a
specific stage, if I want to have a workflow trigger inside the
application, I would have the ability now to facilitate workflow creation
based upon entering or exiting a stage as part of the business process
flow. And this process is actually kind of neat, because this is brand
new to Dynamics 365. We didn't necessarily have workflow functionality
in previous versions or iterations of the application. So let's show you
just kind of some initial set-up around these business process flows. So
I'm going to go into settings and I'm going to actually just go into
customize the system. Now, normally I would probably go into a solution
and just open up the existing solution based upon the entity that I'm
working with, but for today's purposes, we'll just go ahead and expand
out customizations and kind of go into the default solution. I'm going
to click on the account entity, and when I click on the account entity,
this'll open up the entity definition or the entity properties for this
particular item. And as we talked about in the slide itself, if you're
going to use business process flows, you do have to enable the entity for
business process flows. So you'll see here underneath process it says
business process flows and it says field will be created, you have to
check this box to enable it. Now, once it's been checked and business
process flows have been enabled, now you don't have the ability to turn
business process flows off for this entity. You certainly don't have to
use them, but they are now something that is enabled and that can be used
for this entity moving forward. And so it's real important, if you have
a custom entity or something like that that you've created that you want
to use as part of this, that you go in and you enable it for business
process flows and then save and publish, so that information is
available. Once the business process or the entity that you want to work
with has been enabled, now you can go in and you can actually kind of
start building your business process flow based upon what it is that
you're looking for. So now I can go into settings, I can go into
processes, and then inside processes I could go ahead and define whatever
type of process I want to work with. In this case I'm going to create a
new process. I'm going to call this a demo BPF, I'm going to make this a
business process flow. And in this case, we will associate this with the
lead entity ... or actually we'll just do it with the opportunity. Now,
you'll notice that there's an option in here that says run as a business
process flow classic or run as a task flow, mobile only. There's a
different option around mobile that would allow you to auto-stream common
task creation, based upon the fact that you're working on a mobile
device. So now you want to create some follow-up things, maybe there's
some different items. It's conceptually very similar to a business
process flow, but it's only mobile functionality. We're not going to
focus too much on that for right now, we're going to focus more on just
kind of the business process flow option. So we'll go ahead and choose
run as a business process flow, we'll click on OK, and this is going to
open up kind of that design editor that we can see. So when I come into
my design editor, I can see that I have my item that I'm working with.
So when I click on my opportunity option, I can see that it tells me what
the stage is called. So this is where I can define what I want to call
this. Maybe we'll just call this Qualify. Now, in here I can now
associate this with a specific entity. Now, you'll notice that I can't
change anything here. The reason why I can't change anything here is
because this is the first stage in this business process flow, and when
we created this stage ... or this business process flow, we associated it
with the opportunity entity. So it has to be kind of defined from that
standpoint. The category is really more from just kind of a reporting
perspective. This is where if I wanted to be able to report on specific
areas for these categories, this is where I could select different
category options and then use it from there. Now, the other thing is,
these categories are really just global option sets that you could go in
and you could customize to fit your specific needs based upon the
different labels. So once you've kind of got the information defined in
here for what you want to work with, you can hit apply and it will apply
that information to the item that you're working with. Now, if I go back
into components, in here now I can see the different options that I can
define for how I want to move through this. Now, what you can see in
here is I have kind of my mini designer. This is going to give me just a
flow procedure. So I can see, as I start adding these individual options
into here, what the flow of this business process flow looks like. I
also have zoom-in and zoom-out options. So depending upon how many steps
and stages I would have inside this business process flow, I may run into
situations where it's just hard to see within the element of this
designer. So this allows me to kind of expand and collapse things as
needed. I also can take a snapshot of this. So if I ever want to see
what this looks like in the grand scheme of things and keep this for
historical purposes, I can look through that process as I'm going
through. But now these are those different components that we've talked
about, and so if I look at this individual option here and I click on it,
you'll see that I don't have really anything underneath details. I can
see my specific steps. So these are all the steps that are associated
with this particular stage. And remember that each step constitutes a
field, and we'll talk about that here in a couple of seconds, but this is
where as I wanted to add specific items, I could just drag them over and
place them in the editor in the position that I want to work with. And
we'll talk a little bit more about that as we move through, but this is
kind of the initial scenario that shows you how this editor works, so you
can see exactly what the options are.
Steps, Stages, and Categories
So let's talk a little bit more about stages, steps, and categories. So
you saw kind of in the previous demo that I can add additional stages,
and we'll do a little bit more of that. I can do categories to better
categorize that information when I'm going through, and as I mentioned,
that's really more around reporting. The steps are kind of the biggest
thing that I want to talk a little bit about. So as you're going
through, each stage is going to have different steps that are going to
define what it is that people need to do inside the application. Now,
the steps are really just fields inside your Dynamics 365 implementation.
So if you look at over here on the side, it says step one is existing
contact, step two is existing account, purchase time frame, estimated
budget. These are fields that have been added to the Dynamics 365
implementation. Like the existing contact is just the look-up field on
the opportunity to an existing contact record. The existing account is
just a look-up to the account entity. So you can change the label inside
the business process flow, but the bottom line is, these are still just
fields that are coordinated with the actual application itself. And so
one of the other things that you'll want to sometimes keep in mind is,
you may create a bunch of fields that are just going to be used in a
business process flow and not on the actual form of the item that you're
working with. That is totally acceptable. That's actually in a lot of
cases recommended, because you wouldn't ... otherwise, you'd just kind of
be doubling up on the information as you're working through it. Now, a
couple of things that you do need to remember when you start talking
about these different stages, steps and items is, a business process flow
can have a maximum of 30 stages and each one of those stages can have a
maximum of 30 steps. Now, that seems like a lot, and in a lot of cases,
particularly from a stage perspective, 30 stages is a lot of stages.
However, when you start thinking about the steps and what people might be
doing, it is sometimes easy to get through that process fairly quickly.
So you may want to be looking at, if you have 30 stages or if you have
more than 30 stages, are there areas where you can consolidate this, do
you need to have maybe different business process flows based upon
different situations, can branching play a factor into what you're doing?
So there are some limitations in regards to how much information you can
put into this as you're moving forward.

Working with Multiple Entities

The point behind business process flows is the fact that we've got
multiple items that are going to span multiple entities. And so by a
logical standpoint, most of the business process flows that you're going
to create are going to have multiple entities involved with them. Now,
the only thing to really remember is, you can have a maximum of five
entities per business process flow. Now, within that context, you can
have several different entities ... or several different stages
associated with that entity, but you still can only have five entities
per business process flow and each stage can only be associated with one
entity. Now, I can have multiple stages associated with the same entity,
but each stage can only be associated with one entity. So if you look
down on the bottom here, we've got the qualify stage, which is associated
with the lead entity, we've got the develop stage, which is associated
with the opportunity entity; and same with propose, it's also associated
with the opportunity. That's fine as long as each stage is only attached
to one entity. Now, the other situation is, when you're creating these
business process flows and you're moving from one entity to another, you
don't necessarily have to have a relationship between the entities. It
is nice and there's an argument to be made for having a relationship,
because if you have a relationship between the entities, now you can do
things like auto-closing a previous entity, it gives you a little bit
more flexibility in looping back to entities if you ever want to loop
back to them, but you do have some nice functionality around those
individual situations. Only entities that have business process flows
enabled can actually be associated with a business process flow. And
again, if you are going to leverage relationships from a business process
flow standpoint, you have to be leveraging one to many relationships.
You don't have the capabilities to do many to many relationships as part
of your option. But again, most of what you're going to be doing as
you're building these options are going to be working through and
spanning through multiple entities where you can see kind of the
capabilities built into the properties here. You can see on the propose
stage that we're using the opportunity entity and we don't have a
relationship with a previous entity that we've worked through.

Conditional Branching
So when we start talking about business process flows and working through
some of those individual situations, conditional branching is always
something that happens. And we talked about that in the context of the
auto scenario, where if it's a new car, we're going to do this; if it's a
used car, we're going to do this. So it does give you the capabilities
to associate branching with your option. The thing to remember with
branching is, the branching rules have to be based upon the steps in the
preceding stage. So if I'm in the qualify stage or if I'm in the develop
stage and I want to go ahead and do a conditional branch, the branch has
to be based upon values that were captured in that develop stage and not
the qualify stage. So you have to look at that immediately preceding
step to kind of work through it. When I go through those individual
situations, I can specify how I want that branch to kind of delve off
into that option and I can go up to five levels deep within those
scenarios. And it does support kind of a mixing and matching of and/or
options when I'm working through it. So I can say if this is true or
this is true, do this, or if this is true and this is true, do this. The
only thing I can't necessarily do is I can't have a scenario that says if
the state is New Mexico or Pennsylvania and the estimated revenue is more
than 500,000, then do this. I don't have that option. You would have to
look at looking at your first option that says if it's New Hampshire or
Pennsylvania, do this, and then your next condition says OK, now if it's
more than 50,000, do this; if it's less than 50,000, do this. You can
accomplish it, but you typically need to accomplish that through
different steps as far as the conditions, you can't do them all within
the same condition. And we'll show you that here as an example here in
just a couple of seconds.
Create a Business Process Flows
So let's now look at this with a little bit more detail, now that we've
kind of seen how these processes work. So here's that out-of-the-box
lead to opportunity sales process, and when I expand the lead qualify
stage, I can see here's my individual situation. So I can see step one
is to determine if there's an existing contact or an account. I can look
at the purchase time frame, estimated budgets and processes associated
with those options. Now, if I wanted to, I could go ahead and let's just
delete this option here. Now, when I'm ready, I could now take a stage,
I could drag it right over into my option and say from my opportunity
standpoint, the next stage that we have is my close stage. So I'm going
to specify this as a close stage. I can see what specific entities I
want to work with. Now, you can see here, being that it's an ending
stage, it doesn't necessarily matter what specific opportunity or entity
I associate this with. I could now pick on the opportunity I want to
associate it with and then I could come into here and I could specify if
this had a relationship with a previous entity that I wanted to work
with, what is that relationship that defines how that process works.
Now, being that this is all tied to the same opportunity entity, it
doesn't necessarily have a relationship between those individual options.
Now, this is where I can start kind of building some additional
functionality. So, for example, if I look at the opportunity close ...
or propose option here, I can basically see here that I have to complete
an internal review. So this is where now we could go ahead and we could
define maybe some different conditions around how we want to work through
this. So I could come into here now and I could add a condition to this
process that says what do I want to do within this condition. And so now
I can come into here and when I specify my condition, I could specify
what the rule itself is. So what is the field that I want to evaluate
based upon this different situation? So I want to look at specific
fields on this option. So in this case I want it to basically go through
and identify ... let's look at my step again here real quick ... complete
internal review. So in this case I'm going to look at my field, I'm
going to click on complete internal review, and I'm going to say if it
was marked as complete or if it was not marked as complete, what do I
want to do at this point? If it's been completed, what do I want to do?
So this is where I can define what specific value I want to look at from
that standpoint as I'm going through. Once I've defined what that
process looks like, now I can specify what needs to happen based upon
that specific condition. So now I can hit apply and now I can go back to
components and now I could define a specific stage. And now underneath
this option, I could say OK, if this condition takes place, what am I
going to do? So now I'm going to define what happens within this stage
to go through into the next option. So if it hasn't been marked as
completed or I didn't do something, now I need to go into this particular
option and I need to capture additional info. Then I could specify what
specific entity this is going to be worked with. Then I could also, if I
needed to, specify relationships, but this is coming from the same
sampling. So now I could add individual steps to this option to define
what specifically should take place in here, but you'll notice that as I
veer off, it's ultimately coming back into the same path. So even though
I'm going to capture some additional info, once I've captured that info
and I've marked that info as complete, now I can go ahead and hit next
and move on to the final stage. So this is where if you want to veer off
from kind of a conditional standpoint, you do have the capabilities to do
so as part of the application. Now, the other thing that you can do is,
as you're working through these options, I can delete specific conditions
from this option, I can edit this information however I want. And what's
nice about this is, as I'm entering this or adding or removing this
information, it kind of keeps things in line. So now that I've removed
the condition, it goes right to my capture additional info. I can delete
this stage from my workflow or from my business process flow and bring
information back from here. Now, the other thing that I can do is, as
I'm going through these individual options, I can see on the steps that I
can also define what specific field these steps are. So these are just
fields inside the application that define what it's working with. If I
want to make something required, I can just hit required here and that'll
make it required as part of the business process flow. It will not make
it required as part of the application as a whole. So these are, again,
just ways that depending upon how you want to bring the information in,
people can see specifically how that process works. Again, once you've
got your information in there, you just hit apply and that'll apply the
changes to your option. Now, the other option that you have is your
workflow component. So when you add a workflow component to a specific
option, down here on the workflow I have areas that I can use to trigger
when this workflow is going to function. So maybe I have a workflow that
needs to manipulate some values inside a field, maybe I have a workflow
that needs to check something out as part of the application. This is
where I could work with and define how I want this information to be
created, and I can have it work from a stage standpoint when I enter the
stage or I can have it when I exit the stage. So right before we're
exiting a stage and moving on, do I have a specific workflow that I want
to trigger and function? Or right before I'm coming into a stage, do I
have a specific functionality that I want to trigger or function as part
of that option? So this is where I now have some nice flexibility around
what specific situations we want to work with. Now, the big thing to
remember here is, I can do workflows on kind of two tiers of options. I
can do workflows at a stage-specific level if I want to, but I can also
do workflows on a global level. So if I want to have workflows that
might be available across the context of the entire business process
flow, I can do that. The only thing you have to remember about workflows
that you want to use inside business process flows is those workflows do
have to be on demand workflows. They can't be triggered based upon a
specific event. They would have to be something that would be triggered
on demand, and the on demand functionality would be when somebody is
coming into that stage or when somebody is exiting that stage. But,
again, this is something that we didn't necessarily have in previous
versions of the application. So it does give you some nice ways to
facilitate that as you're moving forward. Now, in this case I'm going to
just delete my workflow. We'll leave my option the way it is. I'll add
a close stage to this. We'll call this close opportunity. We'll add a
step to it, Step 1. Status reason, we'll call this, and then we will
delete Step 2, and now I can go ahead and save and then ultimately
activate this. Now, the other option that you have is the validate
option. This would allow me to basically go ahead and validate this
workflow, if need be, once I start working through all of these
individual options, but in this case we can just go ahead and we don't
need to validate it, because it was validated when it was saved. Now,
the other option that you see here are these what are called security
roles. So again, you might have multiple business processes that get
functioned or executed based upon who individual people are within the
application. And so one of the things that you can do here is you can
set up and you can say that specific business process flows are only
available to specific security roles inside your organization. So now
you might have a situation where you have three business process flows
associated with the opportunity entity. One of those is associated with
a salesperson security role, one of those is maybe associated with a
sales manager security role. Now what it does is, when somebody creates
a new opportunity, it looks at who that user is and it looks at what
their security role is, and based upon that option, it'll go out and
that's the business process flow that it will trigger inside the
application. So it takes kind of a two-tier process. What it actually
does is it looks at what security role is associated with that business
process flow and what security role that specific user has, but then it
also looks at this order of business process flows, and so it looks at
the order that is defined and the first specific business process flow
that your security role has access to is the one that you're going to see
inside the application. If you have more than one business process flow
associated with a specific record, you do have the ability to change
those inside the application as well. But let's just go ahead, let's
activate this business process flow here real quick, and let's just give
this a quick option here. There we go. Re-validate it quick. It looks
good, save it, and activate it. So now once this is activated, if I go
back into the application and I go into sales ... and let's just go into
opportunities and we'll just open up an existing one here. So now if I
open this up, I can see that my business process flow information is in
there, I can see where we're at from the individual option, I can see
what's been completed, what's not been completed, I can click on
individual options to mark this. If I want to, I have an option up here
where I go to processes and this is where, if I want to, I could switch
this business process to a different business process. If I'm somebody
who has the ability to edit this business process, I could edit this
business process, or I could completely just abandon this business
process, depending upon what my specific needs are. So you do have some
flexibility around how this process works. Now, if I switch business
processes, the big thing to remember is, all of the information will
still be there, it'll just kind of start over at the beginning. Not a
big deal. You can advance through the stage as kind of necessary, but it
gives you the capabilities to work through those. So now I can go to my
next stage, hit my next stage, and it will advance to the next scenario.
I can then see how long I was in that specific stage and I can see that
I've been in that stage for X amount of time and then I can work with it
from there, but this gives you kind of a nice scenario to see exactly
what that process looks like as you're moving forward.

Mobile Task Flows

I want to show you one more piece to this. So in the previous example,
we showed you how to create or work with and edit a business process
flow. And remember when we were going through and creating that business
process flow, one of the options that we saw was a mobile task flow or a
task flow, and I want to show you where that plays into the realm of what
you might be working with. So I'm going to go back in, I'm in the
processes. I'm going to go ahead and create a new process and I'm going
to associate this with ... we'll just call this Sample Task Flow, and I'm
going to associate this with the ... we'll just say the opportunity
entity or even just the appointment entity. We can go ahead and do that.
So I have this option as run process as mobile or as task flow. What
this is is ... think about how you might do business from an application
standpoint. So let me go ahead and just associate this with a phone
call, and OK. So think about how you might do business when you're going
through. I'm going to go through, I might create a phone call, I might
call somebody specifically from a customer perspective, and once I'm done
with that customer, there might be specific tasks or items that I need to
facilitate as part of that. Maybe I need to go into the contact that's
associated with that phone call and I need to make some updates on
information, or maybe I need to go into a related record and be able to
facilitate some type of functionality. This is where mobile task flows
come into play. So if your policy as an organization is, once you've had
an appointment or once you've had some type of procedural item that
you're working through, when you're done, you now need to go in and
update multiple entities inside the application. You can create a task
flow that can be triggered on a mobile device, that once you trigger that
task flow, it gives you a step-by-step procedural ... almost like a
little mini wizard that says OK, here's the information that you need to
feed in. So on the phone call you need to update this information, and
then on the primary contact or the contact associated with that item, you
need to update this information and individualized items as you're moving
forward. So let's say for example I want to construct this from a phone
call standpoint. So I'm going to go ahead and I can see in my details
that I have different elements or different fields that can be associated
with this. So I'm done with my phone call. What do I need to do? So I
can click on these individual fields and I can define what needs to be
updated in regards to the item that I'm going through. So, for example,
maybe I want to go ahead and let's call this Update Description. I can
see that this is associated with the phone call entity. I can now go
ahead and pick what field I want to work with. So in this case I'll hit
description. And then I can go ahead and define do I need to ... am I
requiring somebody to update that description field? If so, I can make
it required. Then I can go ahead and hit apply. Now I can go ahead and
define what do I want to do next. So in this case I'm just basically
updating the phone call information. So we'll just call this Update
Phone Call. But now I could go ahead and I could add maybe a new page,
so kind of the next page in the wizard. So I'm going to go from updating
that phone call to now updating another specific item that I'm working
with. So maybe let's call this Contact Info. So now when I go into my
details and I look on my components, now I could come into here and I
could look at my field and I can see that I can pull this from a bunch of
different situations. So if this phone call was related to a specific
contact, I could actually pull this in from the regarding contact and now
I could make sure that I have updated fields from that contact. So maybe
I want to verify that the phone number's correct, maybe I want to verify
that the address is correct. This is where now you kind of create this
mobile task flow that guides you through the process of making sure that
any entities related to whatever it is that you're trying to do at that
point have been subsequently updated. Now, the nice thing about this is,
being that this is feeding directly into the related records contact
record, the phone number's already going to be there, the address is
already going to be there. If all you're trying to do is just verify
that the information is still correct or maybe create a new task or item
to associate with it, that's what this is going to be able to allow you
to facilitate. So if you think about follow-up tasks that would need to
happen from the concept of a meeting or an event that you would want to
be able to quickly make sure people can do within the context of a mobile
device, this is where mobile task flows come into play. You can
associate this with one screen, but that one screen can be associated
with multiple entities. So I could have information from the record
itself and then I could have information from the related records
associated with that or the parental record associated with that to be
able to facilitate that. I also could even bring in conditions. So I
could say if this takes place, if this phone call was an outgoing phone
call or if this particular situation happened on this opportunity or this
field is set to this, now fire off this page and here's the data that I
need to capture; if this is bringed in, now I need to fire and capture
this information. So if you're trying to create supporting activities or
supporting entity-based information, it gives you kind of a nice way to
facilitate that. Let me show you another kind of pre-created example
here. So I'm going to just go ahead and leave this option and I'm going
to actually go into this business process flow and I'm going to associate
with the ... in this after-meeting option. So I'm going to open this one
up, so you can see an example to this. So here I have kind of my
appointment. So the first thing that it's doing is it's verifying the
appointment details from this option. So it's showing me what specific
fields that we went in. I'm looking at the notes labels, I'm looking at
fields from the description value, different items, then I have a
condition that basically evaluates that if this is regarding a case and
the case contains data, then I'm going to go ahead and create an
appointment or update the case based upon that situation. So I'm going
to update the regarding case field on the appointment. Otherwise, I'll
have a condition that looks to see if it's in regards to a contact or to
an account, and then I would update that appointment regarding that
specific account. So this is where you can look at where did this
appointment take place, what were the situations that took place around
this appointment, what was this appointment regarding, was it regarding a
specific case, was it regarding a specific contact? If so, based upon
those items, now I need you to guide users through this particular
methodology. So it's a great way to streamline what people might be
doing within the context of the application. But again, this is
something that you can create specifically targeted at mobile
applications. It's a very similar process to your business process flow
designer, but, again, it's specifically targeted at mobile-based
applications.

Module Review
So as you can see, business process flows really do provide kind of a
great way to guide your users through any type of process that you might
have that involves one or multiple CRM records. By going through and
defining different stages and processes, you now have the ability to
insure that every single user of the application is following the exact
same procedures and kind of maximize what it is that you're working with.
What's nice about the business process flows is there's just the
flexibility. So from a conditional branching standpoint, if you're
looking at I want to go this direction based upon this option, you now
have that flexibility to really drive people off, as opposed to in the
past where sometimes we just had to have multiple business process flows
to be able to facilitate those different business processes or procedures
inside the application. Now, the other thing that's nice is, within the
context of these business process flows, workflows can also be added to
now go in and start manipulating some of the data a little bit, based
upon how you're entering and exiting those individual stages. What's
nice about that is, now you have a little bit more flexibility to
interact with other portions of the record itself and maybe fill in
additional fields based upon values that have been plugged in as part of
that business process flow when people are checking off and interacting
those phases, which in the past we didn't necessarily always have the
capabilities to do. And if you're looking for kind of a way to have
flexibility around these options, security roles can be used to really
process and show those business process flows for different entities
based upon who that user is. So it looks at who you are and says OK,
this is the business process flow that really should be available to you
and it triggers that functionality individually and kind of lets you
start working the information from there. So business process flows ...
particularly if you're trying to guide people through kind of a starting
and ending procedure, business process flows are a great way to
facilitate that as you're moving forward.

Test Your Knowledge Questions

1. Which of the following statements is true about Business Process Flows?

 A business process flow can only be enabled for out-of-the box entities.
 A business process flow can span multiple entities. *
 A business process flow can only be enabled for custom entities.
 A user can switch to another Business Process Flow at any time, and the new process
will continue from the same stage that the earlier process stopped.

Explanation: Business Process Flows can be enabled for any entity in Dynamics 365 system or
custom. Business Processes have the ability to span multiple entities,
Reference: What are Business Process Flows?

2. You are creating a Business Process Flow, and have determined that it would be best to use a
conditional branching. Which of the Statements below about Conditional Branching are true?
(Check all that apply)

 Branching rules must be based on steps in the preceding stage. *

  A branch can go up to 10 levels deep.
 A branch can change to the next or a future stage. *
 You cannot mix AND/OR operators in a single condition.

Explanation: When specifying conditions for a branch, your condition can be either an AND or
an OR condition, but you cannot use AND/OR operators in a single condition. If you select the
opposite operator, all operators will change to the last operator defined. Branches can only go
up to 5 levels deep.
Reference: Conditional Branching

3. You have 4 Business Process Flows that have been created for a custom entity. Each one has
different security roles defined for it. Which of the following statements are true when you
create multiple BPF’s for a single entity? (Check all that Apply)

 The order number of a Business Process Flow is considered to help determine which
Process Flow is default for a specific user. *
 If a user does not have access to the current process being used on a record, the
Process bar is not shown in the application.
 The users Security Roles are considered to help determine which Process Flow is
default for a specific user. *
 User can switch to any Business Process Flow assigned to that entity that their
Security Role provides them access to at any time when working with a record. *

Explanation: When someone’s Security role does not allow them access to a Business Process
Flow that is being used in a record they are viewing. The Current Process will show in the
record, but all of the options will be disabled.
Reference: Role Dirven Business Process Flows
Module 07: Dynamics 365 and Office 365
Module Overview
So up until this point, we've really been talking about how do you
configure a Dynamics 365 implementation for functionality that's really
going to be consumed by people who are inside the application. So when
you think about things like business process flows or things when we
start talking about knowledge management and some of those types of
things, those are typically things that internal Dynamics 365 users are
going to be consuming and working with throughout the context of the
application, but more and more we start getting into scenarios where you
want to work with people who aren't necessarily Dynamics 365 users.
Maybe you have a proposal that you're sending out to a customer and you
want to be able to go through and work with a specialist from a specific
area of your organization, who might be able to provide insights on how
to work with that. So from a Dynamics 365 standpoint, there's a lot of
integration options, particularly with Office 365, and more and more
we're starting to see that integration line between the two applications
is really starting to become kind of blurred. So what we want to talk
about in this module is, what are some of the options that you have when
starting to connect a Dynamics 365 organization to an existing Office 365
subscription, so you can really take advantage of some of the different
features out there that will provide some of those collaboration
capabilities and also better email tracking capabilities versus just some
of the out-of-the-box functionality. So in this module we want to look
at what are some of the different options that you have in regards to
connecting to a Office 365 subscription, what are some of the
capabilities you have around email, what are some of the capabilities you
have around just user collaboration as a whole. So we'll talk a little
bit about using tracking folders to be able to track e-mails and
automatically associate e-mails with Dynamics 365 records. We'll talk a
little bit about how you set up and configure office groups for
collaboration. So if you want to create a specific group for an
opportunity that allows you to define who those people are, interact with
different people inside your organization who may not be Dynamics 365
users, what are some of the options that you have in regards to that?
We'll talk a little bit about how you set up and configure server-side
SharePoint integration, because server-side SharePoint integration not
only is really going to give you some of your document collaboration
capabilities, but it's also going to give you the functionality that you
might use for OneDrive integration and OneNote integration, if you want
to have enhanced note-taking functionality throughout the application.
So we really want to go through and just explore what are some of the
different ways that you can extend this functionality out a little bit by
bridging that gap between Dynamics 365 and Office 365.

Integration Options
So why is there a need to integrate with Office 365? Well, you think
about realistically how people work today. Most of us have a tablet
device or a phone device that we're using to check our e-mails, and
oftentimes we're not necessarily using a specific email client.
Depending upon the type of device, whether it's an iPhone or whether it's
an Android type of device, there's usually a specific email client built
into that operating system that you're using to track your email. Now,
the nice thing is you can connect that subscription or you can connect
that device to your Office 365 email account, so you're still going to
have like all of the folders and items that you would use for storing
information together. So the nice thing about that is, I want to be able
to go ahead and create Dynamics 365 email activities on the fly just
simply by moving something from one folder to another folder, now I want
to have an email activity be automatically created. So I don't
necessarily have to worry about having a specific client installed on any
specific device that I might be working with. So it just provides kind
of that level of flexibility. The other reason why you might be looking
at connecting with a Office 365 subscription is just from a collaboration
standpoint. Realistically, you're not always going to have Dynamics 365
users that you need to work with. Sometimes you might have a specialist
in a specific department who understands zoning, and so now you have a
document that you want to associate with an opportunity inside Dynamics
365, but you want to be able to get feedback from people who may not have
a Dynamics 365 license. By using different situations like OneDrive For
Business or even just SharePoint document integration, now I have an area
where I can put stuff from inside the user interface of Dynamics 365, but
I can now expose that and make that accessible to people outside of my
traditional Dynamics 365 subscription. I also maybe want to be looking
at note-taking functionality. Yes, we can do notes and we can add notes
to records inside the application, but, again, now you're running into a
situation where the notes that you're taking are stored inside Dynamics
365. We don't necessarily have all of the necessary capabilities to be
able to do checklists or handwrite those notes or even put in images or
items that might support some of the different functionality or use cases
that we're working with. So by replacing some of the note functionality
with OneNote, now we have that dynamic capability that OneNote provides
us. Now, the additional capabilities around that are the fact that a
OneNote workbook can actually be shared out with, again, non-Dynamics 365
users. So it's all about forcing collaboration and allowing
collaboration with people that are not going to be consuming the data in
your traditional Dynamics 365 way. They're coming in as kind of a
support mechanism and allowing you to work through that. So there's a
lot of different scenarios that are conducive to that, and then
fortunately, out of the box there's a lot of configuration options that
you can do from a Dynamics 365 perspective that are going to allow us to
set up and configure those individual items.

Folder Tracking
So if you think back all the way to Module 1, one of the things that we
talked about was email management and we walked through the concept of
setting up email server profile, so you could take advantage of Dynamics
365 server-side synchronization process. And the advantage to using
server-side synching is, when an email is present or when something
happens at a server level from an exchange standpoint, that can
automatically translate over into Dynamics 365 and create the relevant
activity inside the application. Same thing if you're going the other
way. If you're starting from a Dynamics 365 standpoint and you create
something, that can now come in and send on behalf of somebody else and
now appear as a sent item inside their exchange. What's nice about that
is that eliminates the need to always have to have the Outlook client
installed for individual users that are working with it. There's still
obviously advantages to using the Outlook client, but by using server-
side synchronization, now we have the capabilities to really take that to
the next level. And so one of the things that actually gets enabled or
has the ability to be enabled through that process is a concept called
folder tracking. And we talked a little bit about this at the top of the
module, but if you think about it from an email perspective, one of the
things that comes in is we're going to get an email and I want that email
to be a Dynamics 365 activity. So now I'm going to decide that I want to
track that inside the application. There really was no mechanism outside
of folder tracking to be able to do that if you weren't using a
traditional supported email client. Now, with this concept of exchange
folder tracking, I can just simply move that email to a specific folder
that I've determined or created inside my profile, and once I do that,
the server-side synchronization process is actually going to go through
and promote that to an email activity inside Dynamics 365, so I can use
that moving forward. Now, one of the things that we want to show you is,
what does that concept look like? So there's a few different tiers that
actually have to take place. The first thing is you have to have, as I
mentioned, server-side synchronization enabled for your organization. So
that's something that has to be done and set up for the individual users
who will be working through it. So on their mailbox profile, you'll want
to be using server-side synchronization for incoming e-mails as they're
coming through. The other thing that you have to do is you have to
enable folder tracking for your organization. So it's kind of a two-tier
process. It's enable server-side synchronization first, then go in and
at an organization level enable folder tracking, and that's actually done
through system setting. So if we go into administration and system
settings, we will see an option there for using folder-level tracking, so
we can enable that. Now, if we don't have server-side synchronization
enabled, it won't let us basically move through the process in regards to
what we want to do from there. Now, that's done from an organizational
standpoint. From a user perspective, each user is going to be handling
kind of these folder mapping or folder tracking rules independently. So
the first thing that has to be done then is, from a user perspective,
anybody who wants to have e-mails to move into those folders, they have
to create those folders just like they normally would inside the
application itself. Once they've created those folders, then they can
map those folders for tracking. So what they would then do is ... from a
personal perspective, I would go in and I would click on the configure
tracking rules, and then it will list to me all of the individual folders
that I have available and I specifically just pick the folder in exchange
and then I map that to a specific record inside CRM. Now, what's kind of
nice about that is, as I'm going through and kind of mapping that
individual functionality, it'll go through and create that for me and
automatically set that situation up. Now, I don't necessarily have to
map it to a specific record, I could just go ahead and have it be tracked
in the application. The thing to remember, if it's tracked inside the
application but not mapped to a folder, it'll create the email activity
but it won't associate it with a specific record. So, in essence, the
record might be orphaned from that standpoint. So what they kind of
recommend from that standpoint is, if you're going to do that, go ahead
and map it to a nonspecific record but make sure that you come in later
and then assign that to another record if you need to. So it does at
least give you the tracking functionality, but you would be able to come
in and work through it from there. Now, there are a couple of things
that you have to remember. When something has sub-folders, those sub-
folders are not specifically mapped. Each folder is considered an
independent option. So when you're setting up and tracking this
functionality, for each folder that you want to map to a specific
Dynamics 365 record, you do have to specify what that record is that you
want to work with. The other thing is, there is a limitation in regards
to the number of tracking rules that can be active for a specific user.
So each user can have up to 25 tracking rules that they can set up and
enable. So during the course of the next scenario, what I want to do is
show you what that looks like as we're moving forward.

Exchange Folder Mapping

So let's take a look at what this looks like inside the application
itself. So as I mentioned, this is a server-side synchronization
scenario. So you do have to have server-side synching enabled. So you
would have to go into email configurations and make sure that you do have
a server profile created for the environment that you want to work with.
The next step to that is then you're going to go ahead and go into
settings and administration. And if you remember, under administration
there's a system settings option. So when we go into system settings,
this is going to give us the capabilities to turn on some of these
different functionalities. And one of the options that we'll see here
underneath email is the ability to configure whether or not I want to use
server-side synchronization for the organization. So that has to be set
up and enabled and controlled here, but then if I scroll down there's an
option here that says use folder level tracking for exchange folders. So
this is where I would enable this functionality at an organization level.
Then I can go ahead and click on OK. Now, that's kind of the end of it
from an administrative perspective. The remainder part of this really
does take place inside the individual application profile for each user,
because each user's going to have separate folders that they would set up
inside their exchange. Now, typically you can do that just through
Outlook. You could go into Outlook just like you normally would, right-
click Create Your Folders underneath your inbox to define what specific
folders you want to be able to track. So that's just standard Outlook
functionality. Now, if I'm inside Dynamics 365, if I come up here into
my administrative settings and I click on settings, one of the options
I'll see here is just options, and when I click on options, this is now
opening up my personal options. So this is my individualized profile
that I'm working with for me as a specific user. One of the options that
I have in here is email. And so when I come in here to email, there'll
be an option here underneath select the email message to track in
Dynamics 365. There's a configure folder tracking rules, and so if I
click on configure folder tracking rules, this is where I can set up and
define my individualized mappings that I want to work with. So, for
example, I will go ahead and click on new folder mapping and this will
list all of the exchange folders that I have. So these are all the items
that are kind of set up underneath my box that I'm working with. So I
have a folder here for Adv. Works, or for Adventure Works, and ultimately
what would make sense from this standpoint is I would want to ... any
email that I move into this folder, I probably want to have associated
with the Adventure Works account inside Dynamics 365. So if I come over
into my look-up icon, now I can select multiple records. And you'll
notice in this case it defaults to accounts, but if I go into look up
more records, I could really associate this with any entity type inside
the application. So I've got my contacts, I've got leads, opportunities,
cases, any of the standardized options that you might be working with.
In this case I want to work with Adventure Works. So I would go ahead
and click on add and now this folder is mapped from an Adventure Works
perspective; then I could just continue this process through. So I
create another new mapping. In this case I'm going to go ahead and say
Jane. I'm going to map Jane to a specific contact. So I'll go to look
up more records, switch this to contacts. In here, find the specific
person I want to work with. I don't have a Jane, but in this case we'll
just go ahead and map it to Maria, and then I'll go ahead and hit add.
Now, the big thing that you have to remember here is, once you're done
with this or once you've had this information set up, then you're going
to go ahead and hit save, and this will then map those options
automatically for you. If you forget to do the save, it's not
necessarily going to save the information and you won't see the added
functionality inside the application. Now, this is just a
synchronization scenario. So exchange in Dynamics 365 just goes through
a situation where periodically they synchronize. So it's not necessarily
something that is going to be real time from creating the activity
scenario. You can see here that the last one took place about four or
five minutes ago, but it does happen with relative frequency. So you
will see this on a fairly regular basis. So they will appear fairly
instantaneous, even though they're not necessarily going to be realtime
situations when you're working through it.

Types of Office Group 365 Groups Integrations

Another thing that oftentimes happens is this need for collaboration, and
there's a variety of different mechanisms that you can use inside a
Dynamics 365 implementation to be able to connect and work with items.
One of the options that you would see would be what are called office
groups. So think of office groups as kind of a repository or almost like
a document workspace, where you're going to assign specific people that
you want to collaborate with on a specific mechanism. Now, there's a
couple of different ways you can do this. There's the Office 365 groups
from a Dynamics 365 perspective and then there's the Office 365 groups
connector. We're going to really focus more on the group solution
itself. So what this is, this allows you to actually surface group
information from Office 365 inside Dynamics 365 in the context of that
record that you're currently working with. Now, this is a separate add-
on solution that you have to add to your organization. So basically what
happens is you go out and you install the solution into your
organization, and once that solution is installed, then it basically
allows you to configure that functionality inside the application for
collaboration perspective. Now, the nice thing about that is, the groups
can be auto-created once you're working with it in the context of the
record that you're working through. So the process to actually go
through that is, you have to go into your Dynamics 365 online
administration area instances and surface the solution. So you'll find
an Office 365 group solution, you'll go ahead and click on install, and
that'll install the solution into your environment. Now, that will take
anywhere between five to ten minutes, depending upon the situation, but
once it's installed, then you have the capabilities to go out and
actually configure that functionality for your organization. So you'll
have now ... inside your navigation area, you'll have an Office 365
groups that you can go in and administrate. Now, the big thing here ...
and we'll show you this inside the demonstration as well ... is you have
to define what the entity is that you want to work with and then you have
to specify whether or not you want these groups to be auto-created for
you, which it will do inside the Office 365 subscription. The thing to
remember is, this is really kind of a customization that you would be
making inside the application, because you're enabling kind of related
items from an application standpoint. So you also need to make sure that
you're publishing these customizations when you're done. So you'll see
an option here to publish all. If you forget to do the publish all, that
doesn't... then that functionality will not technically be enabled for
that entity. And that's one of the biggest areas that I see people
sometimes forget, is to do that publish all scenario. Once it's
published and you've configured it, now when you go into a specific group
the first time that you access the Office Group situation, it's going to
ask you if you want to create the group, it'll create the office group,
and then you can provide that collaboration. So let's go ahead and take
a look at how that process works inside the application. So I'm back in
my Office 365 admin center and I've basically navigated to my Dynamics
365 instances through the admin perspective, and so this is my instance
that I want to work with. So when I select the instance, I can see that
there's no solutions currently installed into this instance. When I
click on solutions, one of the options that I'll see from a solution
standpoint is the Office 365 group solution. So what I would do at this
point is now select that solution to install it into my organization. So
we'll give this just a second to kind of catch up. And then once I pick
the group solution that I want to work with, this process, like I said,
can take a few minutes to install. So you may need to refresh
periodically, but I'll accept the terms of the license agreement and I'll
let it run through the install. And again, we'll give this a few minutes
to kind of process through and complete the install procedure. So the
solution's now successfully installed, so now I can navigate back into my
Dynamics 365 instance. So if I come back into my Dynamics 365 instance,
one of the areas that I'll see in the navigation now is my Office 365
groups. So if I look underneath system, underneath my activity feeds
rules, I'll see an Office 365 groups. I go ahead and I click on that,
and this is where I'll basically enable the functionality. So right now
I can see that I don't necessarily have any options associated with this.
Now, one of the things to keep in mind is, this does tell us that we do
need to have SharePoint configured and SharePoint integration to be able
to facilitate that. And that's actually the next option that we'll show
you, is how SharePoint integration works. So first and foremost, we'll
just kind of take you in here and we'll let you see what this process
looks like from a configuration standpoint, but normally we would've gone
through and done some of the SharePoint integration setup first, but
we'll at least set this option up. So I'm going to go ahead and add my
entity, specify what entity I want to work with. So I'll see my
different entities kind of listed within the application itself. I'll go
ahead and pick my specific entity I want to work with and then I will
choose to auto-create. And what that'll do is, whenever I create that
option from that standpoint, it'll then go ahead and auto-create the
records for me. Now we'll go ahead and add just a couple of these for
account, we'll do for opportunity, and then we'll also add one for
contact. Then I can publish all, and then once I've published all, now I
could go ahead and I could consume this feature inside the application.

SharePoint Integration Overview

SharePoint integration is a huge aspect of what you're going to be doing
from a collaboration standpoint in respect to Dynamics 365. Now,
obviously Dynamics 365 has the capabilities to attach documents to
records using some of the note functionality. Historically, the issue
that you'll run into with that is, they're almost like an email
attachment. When you attach a record to a... or a document to a Dynamics
365 record, you're really getting more of a static copy of that record.
So if that document were to ever change in kind of its source area, it
would have to be re-added into the Dynamics 365 application in order to
facilitate that update. If we go in and we enable things like SharePoint
integration, now we have this entire concept of collaborative
capabilities, where I have the ability to take a document and as that
document is being changed and as that document matures, now I can see
those changes reflected inside the application. The other nice thing
about this is, this is where now I have the ability to really collaborate
with non-Dynamics 365 users on these documents, because realistically I
wouldn't necessarily have to have a Dynamics 365 license to be able to
open that record up through the context of SharePoint. As long as I have
access to SharePoint through my user account, I can collaborate and work
with that document together. The other thing that's nice is, now by
using some of this functionality, I can take advantage of the versioning
capabilities of SharePoint, I can use some of the check-in, check-out
functionality, and this is also really the baseline infrastructure to
support many of the other features that we would see from a Dynamics 365
standpoint. Office Groups is one of them. In order to be able to use
document repositories for office group collaboration, you have to have
SharePoint integration enabled. In order to use OneNote integration, you
have to have SharePoint integration enabled, and in order to use things
like OneDrive For Business, that's all based on a structure built off of
this functionality. So this is kind of a critical element moving forward
if you want to enable any of the other collaboration capabilities that
Office 365 provides you. Now, when we start talking about what are some
of the baseline functionalities that we want to work with, you have to
enable either server-side integration or client-side integration. So
there's really two options available. We're going to focus from a today
perspective on server-side integration, and the reason why we want to
focus on server-side integration is because that's what's going to give
you, A, the most flexibility from a deployment perspective because you're
going server to server. It does support hybrid scenarios, whether you're
working with Dynamics 365 Online and a SharePoint on-prem or any other
combination really of the two. The client-side integration, which is
typically provided through the list component, does give you SharePoint
capabilities, but it really just kind of surfaces that information
through an I-frame that's formatted in the context of CRM. So it's not a
true server-to-server back end, which doesn't always give you the same
OneNote functionality and some of the other items that you would be
looking at. So typically speaking, you're going to enable server-side
integration, and it's really kind of a one-time setup situation. You
first will go in, define what it is that you want to work with, you'll
define the type of deployment. So, again, it does support different
hybrid scenarios if you're using SharePoint Online or SharePoint On-
Premise. Once you enable it, though, and once you've configured server-
side integration, there isn't a mechanism to switch to client-side
integration. Which is fine, because moving forward some of the client-
side integration stuff is kind of on the road map to be deprecated moving
forward, and server-side synchronization is really the option that they
are encouraging people to be using more often than not. So this is kind
of what you would see from a structural standpoint inside the document
storage standpoint. You have your Dynamics 365 capabilities and then you
have your SharePoint situation. So within the SharePoint side or within
the collection, you will see records that will be associated with
different document libraries inside SharePoint. Now, those document
libraries might have some folders that are associated with them for
better storage, but realistically inside the Dynamics 365 interface, what
you're going to see is kind of a hybrid model of all the documents that
are associated with that. Now, you can have a singular Dynamics 365
record that is linked to just one specific document location inside
SharePoint or you could have a record that might have multiple document
locations. The nice thing about the integration scenario is that's
configurable. You can set that up and decide how you want that process
to look like in regards to do you want the folders to be created
automatically. And even if they're created automatically, you still have
the ability to manually map to a different document location, if need be,
based upon the needs of the record. So let's go ahead and see what this
process looks like inside SharePoint or inside Dynamics 365 to set up and
enable that integration. So inside Dynamics 365, I'm going to go into
document management, and so I'll see that because I haven't configured
all of this functionality yet, I still have two options available. I can
install the list component or I can enable server-based SharePoint
integration. And again, more often than not, based upon what you're
going to be working with, server-side integration is really what is
recommended from an application standpoint, and at some point in time,
it's not necessarily going to be supported from a list component
standpoint. There are plans to deprecate the list component
functionality. There's just more administration around that and kind of
less flexibility moving forward with some of the enabled functionality
features. So in this case I'm just going to go ahead and enable server-
based SharePoint integration, tell me what I can do within the context of
this situation. So I'll go ahead and hit next. Then it's going to ask
me what type of deployment do I want to connect to. Do I want to connect
to an online instance or do I want to connect to an on-prem instance? In
this case I'll just go ahead and connect to an online instance. I'll
specify the URL for the SharePoint integration type that I want to work
with. I'll go ahead and hit next. It'll then handle the authentication,
and obviously because we're working with Dynamics 365 and we're working
with Office 365, it'll prompt me if need be to log in, but we're using
the same log-in. So we do have single sign-in capabilities. It's gone
out, it's tested the URL to make sure that everything looks OK, it's a
valid URL. So now I can go ahead and I can enable this functionality
when I'm going through. So it's now basically telling me at this point
that once I enable this functionality, I do not have the capabilities to
use client-side integration anymore, and that's fine. We'll go ahead and
enable it. It tells me that everything is basically ready to go. So now
the next step to this is I would have to go in and set up the actual
document management capabilities inside the application, and you'll see
in here that there's an option to go ahead and facilitate that. So I'll
go ahead and open my document management capabilities and I'll hit
finish. So in here, I can see what specific items I want to work with.
So I've got the capabilities to see that I want to work with the account
entity, the articles, categories, opportunities. I can specify which
ones I want to work with. These are the ones that typically kind of get
enabled from a document management perspective out of the box. So we'll
just go ahead and leave the ones that we have. I'll specify my
SharePoint URL and I'll hit next. Then it's going to go through and ask
me how I want to work through this. So it's going to tell me that the
SharePoint item itself is a valid structure. What particular folder
structure do I want to use? So I can base this off of an entity if I
want. So if I typically would want to organize documents based upon the
account or the contact, I could either have it just kind of create these
individual document libraries independent or I could actually go in and
base it off of a specific entity, which in this case makes a lot of sense
to do it off the account entity, because a lot of the opportunities and
the contacts and the supporting documents that would be attached to that
will generally be based off of that functionality. So in this case we'll
just go ahead and hit next. It tells me that they're being created at
this particular path and that it might take a few minutes to go ahead and
do that, but that's OK, we'll go ahead and click on OK. It'll run
through kind of a status validation. So it'll go through and it'll tell
me whether or not those items are there. In this case we've already kind
of had this set up in the past with other integrations to other sites.
So it tells us that it already exists, which is totally fine. We can go
ahead and hit finish, and now that functionality has been enabled for our
organization. So now I can see that I have different options here. I
can see that I have OneNote integration, I have manage Office Graph
integration, which is basically my Delve integration, and then I also
have the capabilities to enable my OneDrive For Business functionality,
if need be, inside the application. So now I will have for each
individual entity the ability to go in and start working with document
management library capabilities. Now, there's a couple of other just
little things I want to mention while we're in here. I'm going to
actually go up into settings and I'm just going to go into customizations
real quick and I'm just going to customize the system. And I want to
draw your attention to a couple of different things on the entities
themselves. So I'm just going to expand this out and click on the
account entity. One of the options that you'll see in here is the
ability to handle some of the different collaboration options. So you'll
see in here that there's a document management and a OneNote integration
capabilities. If you have an entity, whether it's a custom entity or
even an out-of-the-box entity that hasn't been enabled for functionality,
if you want to be able to facilitate and use that for any functionality,
you would have to enable it. So you would have to come into document
management, check document management. Same thing with OneNote
integration. Check OneNote integration if you want to be able to
facilitate that. Once you've turned that functionality on, save and
publish, then you will be able to take advantage of some of the other use
case functionalities like Office Group integration, if you wanted to
utilize that, or OneNote integration or some of the other capabilities,
but it does have to be enabled on an entity by entity basis. The nice
thing is, you do have some of those options when you initially configure
it, but moving forward there may be some options that you have to look at
to enable. What's important to remember is that when you're working with
SharePoint integration in the context of being displayed inside a
Dynamics 365 implementation, you are still working with SharePoint. So
what you're seeing inside the application is a link to the SharePoint
document library. So if you have a document that you place in there
through Dynamics 365 or through SharePoint, it still exists in
SharePoint. So if I delete that document from inside the Dynamics 365
interface, it does delete that document inside SharePoint because that's
where it's residing. However, if I delete a Dynamics 365 record, I'm not
removing those SharePoint documents. All I'm doing is basically removing
the link between that Dynamics 365 record and the SharePoint document
library. So it's important to note that they still are individual
management capabilities and security is even maintained a little bit
individually between the two. So the thing to remember is, when you
start working through these, they aren't a realtime synchronization
scenario. You might have a situation where if you're working through it
and you delete a record inside the application, it's still available in
SharePoint and you may have to do some administration. Same thing with
merging. If you merge records together or Dynamics records together,
that merged record will actually have both document locations associated
with it, because it would have multiple options. So when you start
talking about how this process looks from a security perspective, if you
want to configure any of the SharePoint integration, you do have to have
a system admin role or something equivalent to that situation as you're
moving forward. A lot of the options as far as document libraries and
permissions, you would have to have access to them in regards to be able
to facilitate that. So for document locations, you have to have the
appropriate permissions to be able to enable and work with the document
location inside the application. However, once you're in that document
library, the permissions are independent and they're actually maintained
through SharePoint. So I think that's probably the biggest thing to
remember, is the Dynamics 365 security model is very different than the
SharePoint security model. So you have to make sure that the integration
between the two, it assumes that both users have permission on both
sides. So not only do you have the ability to access that document
location inside Dynamics 365, but I do have the appropriate permission
inside SharePoint to be able to work with things from that standpoint.
So they are independent interfaces. So I can use like an access team in
Dynamics 365 to grant or restrict access to SharePoint. I could only do
that through the context of the record that I'm trying to work with in
the application.

OneNote in Dynamics 365

Another element to consider when you start talking about integration
capabilities is, do you want to use the standard Dynamics 365 note
functionality or would you like to replace that functionality with like
OneNote integration? And because you've enabled SharePoint, you now have
the capabilities to be able to do that within the context of the
application using shared OneNote files. So the nice thing about OneNote
integration is also the standpoint of the fact that I now have the
capabilities when I'm working through this to access this OneNote
information on any device where I might have access to OneNote. And so
there's a OneNote app for mobile, there's a OneNote app for tablets. All
of those items now allow me to collaborate and work with these notes
inside different versions of the application, even though they may have
initially been created inside Dynamics 365. Now, as I mentioned, it's
based off of SharePoint integration. So what you'll actually see is,
when you enable linking to OneNote files, you will actually have each
section of a OneNote workbook that'll be displayed as a section option
inside the Dynamics 365 application. So you will see individual sections
in the notebook that'll link back to items that are displayed inside the
application. Those will constitute the individual sections, but once
you're in those sections, you have all the same flexibility and options
that you would normally have if you were working with kind of standard
OneNote files inside the option. So what you have to basically do in
there is you have to go in and configure the OneNote functionality. And
we talked a little bit about this with the SharePoint functionality, but
first you have to enable SharePoint integration, you then have to go in
and modify kind of the entity settings to allow it to use OneNote
integration, and then you have to modify the OneNote integration settings
to basically turn on what functionality you want to use inside the app.
So it's kind of a two-tier process, but let's look at what that looks
like inside the app. So let's go ahead and hop in and do that. So as
you can see, we're on the account entity, and the account entity does
have OneNote integration enabled. So we're good to go there. So I'm
going to go ahead and close out of the customization or entity definition
window and now I'm going to go back into settings and document
management. And now within this document management, I'm going to click
on OneNote integration, and this is going to open up my OneNote
integration and it's going to look at all the entities that have been
enabled for OneNote integration inside the application and it's going to
tell me here's the options that have been enabled. If this was a new one
that I wanted, I could just check the box for the option that I wanted to
work with, but now I can go ahead and hit finish and I'll see that the
OneNote integration is set up and configured. So let's go back, now that
we've got all of this individual stuff set up, and let's look at this
within the context of the app itself. So I'm going to go back into sales
and accounts and I'm going to open up an account, and so now I'll see
inside the account here is my OneNote integration. So when I click on
this OneNote, this will load up a OneNote notebook that I can use that I
basically can now access, share and edit information directly from within
this application. So I can click on this untitled option, I can come
into here and I can start making changes and working directly with this
OneNote file from within the context of the application. So this now
gives me access to that shared OneNote file that's been created. Now,
I'm not necessarily going to spend a ton of time in here, but you can see
that I have all of the baseline capabilities that I would want to work
with, including sharing this notebook with non-Dynamics 365 users. Now,
let's also look at some of the other items that have come into this as
well. So now if I go into my A. Datum Corporation, I can look at some of
the other options as far as the A. Datum Corporation. Here's that Office
365 groups. So remember we configured that a little bit earlier. Now
when I come into my Office 365 groups, this is what will allow me to
authenticate to a Office 365 subscription and now load in that
collaboration functionality. So this is where I can see that I want to
create this information, I'm going to create the new group inside the
app. Once the group has been created and we're working with it, now
it'll replace this once it takes a couple of seconds to replace this, and
now I will actually see the Office 365 integration piece inside here that
I can work with. So this gives me the capabilities, now that I have the
group created, to actually provide that collaboration. Now, from a
document perspective, once we enable SharePoint document integration, now
when I click on documents, here's those individual documents that I can
see. And I can already see that the SharePoint functionality or the
OneNote functionality has already been brought into here, because this is
that one file or that item that I had created earlier. So this is how
now we have those individual collaborative efforts that have all combined
together to be able to work through this. So this is just a great way
overall that you could provide collaboration options for everybody using
the application.

Module Review
So collaboration is just a huge aspect on what you would want to do and
it really now starts to allow you to use Dynamics 365 in more innovative
ways to allow collaboration amongst different users within your
organization. So I highly encourage looking at some of the out-of-the-
box capabilities that are there to set up and define that. Whether it's
looking at using folder synchronization, whether it's looking at using an
Office 365 group, SharePoint, OneNote, OneDrive, whatever the options
are, it's all going to provide you with a very unique collaborative
experience that you can use when working forward. The nice thing to
remember ... or as you're configuring some of this information, just
remember if you're going to use features like folder synching, folder
synching is kind of a two-tier process. It has to be enabled first at
the organization level through your email settings, and then once it's
enabled at an organization level, then you can go in and you can
configure it on a user-by-user basis within the context of the
application. The other options that you have are like SharePoint
integration. Now, remember there's two types of SharePoint integration,
but realistically the server-based SharePoint integration is really the
one that you're going to want to use most often, because that's the one
that not only provides kind of that realtime single sign-on capabilities,
but it's also going to give you the option to enable much of the other
dependent functionality. So things like office groups, OneNote,
OneDrive, Delve, a lot of that information is based off of having
SharePoint server-based integration set up. Once it's enabled, now you
have the ability to allow that collaboration with both CRM ... or I'm
sorry, Dynamics 365 and non-Dynamics 365 users within the context of the
application. Just remember that the permissions are independent. So if
you want to restrict what people can do inside the document library, you
would have to go into the SharePoint side of things and administrate
that, but now you have the ability to do things like OneNote and office
groups. Remember that with Office Group integration, however, Office
Group integration does rely on SharePoint. So you have to have the
SharePoint integration set up first; then you can install your Office
Group solution into your environment, and then you can go ahead,
configure it and set it up for the individual records that you want to
provide the collaboration on. And if you're looking for additional
options to really replace some of the note-taking functionality that's
inside Dynamics 365, OneNote integration is a great way to facilitate
that, because now you have all the checks and balance options that you
would normally see inside a shared OneNote file that's now being surfaced
inside Dynamics 365.

Test Your Knowledge Questions

1. Which of the following features must be enabled in your Dynamics 365 Organization before
you can use OneDrive Integration?

 SharePoint *
 OneNote
 Office Graph
 Yammer

Explanation: Several integration features such as OneNote, Office Graph, and OneDrive
integration can only be enabled once SharePoint Server integration has been configured. You
must also have a valid SharePoint and OneDrive license to enable the integration.

2. You have enabled OneNote Integration on your Dynamics 365 Organization, Users are asking
about access to notes created in OneNote from Dynamics 365. Which of the follow statements
are true about the security model? (Check all that Apply)

 OneNote Notebooks, use the same Security concepts as SharePoint Integration

 Deleting a Dynamics 365 record will also delete the Document Location that points
to the OneNote Files
 Non Dynamics 365 users can access Notebooks created in Dynamics 365
 Users do not need to have permissions on both sides to perform actions
 Explanation: The Dynamics 365 record is Linked to the OneNote Notebook. Deleting the
Dynamics 365 Record will remove the Link to the notebook not delete the Notebook

3. You went into went into settings and enabled office groups for the Account entity. When you
open an Account you notice that the Office Group stuff is not there. What did you most likely
forget to do.
 Did not click Save
 Did not click Publish All *
 Forgot to enable Office Groups on the Account Entity Properties
 Forgot to add the Office Group control to the Form.

Explanation: When configuring the office group integration, you must click the Publish All
button. This acts as your save functionality. Navigating away from the screen without doing so
will result in your changes not pushing.

4. Which of the following statements about Dynamics 365 Online and Server-side SharePoint
integration are true? (Check all that Apply)

 Server-side is available for Dynamics 365 Online and SharePoint Online *

 Server-side is available for Dynamics 365 Online and SharePoint On premises*
 Once enabled, you can switch to client side anytime
 All of these

Explanation: It is not possible to switch from Server die to client side syncing once enabled

Course Review
So as you can see, there's a lot of options when it comes to configuring
a Dynamics 365 implementation. Now, before we go through and kind of
talk about everything that we've gone through, the big thing to remember
is the configuration piece is really going to work hand in hand with the
customization piece. So remember, there is another course specifically
devoted to customizing Dynamics CRM where we talk about creating entities
and relationships and working with form customizations, because a lot of
the things that we've talked about throughout the course of this content
actually corresponds directly with some of that information. But when
you think about configuring and working through those elements, this is
where you can really start to enhance that functionality. So over the
last several hours, we've talked about a lot of different things,
including just what are the baselines around how do you configure a
Dynamics 365 implementation, how do administrative settings fit into
play, what do you use and how do you configure auditing, where would you
go from a duplicate detection standpoint to be able to configure how the
application is searching and looking for duplicate records inside the
application? We talked a lot about how security structure is based and
set up within Dynamics 365. So we looked at things like business units
and using business units as kind of a foundation for the boundaries for
how you're going to facilitate what records and what functionality inside
the application users actually have access to, based upon what it is that
they're doing. We looked at concepts like security roles and how you can
assign one or multiple security roles to an individual user, and then
based upon the privileges and the access levels that are associated with
that security role for a specific entity, how it controls what specific
items they have access to within the context of the application. And we
looked at how you can use concepts like teams to be able to extend some
of that functionality out and now be able to assign records or work with
permissions for specific items in the application within the context of
that user being a member of a specific team. We explored areas in
regards to hierarchal security and how you can use hierarchal security to
really enhance the baseline security functionality of the organization,
and instead of just relying solely on who that user is and what security
role they have, we looked at how you can use the concept of who their
supervisor is or what their position is within the organization to
provide greater visibility into people who either report directly to them
or indirectly report to somebody that falls underneath you as an
individual. We talked about knowledge management and we talked about how
you can surface and do knowledge management functionality searching
inside the application, and we looked at how to enable that for a
specific entity and some of the baseline configuration options that you
have to do in order to expose some of that knowledge management
functionality and make it available for use on portals and transferring
some of that information over into other areas of the application. We
talked about processes and we looked at how do you use workflows and
dialogs and custom actions to be able to really enhance what some of the
automation processes look like inside the application, being able to
automatically create other records when new items are created just by
using a workflow to be able to facilitate that, or maybe use a dialog to
be able to capture information that was missing through other aspects of
the application. We introduced or talked a little bit about business
process flows and looked at how you can use business process flows to
really guide your users through a specific process that you have inside a
Dynamics 365 implementation, maybe taking somebody from a lead
qualification process and moving it all the way through until the end and
working it through to actually closing that opportunity, creating the
order and generating the invoice. And we were able to introduce you to
the new business process flow designer that was introduced as part of
Dynamics 365 to make it much easier to design those individual business
process flows and add additional functionality like workflows and items
from that standpoint. And then we also talked a little bit about how do
you integrate a Dynamics 365 implementation with Office 365? Where does
folder synchronization fit into the mix and how can you create those
folder maps, so you can drag an item to a specific folder and have it
surface that activity inside the application? We talked about things
like Office Group integration, so you can collaborate with non-Dynamics
365 users across the context of the application. We looked at replacing
note functionality using OneNote and using SharePoint to be able to
facilitate document management. So there's a lot of different options
from a configuration perspective that you can do when you're looking
through these different elements. Now, before we close, I guess a couple
of just final things that I would like to recommend or just talk a little
bit about. We have hands-on lab files that are a part of this course
that I would highly recommend downloading from the application drive.
This just has a lot of exercises on all the different concepts that we
talked about, whether it's creating security structure, whether it's
facilitating integration, or even more importantly, if you want to get
kind of a true hands-on with the new business process flow designer,
using that process as well. So if you haven't already, I would highly
recommend downloading that information from there. Well, that's going to
do it for this session. Again, I want to thank you very much for
watching and we appreciate your time. And again, my name has been Derik
Bormann. Take care, everybody, and have a good one.