Company concept
The company concept (what a company does or indicates) differs depending on the application that you're concerned about. In this module's scenario, you focus on finance and operations apps and Dataverse.
In finance and operations apps, the company concept comprises two concepts that are tied together. Company is a security area tied to permissions, privileges, and roles, and it's also a legal and reporting concept.
For example, your user operates in finance and operations apps and has access to the USMF company in Contoso Demo data. The USMF company is where you can do business, create trade agreements, and define warehouses and countries/regions in a single legal entity. Additionally, you can work in specific currencies only in USMF. As a result, you can't complete these activities in the USRI company because of your security roles. Finance and operations apps refers to the legal entity, data area ID, and company information with the same concept.
Unlike finance and operations apps, which mix security and business constructs in the same concept, Dataverse differentiates these constructs. The business unit or owner records are related to a user's security boundaries, which determine what a user can view or modify. These company records have a specific relationship with the cdm_Company entity. You can have different control over the company, separate from the business unit and the security of the user.
Essentially, finance and operations apps includes both concepts represented together while Dataverse has separate concepts.
In finance and operations apps, any table with the company concept or that's dealing with a company includes the DataAreaID field. This notion is true for all tables, such as CustTable, SalesTable, CustGroupTables, and CompanyInfo. A data area ID is a three or four-character string that relates to the DataArea table, which doesn't keep track of which companies exist. The CompanyInfo table has a one-to-one relationship with the DataArea table, and one row in the DataArea table is tied to the same data area in the CompanyInfo table where the related information about that data area.
In Dataverse, the Account table stores the company information. The cdm_Company foreign key tells a user in which legal record that the record for each row resides. The Owner column is implied security. Most entities, such as Account, have an owner who's a user or a team. A user who's a member of a business unit owns the account record, meaning that the account entity is part of that business unit.
This concept becomes important when you add security. Because you can allow the user to view the record if they own the record or are part of the same business unit that owns the record. The key concept is that the company semantics about the legal company membership is explicitly through the cdm_Company foreign key, and the security constructs of the business unit that it's related to are through the ownership component.
Some records or entities in Dataverse don't have an Owner field, such as the Product entity. These entities are referred to as global entities, and they can still have a business unit but are globally readable by the entire organization.
The standard implementation of finance and operations apps and the deployment of Dataverse have an expectation and automated process. It determines that, for every company in finance and operations apps, an accompanying company entity and business unit exists in Dataverse. When the system makes the connection to Dataverse, the automated process creates the matching company entity between finance and operations apps and Dataverse. Additionally, the system creates two teams: the default team and a dual-write specific team.
This approach simplifies the task of deploying a new entity in finance and operations apps because everything works and is deployed by default. However, you aren't forced into this organization and deployment model. Other options and customizations are available for the business structure in Dataverse without affecting the company or ownership of records.
The following example shows a generic breakdown of the legal entities in finance and operations apps, how it appears in Dataverse from an automated perspective, and the ownership of records based on the automated deployment strategy.
Three legal entities are in finance and operations apps. Therefore, at least three business units (BUs) exist in Dataverse, with two teams under each business unit: a default team and a dual-write team. The system uses the dual-write team for the default ownership of data written from finance and operations apps and vice versa. Therefore, finance and operations apps has the data area ID, and Dataverse has an owner. As previously mentioned, you can customize this setting. You can change the ownership of a record inside of Dataverse after the initial assignment, and you can modify the business units and teams to fit your business needs more efficiently.