Access requests treat an access need as traceable management. GovFrame includes a request cart, Workflow cases, tasks, decisions, provisioning, and evidence. A management instance can group items and allow partial outcomes.
The request takes its context from the requested object—for example, a table, dashboard, dataset, or other permitted destination—and is linked to a Workflow case. The object and its associations determine the business context; the request does not bypass company, membership, module, capability, or scope rules.
Before you start
- Role: A User can participate in requests authorized by their company’s policy. Administrative management of access, memberships, requests, and provisioning requires the capability
access.manage, which belongs to the Administrator under the current contract. Anyone deciding on a request must also be the responsibility configured by the company for the case and be authorized for its context. - Module: The Workflow components involved must be operational for the company. Configurable modules are validated in the interface and backend; disabling one does not automatically delete its records, but prevents further operation with its function.
- Prerequisites: The destination must exist in the company and be identifiable as the requested object. Review its relationship to the taxonomy, the responsible parties, and the scope before processing it. Active membership of the requester and participants is still required.
Temporary user views are read-only, except for expressly permitted Access Requests operations. They do not expand catalog permissions or allow the company or scope to be changed from the browser.
Recommended workflow
- Define the need using the correct object. Locate the asset, table, dashboard, dataset, or other destination permitted by the company’s policy. Verify what is being requested and its context. Do not infer a technical relationship just because two objects share a name or Domain.
- Group related items. Use the cart to gather requests that should be handled in the same management instance. Keep the justification and scope of each item distinct, since the decision may not be the same for all of them.
- Create the case and organize the work. The request is linked to a Workflow case, which is used to track tasks, participants, and the decision. The route is illustrative: the current state documents the functional components, not a fixed form, a public list of stages, or state names.
- Decide based on evidence. Authorized responsible parties review the request, apply the company’s access rules, and record the decision and available evidence. There may be partial approval and masking treatment when the case requires it; the documentation does not define a universal masking policy or its values.
- Track provisioning. When a decision requires provisioning, retain it as part of the traceable management instance and verify the associated evidence. The existence of this phase does not confirm that access is automatically created in an external system: any integration and its actual execution depend on the company’s configuration.
- Review the outcome for each item. Check that tasks, the decision, any restrictions, and evidence correspond to each requested destination. If the object has relationships with contracts, products, rules, or technical sources, use the relationship map to support the review without inventing dependencies.
Illustrative example. An analyst gathers a dashboard and a dataset associated with the Commercial Domain in one request. The case is routed to the configured responsible parties. The dashboard is approved, and the dataset is made conditional on a masking measure documented in the same management instance. The example illustrates a partial decision; it does not describe mandatory fields or screens.
Expected outcome
The company has a management instance connecting the requester and requested destinations with the case, tasks, decision, provisioning when applicable, and evidence. The outcome shows what was resolved for each item without confusing business approval with the automatic technical creation of an external permission.
Traceability is retained within the effective company. The backend derives the company from the session and verifies membership, the module, and authorizations; changing identifiers or parameters in the client must not enable access to objects belonging to another company.
Limits of current behavior
- Request states, deadlines, transitions, forms, closed catalogs of destinations, and exact screen steps are not published because they are not defined as a common functional contract.
- The cart and partial approval do not replace scope rules. Having an assigned task does not authorize operations outside the corresponding object or Domain.
- GovFrame documents provisioning and evidence in the management instance, but it cannot be assumed that a connector or destination system automatically executes permissions.
- If the decision relies on SQL from a quality rule, SQL can only be generated when a physical field is associated and a dialect is configured. The request does not execute that SQL automatically.