Each company is an isolated tenant: its catalog, configuration, locales, modules, and relationships are managed within that context. This guide covers what to configure and how to review the impact of a change within the documented limits.
Before you start
- Role: use platform authorization to administer companies and their permitted global configuration. The Superadministrator can select an active company; the Administrator operates with global scope only within the company where they have membership. These layers are not interchangeable.
- Module: Company Administration. The modules that are enabled or disabled belong to each company's configuration.
- Prerequisites: identify the target company and confirm that the action corresponds to its context. For normal operations, the company must be in state
active. The states documented for a company are exclusivelyprovisioning,active,suspended,disabled, anddeprovisioned.
The effective company is not freely selected from a regular user's browser: it is resolved from their session, membership, and company context. Changing identifiers or client parameters does not allow switching tenants.
What is configured in the company context
Tenant configuration brings together the name, operational state, deployment mode, parameters, locales, enabled modules, and associated hostnames. These properties define the scope of operations; business and administrative data remain associated with the tenant.
Locales affect the available interface and the company's default language. They do not automatically translate or alter names, definitions, or descriptions that the organization has registered as business content.
Modules determine which areas can operate. The application hides the routes and access points for a disabled module, and the backend rejects its queries and changes. Therefore, enabling an option in navigation does not replace permission validation, and hiding an option should not be interpreted as deleting data. Existing data for a disabled module is retained; it remains outside visible operations until possible reactivation, subject to roles, scope, and data state.
Synthetic example: a company can keep the Data Repositories module active and temporarily disable the Quality Rules module. The repository and its metadata remain objects of the company; one should not assume that the rules are deleted or that they can be operated while the module is turned off.
Recommended process
- Define the decision. Determine whether you will configure the company, locales, or modules. For platform actions, confirm the active company; for a tenant action, check membership and authorization.
- Review state and impact. An inactive company is not used for normal operations. Before modifying modules, identify dependent objects and workflows. Administration displays the records that will be hidden before confirmation.
- Configure in a coherent sequence. A progressive adoption starts with taxonomy and access, continues with repositories and the Technical Dictionary, and then incorporates terms, quality, assets, products, contracts, workflows, KPIs, policies, and exploration. This is a functional path, not a form or a list of states.
- Validate dependencies. The Technical Dictionary depends on Repositories; Quality Rules require both for complete operation. Products and Contracts require related objects. A disabled dependency may hide, limit, or reject the dependent function.
- Check the authorized effect. Review access, routes, capabilities, and scope. A visual check does not replace backend controls.
Limits worth confirming
A Quality Rule can exist without generated SQL. Generating SQL requires a valid association with a physical field and a configured dialect; this condition does not imply automatic execution of the SQL. Similarly, metadata synchronization records a manual, daily, weekly, or monthly schedule and versioned snapshots, but the effective schedule depends on the company's configuration. The presence of these options does not mean that production tasks are enabled or scans are running.
Risks and Controls are also not independent catalog modules in the current state. A control can be documented through a Quality Rule, a Policy or Procedure, a workflow, an approval, a classification, a certification, or a task; no expectation of standalone “Risks” or “Controls” inventories should be created.
Expected outcome
The company is configured in its own context, with locales and modules consistent with its operational scope. Disabled modules cannot be used, including through direct routes; their existing data is not automatically deleted, and operations remain subject to company state, membership, capability, and scope. The configuration does not, by itself, grant access between companies.