Business Units (Planning and Implementing Your Organization’s Structure)

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.

The hierarchy of securitycontrols for 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.

Configuring security roles:

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:

·         Create

·         Read

·         Write

·         Delete

·         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. 

Note:                                            

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.

       

Working with field securityprofiles:

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.

Note:

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.

Business Units in depth: 

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.

·         User management

·         Security 

·         Reporting

Root Business Unit:

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.

Business Unit Contents:

A Business Unit may contain the following entities:

·         Users

·         Business Units

·         Teams

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:

·         Facilities/Equipment

·         Resource Groups 

·         Audit History 

·         Processes 

·         Dialog Sessions

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.

Maintaining a Business Unit:

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.

NOTE:

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.

Deleting 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.

NOTE:

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.

BEST PRACTICE:

Disable Business Units rather than delete them if they are no longer part of the structure of your MICROSOFT DYNAMICS CRM organization.

WARNING:

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.