> ## Documentation Index > Fetch the complete documentation index at: https://docs.generalvalidation.com/llms.txt > Use this file to discover all available pages before exploring further. # Azure resources and permissions > Understand the customer execution resources, identities, and scoped permissions created when you connect General Validation to Azure. General Validation hosts the application and stores its configuration and result metadata. Your Azure subscription owns validation execution, source access, staging, exact results, and captured failed rows. The [environment setup flow](/installing-general-validation) shows the exact resources, names, template, and permissions before you deploy. Your Azure administrator deploys that template; General Validation then verifies it and manages its reusable Data Factory content. ## Resources in your subscription | Resource | Purpose | | -------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Dedicated resource group | Contains the execution environment's resources | | Azure Data Factory with a system-assigned identity | Runs metadata preparation, source-access probes, validation, and result delivery | | ADLS Gen2 storage account | Retains customer-side working files, results, and artifacts | | Control and results container | Holds validation inputs and results | | Browser-artifact container | Holds exact result metrics and bounded failed-row previews that authorized browsers read directly | | User-assigned callback identity | Lets the customer execution factory submit bounded result metadata to General Validation | | Custom roles and role assignments | Authorize metadata operations, execution management, and narrowly scoped source-access preparation | The storage account uses hierarchical namespace, HTTPS, TLS 1.2, and Microsoft Entra authentication. Shared-key and anonymous access are disabled. The standard template enables thirty-day soft deletion for blobs and containers. Browser CORS permits the General Validation application origin. The application, API, background services, and application database are operated by General Validation. They are separate from the execution resources billed to your Azure subscription. ## Who receives access | Identity | Access | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | | Execution Data Factory identity | Writes control/results and browser artifacts; reads approved source containers and customer-authorized SQL or Fabric tables | | Callback identity | Authenticates metadata-only result delivery from the execution factory | | Setup Owner | Reads the browser-artifact container through their own Microsoft identity | | Optional customer Entra group | Gives its members the same browser-artifact storage read access | | General Validation application in your directory | Reads approved resource metadata, manages the execution factory's reusable content and runs, and manages constrained source-reader grants | General Validation's Azure roles have no customer-storage data permissions. They do not allow it to read source rows, result artifacts, storage keys, or customer secrets. Exact-value and evidence reads use customer identities. Organization membership and Azure storage access are separate. An Owner grants product access in **Organization**; a customer Azure administrator controls storage RBAC and the membership of the optional reader group. ## Data Factory discovery By default, the template grants General Validation a read-only metadata role across your subscription so accessible factories appear in the discovery picker. This includes factory definitions and related metadata, with no source-data read permission. You can turn off subscription-wide discovery in the Azure deployment form. Grant metadata Reader access on each selected factory instead. The execution factory is separate from discovery sources and cannot be registered as one. An organization Owner registers a discovery source. Contributors can refresh its catalog and import selected datasets. ## ADLS Gen2 source access When you import a supported storage dataset, preparation uses the customer execution factory to check access and schema. If a qualified probe proves a missing read permission, General Validation can create or reuse a container-scoped **Storage Blob Data Reader** assignment for that execution factory's identity. The template's delegation permits only that reader role for this environment's execution identity. The preparation workflow further limits the assignment to the verified source container. General Validation itself receives no storage data access. A fresh customer-side probe must verify access before the Dataset becomes ready. Azure RBAC propagation can delay that check. A missing file, blocked network route, or unsupported schema needs its own correction; creating a role assignment does not resolve those problems. Existing customer grants are preserved. Product-created grants remain while imported datasets or active validation work need them and are cleaned up under the environment's disconnect workflow. ## Azure SQL Database The supported Azure SQL path uses the execution Data Factory's system-assigned managed identity. A customer SQL administrator creates its Entra database user and grants **SELECT** on the required tables. Azure subscription or server RBAC does not replace database permissions. Preparation runs a fixed access check against the exact imported table, then reads its schema through customer Data Factory activities. Follow the Dataset's remediation if it needs a table grant or SQL network access. Automated SQL permission grants are not available in the application. ## Microsoft Fabric Guided Fabric setup requires an organization Owner who is also an **Admin** or **Member** of the workspace. The Fabric tenant must allow the required service principals to call its APIs; tenant policy may also require administrator consent for the browser's Fabric permission. The browser connects the selected workspace and grants **Viewer** access to your execution Data Factory's managed identity when needed. Existing higher permissions are preserved. Viewer permits reads across the selected workspace, including Lakehouse and Warehouse SQL data. The Fabric token stays in the browser. The customer execution factory discovers items and tables, checks access, and reads supported Lakehouse and Warehouse SQL endpoints. Fabric capacity and networking must permit those operations. Each imported Dataset must pass its own table-access and schema checks before it becomes ready. Current setup and repair do not request a Fabric workspace role for the General Validation application. For an existing connection, review earlier assignments with your Fabric administrator; a setup change does not remove previous grants automatically. See [Connect Microsoft Fabric](/connect-microsoft-fabric) for setup and removal. ## Costs and retention Microsoft bills execution resources and validation activity to your Azure subscription. The General Validation subscription is separate. Azure costs continue during the free trial and can continue after disconnect while the resources remain. Set a customer-side retention policy for results, captured failed rows, and staging. Staging files do not currently have automatic cleanup or expiry; account for active runs before deleting their folders. Soft delete helps recover deleted objects for its configured window and does not replace your retention plan. See [Security and the data boundary](/security-and-data-boundary) and [Runs, results, and evidence](/runs-results-and-evidence) for how these resources participate in a validation.