In GovFrame, a client company is modeled as an isolated company within the service. Its operational state is part of access control: together with membership, role, capability, scope, and modules, it determines whether a person can perform normal operations. The company context is not derived from an identifier sent by the browser and cannot be bypassed by changing a route.
This page is limited to the documented states for the company. It does not define states for workflows, requests, catalog objects, or other records. Nor does it assume a transition sequence, approvals, timeframes, or specific screens that are not publicly documented.
Before you begin
- Role: Global company management is the responsibility of the Superadministrator or Platform Administrator when the authorized procedure permits it. The Company Administrator can assess the impact of a change on people, modules, and operations, but must not assume global authority beyond their company.
- Module: Use the company and platform administration capabilities available to the company and your profile. The company state is distinct from enabling or disabling a business module.
- Prerequisites: Unambiguously identify the target company and confirm that you are acting within your authorized context. Before requesting or executing a change, review memberships, scopes, modules, and dependencies that could affect continuity of work.
Documented states
| Company state | Documented operational interpretation |
|---|---|
provisioning |
The company is in a preparation phase. It must not be treated as enabled for ordinary operations: only active permits normal operations. |
active |
This is the only state that permits normal company operations, provided that membership, role, capability, scope, and enabled modules requirements are met. |
suspended |
The company must not operate normally. Membership or a role does not restore those operations while this state remains in effect. |
disabled |
This is a documented company state and does not enable normal operations, since these are reserved for active. The available documentation does not prescribe a specific additional screen, transition, or handling. |
deprovisioned |
This is a documented company state and does not enable normal operations. It must not, by itself, be interpreted as an instruction to delete data, restore access, or modify configurations: such effects would require a documented procedure. |
Recommended workflow
-
Identify the need and the competent authority. Distinguish an access issue from a decision about the state of the entire company. If the scope is global, refer it to the Superadministrator or authorized Platform Administrator. Do not try to resolve it by modifying identifiers, scopes, or parameters in the browser.
-
Review the operating context. The effective company is resolved in the session and, normally, from the normalized hostname. A Superadministrator may select a company that permits normal operations for a global task. This selection does not turn the platform role into unlimited permission over the company's objects: the membership, capability, scope, and module guards remain in place.
-
Assess the functional impact without assuming automation. When the company is not in
active, normal operations must not be performed. Check which people, tasks, and processes will lose operational continuity and communicate the impact through the authorized channel. The sources do not establish an automatic schedule for suspension, reactivation, deletion, restoration, or notification; therefore, do not plan these effects as if they were enabled by default. -
Separate company state from modules. A disabled module hides or blocks its own operations, and the service rejects its procedures, but this configuration is not equivalent to changing the company's state. Conversely, an enabled module does not permit operations if the company is not in
active. According to the available documentation, data for a disabled module is not automatically deleted. -
Verify access after the authorized decision. For a company in
active, normal operations still depend on the other controls. For the other documented states, do not treat the presence of a previous session, a saved link, or a visible menu as authorization. Sensitive changes to an account, role, or scope may invalidate sessions in accordance with the security policy.
Illustrative example: the fictitious company “North Example” is listed as
suspended. Even if a person retains a previous session and has the Administrator role, they must not continue with ordinary tasks. The authorized team must assess the reason and follow its administration procedure; this guide does not invent a transition or a form for changing the state.
Expected outcome
The team identifies the five documented values, knows that only active enables normal operations, and distinguishes this condition from modules, roles, and scopes. Any change is treated as an authorized administration decision, with an impact assessment and without assuming automations or data effects that are not documented.
To review the scope of objects and responsibilities before assessing an impact, see Object model and relationships, How to read the relationship map, Roles, capabilities, and scope and Modules and dependencies.