About Business Units

As part of your enterprise structure in the applications, the business unit (BU) primarily serves as a container or construct that can be used to separate or share setup and reference data.

A business unit typically performs one or many business functions and has a specific place in the organization hierarchy. Usually, each business unit has a manager, strategic objectives, a level of autonomy, and responsibility for its profit and loss.

A business unit can:

• Process transactions on behalf of many legal entities and post transactions to its own primary ledger.

• Segment transactional data from other business units. For example, if you run your Sales business separately from your Marketing business, you segment the Sales business data to prevent access by the Marketing employees.

• Report on transactions.

• Share sets of reference data across applications. Business units process transactions using reference data sets that reflect your business rules and policies across the company. You can share reference data, such as payment terms and transaction types, across business units, or you can choose to have each business unit manage its own set, depending on the level at which you want to enforce common policies.

Business Unit Terminology

Be aware of the following terminology as you implement and work with multiple business units:

• Master data: Data that's managed globally and isn't specific to any BU. Examples include:

  • Accounts: Customer accounts can't be segmented by BU.

  • Users: Users can be associated to BUs through their resource organization membership, but in general are managed globally.

  • Products: While different BUs might sell different products, the definition of a product is global.

  Note: Access to master data, such as accounts and contacts, must be driven through territory-based assignment. Master data can't be segregated by business unit.

• Reference data: This is data that's used by transactional objects like leads and opportunities. Reference data can be different across BUs or common across BUs. Reference data is organized into reference data sets, also called sets, each with a unique Set ID. Examples include:

  • Lookup types, such as those that provide lists of values for several fields in opportunities and leads

  • Opportunity sales methods, available for modification in the sales methods setup pages

• Transactional data: This is the sales user data, such as that associated with leads, opportunities, and contracts that are created during a typical sales process.