Business units
Create and assign business units to your system users to organize your system and add different layers of permissions to your data.
By creating business units and assigning them to your users, you can add differentiation between the data in your system. This will allow users in different business units to only see the data which they personally should have access to. If your business has a few different departments, is split up by geographical areas, has a few different branches, or anything similar, you can use business units to create relevant permissions for each department, area, or branch.
What are business units?
You can use business units to organize your company’s data access levels and create hierarchical permissions for the data your users have access to. The main advantage of using business units in your system is to assign a group of users with the same permission settings and differentiate between different data.
For example, let’s say you run a real estate business in the different boroughs of New York City: Manhattan, Brooklyn, Queens, Bronx, and Staten Island. Each of these boroughs have their own corresponding business unit. You can set up permissions so that the sales manager of the company can see accounts no matter which borough the account belongs to. However, the sales reps from each borough will only see the accounts which belong to their specific borough. This means the sales reps in the Manhattan offices will only see accounts which are in Manhattan, while the sales reps in the Bronx offices will only see accounts which are in the Bronx and so on. This example specifies the accounts object, but you can use business units to differentiate the data in any system object, such as deals, contacts, tickets, and more.
Below you can learn how to assign users to different business units so that the access to your data is based on their business unit. You’ll also learn about the parent business unit option, explained here, which allows you to create multiple layers of data access in your business.
Managing business units
To view all the business units in your system, first click the settings gear on the top right of any system page. Then use the System tab on the left and select the Business Units option from the top menu. Here you’ll open a list of all your existing business units.
Like in any other view, clicking on a business unit, such as the Brooklyn business unit, will open its individual page. Here you can edit any of its details, such as changing the name of the business unit, the manager, the address, or any other important details. In this way you can make sure each business unit in your system has the relevant data saved.
The business unit object’s page can be edited so that the structure and components of the page are relevant to your business using the Edit Page option, which is explained here. For example, you can add a highlights bar at the top of the page with the most important information. In the same way you can also edit the forms within the page, explained here, such as adding a related field called Phone - Manager which displays the business unit manager’s phone number. In this way you can fully customize both the components on the page and the fields within the form.
Adding new business units
You can add a new business unit to your system at any time, such as the Queens business unit. First follow the instructions above to open the business units list, and then click the green Add button at the top of the page.
This will open the new business unit form where you can add all the details for your new business unit, such as the name, phone number, manager, and address. The Parent Business Unit field is important if you’d like to add multiple layers of data protection; see below for more details. Click Save to add your new business unit and open its page.
Parent business units
You can use parent business units to provide specific users with an added layer of access. For example, you may want anyone who’s assigned to the New York City business unit to be able to access all the account records in the system which fall under any of the New York City boroughs, and not just the accounts in a specific borough. Users who are assigned to a parent business unit can be given access to all the records which are assigned to both the parent business unit, and to any of the child business units which belong to the parent.
Continuing the above example, you can set the New York City business unit as the parent to each of the borough business units, Manhattan, Brooklyn, Queens, Bronx, and Staten Island. Any user who is assigned to New York City can then have access to any records where the access level is set to any of the five boroughs, or to the New York City parent unit. The reps who are assigned to one of the borough business units will still only have access to their specific borough, so that reps assigned to the Manhattan business unit will only see accounts in Manhattan and so on.
To set up the example above, you’ll first need to create the New York City business unit. You can then open up each of the five borough business units and set the Parent Business Unit field to New York City. This field is a built-in lookup field within the business unit object, which relates business units to other business units. This means by opening the lookup option for this field, you’ll open a list of all the business units in your system, and can select the relevant one. For a detailed example, see below.
To make sure you’ve included all your child business units within your parent business unit, first open your parent business unit. Then use the related multi component and click on the Business Units option to view a list of all the children assigned to this business unit. You can learn more about the related multi component here.
Assigning business units to users
After you’ve set up your business units, the next step is assigning each user with the relevant business unit. This will ensure that each user only sees the data which is relevant to them. To start, open the list of users in your system by clicking the settings gear on the top right of any system page. The System tab will automatically be selected and opened to the Users page. Here you can click on any user to open their page and update their business unit. For example, you can click on Henrietta Cole, who’s one of the sales reps in Brooklyn, to open her page. You can now scroll down to the User Settings section and click on the Business Unit field to update it. For Henrietta this field can be set to the Brooklyn business unit, as that is the borough she works in.
You can now go back to your main users page and set the business units for each individual user. For example, you can assign the Director of Operations and the CFO of the New York offices to the New York City parent business unit so that they can see all the data in each of the child business units. Each sales rep will instead be assigned to the borough business unit they operate in, and will only see the data which is relevant to their borough.
Setting each role’s sharing level
Once you’ve assigned each user the relevant business unit, you can decide which data should be differentiated based on business units. This is done using the sharing options of objects within each role permission page. There are two options which you can select for each object, Team Only or Business Unit. Each are explained in detail below
Team Only sharing level
The Team Only option will ensure that users assigned to this role will only see records which belong to them or someone else in their business unit. Continuing the example used above, you may want all your sales reps to only see the accounts which are in their business unit. You can do this by opening the Sales Rep role and setting the sharing permission of the Accounts object to Team Only. Be sure to click Save once you’re done. Now every user who is assigned the Sales Rep role will only see the accounts which they share a business unit with. For example, if Henrietta is assigned to the Bronx business unit and is under the sales rep role, she’ll now be able to access all the accounts which are assigned to her or any other users who are also assigned the Bronx business unit. You can go on to set up these permissions for the different roles and objects in your system.
Business Unit sharing level
The Business Unit sharing level adds an extra layer of access to users based on child business units. By selecting this option, users will have access to any records which are assigned to their business unit, as well as any records which are assigned to any child business units which belong to their business unit. Let’s use the example above to clarify. Mark is assigned the Director of Operations role and the New York City business unit. This business unit is the parent business unit for each of the five borough business units. Open the Director of Operations role and set the Accounts object’s sharing permissions level to Business Unit.
Mark will now see not only the accounts which are assigned to the New York City business unit, but also all accounts which are assigned to any of the five borough business units. He will not see any accounts which fall under other business units which aren’t part of the New York City hierarchy, such as accounts which are under the Los Angeles business unit.
Example: Multi level hierarchy
Business units are most helpful when you’d like to create a multi level hierarchy of access levels within your system. Let’s continue our realtor business example to explain this concept.
One level
Prime Real Estate is a realtor company which operates in the United States, specifically in New York City and Los Angeles. When they first started working they created business units for each of these cities. In this way the employees in the different cities only saw the properties, accounts, and deals which were relevant to them, and information which realtors didn’t directly need access to stayed confidential. All of these objects are set with the Business Unit sharing level. Some employees worked in HQ and needed access to all the data in the system. To set this up, the sharing level of their objects was set to Everyone. In this way they could see all records, no matter which business unit the record belonged to.
.png)
Two levels
As the company grew, they had different realtors who worked in different districts of each city. To make sure that each realtor was only working with the properties which were relevant to them, the system administrator created child business units for each district. The Beverly Hills, The Harbor, and Central LA business units were created and their parent business unit was set to Los Angeles. Business units were also created for each of the five boroughs, with New York City set as the parent business unit for each.
Now each of the realtors was assigned to the business unit of the district they worked in, and had access to only the properties in their district. Their sharing level was still set to Business Unit. Because their assigned units did not have any children, this level functioned the same way the Team Only sharing level would, in that they only had access to records which belonged to their business unit.
In contrast, the employees in the main office of each city, such as the directors of sales, were all assigned one of the parent city business units. The sharing level of the objects for all of these employees was set to Business Unit. This provided the main office employees with access to all the data which happened in any of the districts within their city. However, they were unable to access any data which belonged to a different city. For example, the director of sales in New York could access any information which belonged to their assigned business unit, New York City. They could also access records which belonged to any of the New York City boroughs, as these business units were all children of their assigned business unit. They could not access data which belonged to Los Angeles, or any of its child business units as they did not belong to the New York City business unit. In this way each system user was provided access to only the data they needed. Below you’ll find charts depicting the structure of the business units.
Three levels
Eventually Prime Real Estate started branching out and working in other cities in New York State. They now had a main office in New York which managed all the holdings anywhere in New York state and New York City. This office used the business unit New York State, and all the cities in New York had this business unit set as their parent business unit. One of these was the New York City business unit, which was still the parent unit for the five borough units. This set the five borough units as grandchildren to the New York State business unit. In this way the employees in the New York state office could access data assigned to any of the boroughs, as well as any of the other cities in New York, and in the main New York state office. These employees were of course set to the Business Unit sharing level. If they were instead set to the Team Only sharing level, they would only see records which belonged to their assigned business unit of New York state. For a visual understanding of these business units, see the flow chart pictured below.
This structure was set up in the system by setting the relevant parent business unit for each business unit, as is pictured below.
All the employees who used the Business Unit sharing level and were assigned to any of the New York state business units could not access any data pertaining to the Los Angeles business units. This kept the two locations separate, and let the branches run separately while still using the same system structure. By using structured business units and the different sharing levels, you can provide all your employees with access to the exact data which is relevant to them and keep your data secure.
