Organizations
what is an organization? an organization represents a logical boundary around a set of assets, data, users, and configurations within factry historian it defines who has access to what, and separates one environment from another organizations are typically used to map to a company, site, or business unit, depending on how the historian is deployed why does it matter? organizations are the top level structure for managing access, visibility, and ownership they ensure users see only the data they are allowed to see assets and data are logically grouped configurations like dashboards, alerts, and events are scoped correctly multi site or multi client environments remain clean and isolated without organizations, it would be difficult to manage who can access which part of the system, especially in larger deployments how does it fit in the system? each organization contains collectors docid\ wp81bftwmpuk gfimcj6u , measurements docid\ xqwlemdcnfff3 0h gmms , calculations docid\ opiodkgnngyjedx6zkg d a set of assets docid\ c4opdlucirj0draexrisp , asset properties docid\ cr6hbrdsl8fsuvlvm20if and events docid 0ith2zlcais5yywhsdtje linked to those assets manual entry forms docid\ e6zvm8l zlpfpchdtqu0h sinks & forwarders docid\ xcoj5kic2xmxsz4inas users with roles and permissions specific to the organization (see users and groups docid\ qbrzo7rkw3jk66xvbrt2l ) most data and configuration objects in the historian belong to a single organization users can belong to one or more organizations, and have different permission levels (with groups) for each example suppose you run a central historian instance for multiple production sites ghent brewery antwerp packaging plant bruges r\&d lab you define one organization for each site each site has its own assets, measurements, dashboards, and users operators in ghent cannot see data from antwerp or bruges unless explicitly granted access management can see data from all when you use it you define and manage organizations when deploying the historian for multiple clients or locations assigning users and setting permissions configuring data access boundaries for integrations or reports managing site specific settings and templates in a single site deployment, you may only need one organization, but the structure still applies common misconceptions an organization is not the same as a department or team it is a technical boundary for data and user access organizations are not optional even single site systems still operate within one you cannot share assets or measurements across organizations directly cross org access requires deliberate configuration best practices use one organization per physical site or business unit to keep things clean avoid mixing unrelated assets or users within a single organization name organizations clearly and consistently, especially in multi site setups review user roles and access regularly, especially if users belong to multiple organizations more information creating an organization docid\ ut7ikcamgr4vesremx2k8 switching to an organization docid 46jh2un7xsioyn8so5ryn