Dynamics CRM: Stepping into organisation management

One of the core concepts in Dynamics CRM concerning organisation management is Business Units. Business units are containers used to represent the business hierarchy, where the organisation created during the installation of Dynamics CRM is at the top (that is, the root business unit).

Business Units are similar to an organisational chart, but not quite the same. Combining with other organisational management settings such as sales territories and sites, this can lead to a lot of confusion, and I’ve seen a lot of implementations where business units haven’t been properly considered.

I wrote this post as a kick-start guide for those who are unsure on how to structure their organisation in Dynamics CRM.

Background

Consider this organisational structure chart for the company ACME, a logistics company:

The company has six divisions of operation. For Brazil, the country has been split into four divisions, and there isn’t a top-level division for Brazil at this point.

Adding into the equation, the company has six offices, where the newest one is the California office which has opened in February this year.

Now if we combine the divisions and offices of ACME, this is the chart we come up with:

As for the people organisational chart, this is how ACME commercial is structured from a sales management point of view:

ACME is a family business ran by both father (Edward) and son (Jason). Edward is located in Brazil while Jason has recently relocated to their new offices in California, but they both should have a transparent visibility through the entire organisation. Jason is responsible for managing ACME’s international divisions, therefore Andrew, ACME’s EMEA regional manager, reports to Jason. Andrew has two account managers in his team: Kevin and Wayne. ACME is still setting out their offices in California, and Jason will be responsible for its operations once it opens.

Brazil is ACME’s main market, and due to its size it has two regional managers. Renata manages the São Paulo sales division, which is ACME’s largest division, while Marcelo manages the rest of Brazil. Renata has three account managers in her team: Helena, Victor and Bruno; while Marcelo has four account managers: Silvia, Fernando, Daniel and Carlos.

What went wrong

ACME was having a hard time trying to enforce security roles across its business units in Dynamics CRM, so they called me to provide some consultancy. At the time they had an implementation of Dynamics CRM 4 with the following business units defined:

ACME defined their business units in Dynamics CRM based on their office locations, which resulted in the following issue: Marcelo, the manager responsible for all of Brazil but São Paulo, couldn’t be assigned into an appropriate business unit. Since Marcelo must have access to the Brasilia, Rio de Janeiro and Porto Alegre business units, he must be at a parent business unit which has these business units as its childs. If Marcelo was to be assigned to the Brazil business unit, he would have hierarchical access not only to his Business Units, but also to the São Paulo Business Unit which he shouldn’t – São Paulo is Renata’s Business Unit.

Previous limitations of Business Units: In Dynamics CRM versions prior to 2011 (which includes version 4), messing around with business units is particularly painful, since business units couldn’t be deleted or renamed. Microsoft addressed this issue with Dynamics CRM 2011.

Understanding our options

The key in not to mess with the organisational structure in Dynamics CRM is to understand the options we have for structuring our organisation. There are certain options which, although they might not seem important to some, tend to help us a lot with reports and workflows.

• Sites: Sites allow us to create the locations from where our organisation operates. This is quite useful when creating reports and charts to measure the performance/progress of specific sites. This is also useful for resource assignment if you’re using the Services module.
• Sales Territories: Sales territories allow us to define the market segments which are assigned to salespeople. This is quite useful for creating workflows and reports. For instance, we could trigger a workflow to notify the manager of a sales territory when new opportunities are created within the manager’s territory, or group a sales pipeline report based on sales territories.

A note on sales territories: I have seen a lot of confusion with Sales Territories in the past. I once visited a customer that created one sales territory for every single USA state, which didn’t reflect their sales regions at all. Remember that we have the option of specifying the state/region of client records in Dynamics CRM, so there is no point in replicating those as sales territories, unless each state is in fact a unique sales territory (a scenario which I am yet to see in real-life).

• Teams: Teams allow us to group users who work and share the same business records. In Dynamics CRM 2011, every Business Unit that is created has a default group, to which all users of that Business Unit is a member of. The membership of these default groups cannot be modified. However you can create new teams where you can specify their memberships across Business Units. This is quite useful when we want to share certain business records across business units.

The solution

The key in creating the business units in Dynamics CRM is to think of the people responsible for managing them. With this in mind, when I deployed a fresh new (and from scratch) Dynamics CRM 2011, I went to create the following business units:

I encourage you to compare the diagram above with the original business unit set-up that ACME did with Dynamics CRM 4. I hope it will all make sense as you reach the end of this post.

With the process of creating business units comes also the process of customising our security roles. I have initially set three main security roles for ACME, which are briefly described below:

• ACME Salesperson: Can perform several activities within Dynamics CRM, mostly in the Sales module and its related entities, such as leads, accounts, contacts and opportunities. Most of the privileges for this security role is based on the user access level (only for the records the users own). I have also removed access to other modules and restricted some delete privileges (they must ask their sales managers to delete stuff fore them).
• ACME Sales Manager: The sales manager is responsible for managing salespeople within their business units. In essence this security role is similar to ACME Salesperson, however it has access to more entities and other modules and it can also delete certain records. Most importantly, the majority of the privileges for this security role is based on the parent access level (all records in their business unit and child business units).
• ACME CEO-Business Manager: This is the “ultimate” security role, created for the directors of the organisation. They have to almost all modules (with some exceptions to prevent accidental misconfiguration, such as customisation and system administration), and the majority of the privileges for this security role is based on the organisation access level (all records in the whole organisation).

Overview of the solution

Here is how I set the business units to work along with the security roles I mentioned:

• ACME: This is the top-level organisation business unit. There are only two people assigned to this business unit as CEO-Business Managers: Edward and Jason (the directors).
• BRAZIL: There is no one assigned into this business unit. I have created to consider the future expansion of ACME, since the divisions for Brazil are likely to change in the medium term.
• REST OF BRAZIL: Marcelo is the only person assigned into the Rest of Brazil business unit, and he has a Sales Manager security role.
• CENTRE-WEST, NORTH & NORTHEAST: Silvia is assigned into this business unit as a Salesperson.
• SOUTH: Carlos is assigned into this business unit as a Salesperson.
• SOUTHEAST: Fernando and Daniel are assigned into this business unit as Salesperson.
• SÃO PAULO: Renata is assigned as Sales Manager, while Helena, Victor and Bruno are assigned as Salesperson.
• EMEA: Andrew is assigned as Sales Manager, while Kevin and Wayne are assigned as Salesperson.
• NORTH AMERICA: ACME is yet to hire personnel for the north american operations,so this business unit is empty at the moment.

This set-up perfectly fits the requirements of ACME for their CRM implementation. With Edward and Jason as CEO-Business Managers at ACME (the top-level business unit), they have the visibility their required through the entire organisation. With Marcelo being the sales manager of the Rest of Brazil business unit, he has the required visibility to the child business units (Centre-West, North & Northeast, South and Southeast). The EMEA and São Paulo business units has their appropriate sales managers (Renata and Andrew, respectively) directly assigned to them. Finally, every salesperson is directly assigned into their respective business unit.

If you compared the original ACME business unit chart with my business unit solution, you might be wondering about the sales territories and offices. Well, this is where the Sales Territories records and Sites records come into place.

Next step: Sites and Sales Regions

After I created my business units, I am moved on to create my sales territories and sites for ACME.

First I created one site for each ACME office:

• Brasilia
• California
• Dublin
• Porto Alegre
• Rio de Janeiro
• São Paulo

This is quite useful if you want to create workflows. For instance, I could set-up one workflow to e-mail the appropriate personal based on the office where record owners are based. Say, if Fernando creates an invoice record, an e-mail is sent to the billing department of the Rio de Janeiro office (that is, the office where Fernando is based). I am also on the process of creating reports to measure the performance of given offices.

Finally, I created the following Sales Territories:

• BR: Centre-West, North & Northwest
• BR: São Paulo
• BR: Southeast (excluding SP)
• BR: South
• EMEA
• NA

Sales Territories are particularly important for drawing reports and charts in the sales module, such as the sales pipeline report. Users can also drill-down into the sales pipeline chart (the funnel graph) and follow the pipeline by territories. I can also think of useful workflows can that make use of sales territory information. For example, what about e-mailing territory manager when a new account or contact is assigned to their specific territories?

Wrapping up

I hope that this guide can be prove useful to those starting with Dynamics CRM. At first the concept of business units, sales territories and sites can be overwhelming, and I am sure that some opinion on the matter wouldn’t hurt (I wish I had this info when I started four years ago with Dynamics CRM!) Remember that what your organisation perceives as business units in their day-to-day operations might not be exactly what you need in Dynamics CRM. Start by thinking on who manages what, and who must see what, and go from there.