# Data Access Service Account Grant Feishu Approval

This is a separately deployed, manually reviewed Feishu definition for
Helix-originated BigQuery dataset access requested for a typed GCP Service
Account email. Runtime never creates or changes this definition.

- Flow key: `data_access_service_account_grant`
- Origin: Helix only; external origin disabled
- Callback: `/api/v1/approval/feishu/callback`
- BigQuery mutation owner: the data-access reconciler only, never this
  approval callback

Before mapping the published approval code into
`integration_approval_flows`, configure only the `data_owner_review` node:
Helix supplies the selected dataset/table owners. There is no requester-manager,
workload-manager, or Service Account technical-owner approval stage.

Helix validates and records the typed Service Account email before creating the
approval. The input is not pre-registered and does not require a technical
owner. On callback Helix revalidates the recorded principal plus every resource
snapshot; any mismatch settles as `stale_requires_resubmit` without a binding,
compiled effect, or BigQuery write.

Build the reviewed Feishu v4 payload with the shared DAX deploy helper before
making any network call:

```bash
python3 deploy/feishu/deploy_data_access_group_grant.py \
  --definition deploy/feishu/approval-definitions/data_access_service_account_grant/definition.json \
  --dry-run
```

The helper is shared despite its historical Group-oriented filename; pass the
published approval code only when updating an existing disposable/test
definition. Record the published code in the matching Helix flow mapping only
after an independent definition readback.

For the controlled production release path, run `Deploy DAX Feishu Approval`
on `main` with `flow_key=data_access_service_account_grant`: its closed
selector uses this definition, stores the returned code only in
`FEISHU_APPROVAL_DATA_ACCESS_SERVICE_ACCOUNT_GRANT_CODE`, and upserts only the
same `integration_approval_flows.flow_key`. It does not alter the Group mapping.

Start each non-production rollout with `apply_mode_enabled=false`. Provider
writes require the separate Service Account apply switch and the normal approved
binding/current-resource checks, not principal or dataset config allowlists.
Do not enable apply switches when publishing this definition.

Deploying Helix code alone does not update Feishu's published template or old
in-flight instances. Publish/read back the owner-only definition and upsert its
matching Helix mapping for new requests. Handle old manager-blocked instances
separately; do not forge approval callbacks or mark them approved in the DB.