Dynamics CRM has a robust
security model consisting of several components that work together to control
the privileges and access levels to which users are entitled. The combination
of these security controls also establishes an organizational structure within
Dynamics CRM.
Access: How will users access the system? (HTTP/HTTPS, the Outlook
client, mobile devices). Each of these gateways will have associated security
protocols in place.
Authentication: How are users recognized by Dynamics CRM? This can be
established through Active Directory, Windows Live ID, or claims-based
authentication.
Organization: To which organization(s) does the user belong? Users have a
default organization and may belong to multiple organizations.
Business Unit: User will belong to a Business Unit (BU). BUs are also
hierarchical and may have multiple child BUs. BUs establish the depth of the
organization’s structure in Dynamics CRM.
Security Role: Users may have multiple security roles. Security roles
establish the depth and breadth of access and privileges that users are
granted.
Team: Users may belong to one or more teams. Teams also have
security roles and can own records in Dynamics CRM.
Field Security Profiles: Field security profiles are used to enforce field-level
security on Dynamics CRM objects.
Understanding business units:
One of the greatest values of
Dynamics CRM is its ability to increase knowledge-sharing and ease of access to
information for an organization. Business Units are the fundamental building
block that Dynamics CRM uses to establish the depth of a user’s access. Each BU
has one parent BU, but may have multiple child BUs. Each user (and team) must
belong to one (and only one) BU. Security roles can be configured to provide
users and teams with privileges (such as read, write, assign, and so on)
limited to their own records, their own BUs, child BUs, or organization-wide.
If Business Units create the
depth of your organization’s structure in Dynamics CRM, security roles specify
the breadth of a user’s or team’s privileges, and the depth to which they can
employ them. Security roles use these two concepts depth and privilege to
create a multidimensional set of permissions. Privileges are the actions that a
user may perform on a specific entity.
The available privileges are:
·
Append (permits the user/team
to attach an instance of the specified entity to another record as a child)
·
Append To (permits the
user/team to attach other records to the specified entity)
·
Assign (not available for
organization-owned entities)
·
Share (not available for
organization-owned entities)
The intersection of a security
role’s privileges on a given entity are referred to as access levels. Access
levels determine the scope or range of records upon which a user may perform
the privileges. Access levels (depths) are:
·
None: The user cannot perform the privilege on any records.
·
User: The granted privilege can only be performed on records the
user owns.
·
Business Unit: The granted privilege can be performed on records in the
user’s Business Unit, regardless of who owns the record.
·
Parent: Child Business Units: The granted privilege can be performed on records in the
user’s Business Unit, or on any records in Business Units that are parented by
the user’s Business Unit.
·
Organization: The granted privilege can be performed on any record
throughout the organization.
Microsoft Dynamics CRM 2011
introduces team ownership, the capability for records to be owned by teams
rather than by users. Users can be members of multiple teams.
When users are assigned more
than one security role, they receive the union of permissions from the security
roles. In other words, they are given the least restrictive permissions. For
example, if one security role has the User access level on the Write privilege
for contacts, and a second role grants the Organization access level for the
same privilege, a user with both security roles will have the greater
permission — Organization-wide Write privileges on contacts.
Dynamics CRM ships with a
number of default security roles. Among the default roles are two that have special
behavior when it comes to custom entities. The System Administrator role and
the System Customizer role are automatically granted privileges for new custom
entities when the entities are added to the system. Other roles must be
manually updated to accommodate new entities.
Dynamics CRM 2011 has the
ability to configure permissions on individual fields within an entity.
Field-level security is enforced using a new type of role called a Field
Security Profile. Field security profiles behaves similarly to sharing in that
they cannot grant a user privileges that the user’s security roles do not
allow. When a field is enabled for field level security, Dynamics CRM starts
with a restrictive default setting for the field. Users cannot read, update, or
create the field until you specify roles that have these permissions.
Field security can only be enabled for custom fields. System
fields cannot be enabled for field-level security in Microsoft Dynamics CRM
2011.
Setting up teams for your
users:
Teams are a convenient way to
group users who work together on sets of records in Dynamics CRM. Teams can own
records and are assigned security roles like users. Also, like users, teams
must be parented by a single Business Unit.
The main purpose of Business
Units is to allow you to define security in Microsoft Dynamics CRM. Each user
must belong to a Business Unit. Business units form the foundation upon
which the security structure is built. They allow the grouping of users and the
objects they own so that permissions to those objects can be set. Business
Units provide the framework upon which you configure the following components.
There must be at least one
Business Unit in Microsoft Dynamics CRM. The root Business Unit is the
top-level node of the Microsoft Dynamics CRM organizational hierarchy. This may
represent the corporation or holding company of all Business Units in the organization.
The root Business Unit has the following characteristics:
·
There is exactly one root
Business Unit in Microsoft Dynamics CRM.
·
The root Business Unit is
automatically created by the Microsoft Dynamics CRM Server Setup program (or
from the Deployment Manager if this is a second or subsequent organization in a
multiorganization deployment).
·
Because it is the top-most
Business Unit in any organizational hierarchy, the root Business Unit cannot be
assigned a parent Business Unit.
·
The root Business Unit cannot
be deleted or disabled.
All other Business Units:
All other Business Units are
children (direct or indirect) of the root Business Unit. Business units may
represent subsidiaries, divisions, or departments within the business. With the
exception of the root Business Unit, all other Business Units may be deleted,
though there are conditions to be met. All other Business Units may be moved
around the hierarchy or disabled.
A Business Unit may contain the
following entities:
Although it does not have to
contain any of these, there would be little point in a Business Unit without at
least one of these types of entity. A Business Unit may also relate to one or
more of the following entities:
When a Business Unit is
created, it has no contents except for a single Team with the same name as the
Business Unit. The Team has no members, but any Users created in, or added to,
the Business Unit will automatically be added to the Team.
The Parent Business Unit field
is required for any Business Units you create. The only one that cannot have a
parent is the root Business Unit and that is created by the system on creation
of the Organization. You can change the Parent Business Unit of any Business
Unit in order to reorganize your structure.
When you do this, the following
considerations apply:
·
Changing the parent of a
Business Unit affects all the children of that Business Unit, they move with
the parent.
·
You will not be allowed to
create circular relationships. For example setting A to be the parent of B; B
to be the parent of C; and C to be the parent of A.
·
You cannot change the parent of
the root Business Unit (the root Business Unit cannot have a parent).
·
You cannot set the parent of a
Business Unit to nothing.
Reorganizing Business Units:
Reorganizing a Business Unit is
a matter of changing a Business Unit’s parent. This changes the reporting
relationship for the Business Unit and all users, teams etc. in that Business
Unit.
·
When a Business Unit is
reassigned to a new parent, all its child Business Units move with it, along
with their users, teams etc.
·
There may be issues with the
Security Roles that a user or team has. In particular, if an inherited
Security Role has been assigned to one or more of the users or teams that
belong to the moving Business Unit and the new parent does not have the role,
then the Security Role will be removed from the Users or Teams. You should
always check the Security Roles of Users and Teams in Business Units that move.
You can also open a specific
Business Unit record to change its parent. However, you cannot change the
parent Business Unit directly on the Business Unit form because the Parent
Business unit field is read-only. To change the parent Business Unit, you must
click the Actions menu and select the Change Parent Business option.
Disabling Business Units:
A Business Unit (except the
root Business Unit) can be disabled, For example, if the Business Unit
temporarily ceases operation. This leaves its organizational structure in the
Microsoft Dynamics CRM database for historical purposes, or so that it can be
re-enabled if it begins operations again.
Disabling a Business Unit will
disable all child Business Units and render Users, Teams etc. that are attached
to these Business Units unable to connect to Microsoft Dynamics CRM. Any other
users who gain access to MICROSOFT DYNAMICS CRM resources through membership of
disabled Teams will not be able to access those resources.
Although the Users cannot access MICROSOFT DYNAMICS CRM, the user
records themselves are not removed or disabled. Therefore, the licenses of
those users will not be withdrawn.
·
Disabling a Business Unit has
serious repercussions, especially to the users assigned to the disabled
Business Unit.
·
Disabling a Business Unit
disables not only that particular Business Unit, but also every child Business
Unit below it. The users assigned to these Business Units will be unable to log
on to Microsoft Dynamics CRM.
·
Disabling a Business Unit does
not disable any of the users, therefore it does not unassign the user licenses
associated with those users.
·
Users cannot be assigned to a
disabled Business Unit.
·
Child Business Units cannot be
assigned to a disabled Business Unit.
·
Users who relied on membership
of teams for access to certain resources will not be able to access those
resources if the Business Unit (and hence the teams) are disabled.
Although users assigned to a disabled Business Unit cannot access
Microsoft Dynamics CRM, no data associated with the Business Unit is deleted or
lost. If a disabled Business Unit is enabled, each enabled user assigned to
that Business Unit can again access the application.
Similarly, enabling a disabled
Business Unit also affects the users assigned to the Business Unit as well as
Child Business Units which will also become enabled
·
All enabled users assigned to a
Business Unit that is enabled can access Microsoft Dynamics CRM.
·
Any disabled user (an
unlicensed user in Microsoft Dynamics CRM) is not enabled when his or her
Business Unit is enabled.
·
If a user is disabled when the
Business Unit was disabled, the user must be enabled before he or she can
access Microsoft Dynamics CRM after the Business Unit is enabled.
A Business Unit (except the
root Business Unit) can be disabled, for example, if the Business Unit
temporarily ceases operation. This leaves its organizational structure in the
Microsoft Dynamics CRM database for historical purposes, or so that it can be
re-enabled if it begins operations again. Disabling a Business Unit will
disable all child Business Units and render Users, Teams etc. that are attached
to these Business Units unable to connect to Microsoft Dynamics CRM. Any other
users who gain access to MICROSOFT DYNAMICS CRM resources through membership of
disabled Teams will not be able to access those resources.
Although the Users cannot access MICROSOFT DYNAMICS CRM, the user
records themselves are not removed or disabled. Therefore, the licenses of
those users will not be withdrawn.
Before you can delete
permanently a Business Unit, you must remove any child Business Units, Users or
Teams. This can be done by deleting or re-assigning them individually, or by
using the Reassign Records option as mentioned above. The exception to this is
the default team of the Business Unit, which will be deleted with the Business
Unit. Facilities/Equipment and Resource Groups do not have to be removed
beforehand (though they can be if you want to preserve them).
Finally, you must disable the
Business Unit before deleting it.
The Reassign Records option is
available even for a disabled Business Unit. Perform the following steps
to permanently delete the records of a Business Unit:
·
From the Navigation Pane, click
Settings, click Administration, and then click Business Units.
·
Select Inactive Business Units
from the View. Open the Business Units you wish to delete.
·
Ensure all Users, child Business
Units and Teams (except the default team) are removed.
·
From the Actions Menu, choose
Disable. Click OK in the resulting dialog.
·
Again from the Actions menu,
choose Delete Business Unit. Click OK in the resulting dialog.
If you have satisfied all the
requirements, the Business Unit will be permanently deleted.
Disable Business Units rather
than delete them if they are no longer part of the structure of your MICROSOFT
DYNAMICS CRM organization.
There is no way to undo the deletion of a Business Unit.
The best practice is to
implement as flat a Business Units structure as possible, both to simplify
administration and to minimize complexity.
Below are some simple rules to
keep in mind when working with Business Units:
Business Units cannot be
deleted or renamed, but they can be disabled or reparented.
When disabling a BU, all users
and teams within it are also disabled.
When reparenting a BU, users’
and teams’ security roles are removed and must be reassigned manually.
When creating a new BU,
security roles are automatically copied down from the parent to the child BU,
where they cannot be edited.
They must be edited in the parent BU, and changes will propagate
down to the security roles in all child BUs.
