A Workflow turns a governance decision into a traceable case with tasks, decisions, evidence, and notifications. It starts from a specific object or matter, follows the stages defined by the company, and does not replace the taxonomy or its recorded relationships.
GovFrame allows Workflows to be configured by type and number of stages. A case can maintain Domain or Subdomain context directly, or derive it from the affected object. Therefore, authorization does not depend solely on participating in a task: the company, module, capability, and applicable scope continue to be checked.
Before you begin
- Role: The Administrator can manage operations and the settings permitted for the company. A Data Owner handles decisions requiring approval within their scope; a Data Steward works on definitions and tasks in assigned Domains or Subdomains. A User participates only in activities they are authorized for.
- Module: Governance Workflows must be enabled for the company. If it is disabled, it is no longer operable either through the interface or through application procedures; existing data is not automatically deleted.
- Prerequisites: Identify the object or matter prompting the case, its taxonomic context if any, and the responsible parties who can take part. If the workflow requires a Workflow role or a governance responsibility, the company must have defined and assigned it consistently with the scope.
Before starting, distinguish between two levels. The template describes how a type of activity will be organized; the case is the specific instance tracked for an object or a request. This distinction prevents treating an isolated task as if it were a new governance process.
Recommended workflow
- Define the purpose and context. Explain what needs to be resolved, which object is affected, and which Domain or Subdomain applies. When the context comes from the object, review it before assigning work: an inherited relationship supports navigation and authorization, but does not change the object's original level.
- Define the template’s functional path. Configure the Workflow type and the number of stages needed for the company's process. For each stage, establish which responsibility must participate and what decision or evidence is expected. This is a functional path: the current documentation does not publish a fixed catalog of types, stage names, states, or universal assignment rules.
- Open and route the case. Link the case to the relevant governance object and assign tasks to people with appropriate capability and scope. Notifications do not replace reviewing the task and its context.
- Record verifiable work. Keep the decision made and the available evidence in the case. If the matter depends on a Quality Rule, first check that the rule has an associated physical field and a configured dialect before expecting SQL; the Workflow does not generate or execute SQL on its own.
- Close out the tracking with traceability. Review the pending tasks, decisions, and evidence linked to the same case. To analyze the object's impact before deciding, use the relationship map and follow only recorded links, not dependencies inferred from a name or from sharing a Domain.
Illustrative example. The team identifies that the definition of a Customers attribute needs review. A case is created and associated with the attribute; a Steward prepares the proposal and contextual evidence, and the competent Owner makes the decision within their scope. The outcome is linked to the case, without asserting that a standard stage, state, or form exists for all companies.
Expected outcome
At the end, there should be clear traceability between the matter addressed, the governance object when applicable, the assigned tasks, the contributions, the decision, and its evidence. The case retains the context needed for the company to track the work and for the backend to apply tenant, module, role, and scope restrictions.
A well-operated Workflow makes clear who did what, on which object, and on what basis, without creating an independent Risks or Controls catalog. In the current model, a control may be represented by a Quality Rule, a Policy or Procedure, an approval, a task, or a certification; each retains its own object and relationship.
Limits of current behavior
- Workflows are configurable, but this guide does not assume states, transitions, SLAs, forms, or screen sequences that are not documented for the company.
- Being able to view an object does not automatically grant permission to edit it, approve it, or assign work. Checks are performed in the backend.
- A disabled module blocks operation, but does not itself delete existing cases, tasks, or evidence.
- Scheduled tasks in other areas, such as metadata synchronization or backups, depend on their configuration. A Workflow case should not be interpreted as proof that a production job has run.